Skip site navigation (1)Skip section navigation (2)
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>