Problem with nfe stability and throughput
Pyun YongHyeon
pyunyh at gmail.com
Fri Jan 18 22:04:02 PST 2008
On Fri, Jan 18, 2008 at 07:10:48PM +0100, Chris Poulsen wrote:
> Hi,
>
> Pyun YongHyeon wrote:
> >On Fri, Jan 18, 2008 at 10:01:00AM +0900, To Chris Poulsen wrote:
> > > On Thu, Jan 17, 2008 at 07:05:11PM +0100, Chris Poulsen wrote:
> > > > Hi,
> > > >
> > > > Pyun YongHyeon wrote:
> > > > >Would you show me the output of "ifconfig nfe0"?
> > > > >
> > > > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> > mtu 1500
> > > > options=48<VLAN_MTU,POLLING>
> > > > ether 00:1d:60:6d:73:ec
> > > > inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255
> > > > media: Ethernet 100baseTX <full-duplex>
> > > > status: active
> > >
> > > Hmmm, it seems that you've set media type manually without relying
> > > on automatic media detection. Is there any reason not using auto
> > > media type? How about using media type 'auto'?
> > > #ifconfig nfe0 media auto
> > >
> >
> >I've updated the experimental driver. Please revert previous patch and
> >apply the following one.
> >
> >http://people.freebsd.org/~yongari/atphy.diff2
> >
> >And show me the 'ifconfig nfe0' output again.
> >
>
> I tried specifying the media type manually, when I was trying to get nfe
> up and running earlier, I've reverted to auto now.
>
> The box in question is currently running with your latest patch, I did
> manage to stress it (with a couple of concurrent ftp uploads+some web
> browing) into a state where it once again gave me a bunch of the following:
>
> kernel: nfe0: discard frame w/o leading ethernet header (len 4 pkt len 4)
> kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0)
> last message repeated 12 times
> kernel: nfe0: discard frame w/o leading ethernet header (len 3 pkt len 3)
> kernel: nfe0: discard frame w/o leading ethernet header (len 11 pkt len 11)
> kernel: nfe0: discard frame w/o leading ethernet header (len 5 pkt len 5)
> kernel: nfe0: discard frame w/o leading ethernet header (len 5 pkt len 5)
> kernel: nfe0: link state changed to DOWN
> kernel: nfe0: link state changed to UP
>
> However bringing the interface down and up seemed to put it back into a
> normal state. (I just noticed that nfe0 went down/up again, without my
Did you have to bring nfe(4) down and up manually due to network lockups?
> interaction, if that matters).
>
Maybe this would come from atphy(4) bug. atphy(4) does not seem to
reliabily detect an established link.
> ifconfig nfe0 yields:
>
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=48<VLAN_MTU,POLLING>
> ether 00:1d:60:6d:73:ec
> inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255
> media: Ethernet autoselect (100baseTX <full-duplex>)
> status: active
>
How about the following change?
>From /usr/src/sys/dev/mii/athpy.c:
288 ssr = PHY_READ(sc, ATPHY_SSR);
289 if ((((bmcr & BMCR_AUTOEN) != 0) && ((bmsr & BMSR_ACOMP) == 0)) ||
290 (ssr & ATPHY_SSR_SPD_DPLX_RESOLVED) == 0) {
291 /* Erg, still trying, I guess... */
292 mii->mii_media_active |= IFM_NONE;
293 return;
294 }
To:
288 ssr = PHY_READ(sc, ATPHY_SSR);
289 if ((ssr & ATPHY_SSR_SPD_DPLX_RESOLVED) == 0) {
290 /* Erg, still trying, I guess... */
291 mii->mii_media_active |= IFM_NONE;
292 return;
293 }
Thanks for your patience and testing.
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list