Date: Tue, 13 May 2008 10:07:21 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Pascal Hofstee <caelian@gmail.com> Cc: pyunyh@gmail.com, current@freebsd.org, yongari@freebsd.org Subject: Re: nfe0 watchdog timeout Message-ID: <20080513080721.GA92634@onelab2.iet.unipi.it> In-Reply-To: <20080513073809.3b163baa@nebuchadnezzar> References: <20080512181259.04a2f542@nebuchadnezzar> <20080513020927.GD32942@cdnetworks.co.kr> <20080513073809.3b163baa@nebuchadnezzar>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 13, 2008 at 07:38:09AM +0200, Pascal Hofstee wrote: > On Tue, 13 May 2008 11:09:27 +0900 > Pyun YongHyeon <pyunyh@gmail.com> wrote: > > > Can you see link state change reports of nfe(4) in your dmesg file? > > If you find any entries related with nfe(4) please show them to me. > > It may have a couple of link UP/DOWN messages and watchdog timeouts. ... > > When you know nfe(4) is not working anymore, would you check Rx MAC > > is still able to see incoming packets by invoking tcpdump on > > nfe(4) interface? > > Once it happens again i'll make sure to check on it. > > > It would be even better I can see verbosed boot messages related > > with nfe(4). > > Will provide once i can reboot the system again (it's currently in the > middle of a somewhat lengthy build process). related to nfe(4) i recently noticed on one of my systems a tendency of the receiver to stall under high link and CPU load. A patch to address the problem is at http://info.iet.unipi.it/~luigi/FreeBSD/#nfe though not ideal (because it calls the nfe_init routine on a suspect stall) it does the job here, so maybe you can try it on your system too. At first i too saw the problem on an AMD64 system, but it turns out that i386 uses the exact same code and the problem was repeatable on i386 platforms too. A way to trigger the stall, in my case, was to start an scp of a long file from a local machine (100Mbit in my case) to the nfe-equipped system. At the same time, start playing with X11, run a compile or do some other CPU intensive work, which should cause CPU shortage for the receive task to a sufficient level for the stall to occur cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080513080721.GA92634>