Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Nov 2006 17:44:40 -0800 (PST)
From:      John Polstra <jdp@polstra.com>
To:        Mike Tancsa <mike@sentex.net>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Serious em problems under -current on two different platforms
Message-ID:  <XFMail.20061118174440.jdp@polstra.com>
In-Reply-To: <200611181621.kAIGLblS075218@lava.sentex.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Nov-2006 Mike Tancsa wrote:
> Havent had too much experience with PCIe riser cards yet, but have 
> had some experience with bad PCI-X risers.  Any way to test to see if 
> its a bad riser card? The behaviour almost looks to be a hardware issue ?

I agree.  There's another slot (with its own riser) in the system, so
I can try the card there and see what happens.  I'll let you know.
It could also be a bad card, of course.  I have never seen it work
properly yet.

However, this wouldn't explain why the same kernel, driver, and
userland is also failing to work with my Tyan 2721's onboard 82546EB.
(It works flawlessly with earlier versions of the driver, even when
ported to the up-to-date kernel.)  The symptoms are pretty different
on the Tyan, though.  There, neither port will transmit anything, and
you get TX watchdog timeouts every time you try.  Go figure.

Back to the Dell.  Here's an interesting thing.  I went away from
the system for a few hours, and now I see that both ports are
working again.  I can ping flood either port and it works fine.  But
get this.  I started a ping flood on em0, and it's sitting there
drawing and erasing the ".", with no loss whatsoever.  Now I start a
normal 1-per-second ping on em1.  Once a second, every time a ping
goes through em1, the flood ping on em0 drops exactly 1 packet and
draws an extra ".".  Very strange.  Clearly, operations on one port
are affecting what happens on the other port.

>>Are you using both ports of the NIC?  With an older driver, em0
>>worked fine but em1 did not.
> 
> Yes, actually I am testing the forwarding ability of the box.  So far 
> with FreeBSD, I found that the 2 kernel options below
> 
>#options        ADAPTIVE_GIANT          # Giant mutex is adaptive.
> options         NO_ADAPTIVE_MUTEXES
> 
> and turning on fast_forwarding increases performance and 
> responsiveness of the box.

Thanks for that info.  It'll be useful to me once I get the NICs
working.

> any errors at the time on the switch port when things lock up ?

Not as far as I can tell, but they may have dropped off the end of
the stats by the time I checked.  There doesn't seem to be a way to
get cumulative stats from this switch, at least not through the GUI
interface.

John



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