Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2005 15:02:57 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Patrick Domack <patrickdk@patrickdk.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: EM Driver problems
Message-ID:  <20050621145127.L26664@fledge.watson.org>
In-Reply-To: <Pine.LNX.4.62.0506202043370.3348@server.dswett.patrickdk.com>
References:  <Pine.LNX.4.62.0506202043370.3348@server.dswett.patrickdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mon, 20 Jun 2005, Patrick Domack wrote:

> I have been using fxp network based cards, without issues. I have 
> recently changed over to em cards, and get kernel panics about once 
> every few days with them (mainly sbdrop panics). I already have 
> nsfclusters set to 32k, and freebsd vm memory set to 850megs, with 4g 
> memory installed.
>
> After playing adjusting things and not making any noticable 
> improvements, I upgraded the default freebsd em driver from 1.7 to the 
> 2.0 version on intels website. This seemed to fix things for awhile, 
> lastest two weeks before any problems happened, at witch time the 
> card/driver stopped recieving/sending packets. I am still looking into 
> exactly what happened here.

I looked in some of the mailing list archives, but didn't see specific 
reports from you on the panics you are seeing.  sbdrop() panics are almost 
always a sign of a device driver or network stack bug.  In as much as 
possible, a detailed bug report with source code version, stack trace, 
etc, would be very helpful.  Also, could you tell us a little more about 
the workload?  If you've already submitted a PR or posted in detail 
somewhere, I pointer would be helpful, thanks!

I'm not familiar with the if_em driver source from Intel, but one of the 
sets of changes that has been made to our driver that might not have been 
propagated into their driver is support for fine-grained locking, which is 
required if you're running on FreeBSD 5.3 or higher.  Hangs are not 
unusual failure modes if locking is omitted.  As such, I'd suggest we try 
to move debugging forward on vanilla FreeBSD source rather than the 
vendor's version of the driver.

Thanks,

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050621145127.L26664>