Date: Mon, 29 Sep 2008 23:12:18 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Robert Watson <rwatson@freebsd.org> Cc: pyunyh@gmail.com, stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) Message-ID: <20080929211218.GC69054@onelab2.iet.unipi.it> In-Reply-To: <alpine.BSF.1.10.0809292109040.24341@fledge.watson.org> References: <wptzc1gu9v.fsf@heho.snv.jussieu.fr> <20080929043134.GD54819@cdnetworks.co.kr> <wpy71bavmf.fsf@heho.snv.jussieu.fr> <alpine.BSF.1.10.0809292109040.24341@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 29, 2008 at 09:10:29PM +0100, Robert Watson wrote: > > On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > > >However, the "request/respones" tests are awfull for my notebook (test > >repeated on the notebook for the sake of conviction) : > > Is it possible to rerun these tests with a 7.0 kernel of the same general > configuration? That would help us determine if it's a regression between > 7.0 and 7.1, or perhaps a more general issue between 6.x and 7.x. I > wouldn't reject a hardware, driver, or general stack issue at this point as > things are still fairly unclear. If it's definitely between 7.0 and 7.1 > that the problem arises, trying a series of kernels spaced at, say, one > month intervals in that period would be quite helpful in narrowing down the > source. two things: + the 'nfe' driver is not in 6.x so i wonder how these numbers were derived in 6.x -- perhaps using a backport, or using the nve driver instead ? In any case we cannot easily compare 6.x and 7.x behaviour with nfe. + with the nfe driver and the MCP67 chipset i have found a tendency of the card to stall at high data rates and with some system load (e.g. massive scp while some X applications is spinning). This was completely repeatable and caused the network card to become deaf (it could transmit though) and it required an ifconfig down/up to come back to life, watchdogs and timeouts did not fix it. Additionally i have found some bug in the polling implementation which may or may not relate to more generic interrupt handling. This was described in a thread in april. A patch to address the stalls is at http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080426.1044.diff (i have been running this on my home pc since late april) A related patch changes slightly the implementation of polling: http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080427.diff At the time when i raised the problem on the mailing list apparently others were not seeing the problem so i did not pursue the integration in the system - but if this is a significant problem in 7.1R then it is worth a try. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080929211218.GC69054>