Re: natsemi.c: Oversized(?) ethernet frame message w/ card hang

Re: natsemi.c: Oversized(?) ethernet frame message w/ card hang

[James E Lucas]

Thanks for the quick response.  The program I wrote can be retrieved at 
http://www.utdallas.edu/~jelucas/nstress.zip

I included the source file, and a binary compiled with mingw.  Of 
course, there are no guarantees on this.  I'm running it from win2k, I 
can't remember if there are any version dependencies in the program... 
should work under any NT version at least.  Syntax is nstress <IP 
address>.

Generally, what I've done is have an ssh session open to the offending 
box, and run tcpdump to watch the card.  Then I start throwing packets 
at it.  Between all the ssh traffic and the massive load, that usually 
brings things down pretty quick; within about 30 - 60 seconds.

The spec for the chip that I've been looking at can be found at  
http://www.national.com/ds/DP/DP83815.pdf

Take a look at page 82.  Now, in natsemi.c we find:

if ((desc_status&(DescMore|DescPktOK|DescRxLong)) != DescPktOK){
                        if (desc_status & DescMore) {
                                if (netif_msg_rx_err(np))
                                        printk(KERN_WARNING
                                                "%s: Oversized(?) 
Ethernet "
                                                "frame spanned multiple 
"
                                                "buffers, entry %#08x "
                                                "status %#08x.\n", 
dev->name,
                                                np->cur_rx, 
desc_status);
                                np->stats.rx_length_errors++;

Now, from page 82 of the spec:
A single packet may also cross descriptor boundaries. This is indicated 
by setting the MORE bit in all descriptors except the last one in the 
packet.


Maybe the chip is choking under load and spewing garbage into a packet? 
 Or trying to combine multiple packets...?  Perhaps this is a symptom 
and not the problem.  Maybe the chip's already plotzed, and this is a 
result before a total hang.

If that's the case, should we be resetting the chip at the point where 
the MORE alert comes in?  What would that do to open connections?  I 
don't know enough to say.

What has me wondering is that the card occasionally hangs apparently at 
random.  It may really be a chip bug that needs working around, and 
putting the card under heavy load just makes it show up by attrition.  
Or not.  I've actually been sitting on this one for a while, but it's 
nice to know I'm not the only one.

One related note: 
kernel: PCI: 00:07.3: class 604 doesn't match header type 00. Ignoring 
class.

shows up in the syslog on every bootup.  That ID belongs to a (Via) PCI 
bridge on the motherboard.  I looked through the linux-kernel archives 
and saw that this had been remarked upon a few times, but nothing much 
was made of it.  I don't know what kind of board you're using... it's 
probably not even related, but I thought it worth a mention.

Sincerely,
James Lucas

Re: natsemi.c: Oversized(?) ethernet frame message w/ card hang

[Alan Cox]

On Tue, 2003-02-04 at 21:23, James E Lucas wrote:
> 
> And, my kernel ring buffer (dmesg) is showing messages like this:
> 
> eth0: Oversized(?) Ethernet frame spanned multiple buffers, entry 
> 0x00ba8b status 0xe0000bd5.

By strange co-incidence I saw this with natsemi on one of my boxes
today. 

> numbers of large UDP packets at the card to reproduce the breakage.  If 
> anyone's interested in it I could post it up somewhere, though it's not 
> very pretty ;)

I'd love a copy

> from National Semiconductor *seems* to indicate to me that this message 
> results from a packet spanning multiple descriptors in the hardware.  
> This *is* legal for the chip according to National's docs, but I can't 
> find anything in the driver that seems to acknowledge this beyond the 
> warning message.  My current working theory is that this doesn't happen

Our drivers post buffers larger than an ethernet packet to the card so
it means the card thinks it received a frame larger than anything it
should have accepted.

> very often, but when it does, the driver's not handling it properly.  
> What I'm not so sure on is why that hangs the card.  Perhaps it's 
> throwing the driver into an infinite loop or something.  Not really 

If it got stuck in a loop the box would hang. It appears to stop the
chip and it never restarts.

My card that did this is also an FA-311. I've only ever seen this once
however so I guess my network isnt loaded enough 8)

natsemi.c: Oversized(?) ethernet frame message w/ card hang

[James E Lucas]

Hi, this is my first post to the list, so please go easy on me ;)  I've 
been having problems off and on with the natsemi driver for a good 
number of kernel versions.  I've wrestled with the problem off and on, 
but I've finally decided that it's out of my league, so I'm going to 
ask people smarter than I.

The card works fine most of the time, but under heavy load (and even 
occasionally seemingly at random) the card simply locks up.  ifconfig 
eth0 down; ifconfig eth0 up brings it back into a working state, but 
this is understandably still a problem.  ifconfig output after a few 
errors and resets looks like this:

eth0      Link encap:Ethernet  HWaddr 00:02:E3:04:D5:0B
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19883349 errors:1 dropped:778 overruns:3930 frame:4
          TX packets:288019 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3507882433 (3345.3 Mb)  TX bytes:336382589 (320.7 Mb)
          Interrupt:11 Base address:0xd000

And, my kernel ring buffer (dmesg) is showing messages like this:

eth0: Oversized(?) Ethernet frame spanned multiple buffers, entry 
0x00ba8b status 0xe0000bd5.


kernel messagelog and syslog are both clear (no apparently related 
messages).  You may note the extremely high number of received packets 
on the ifconfig.  I wrote a program (for Windows) that hurls massive 
numbers of large UDP packets at the card to reproduce the breakage.  If 
anyone's interested in it I could post it up somewhere, though it's not 
very pretty ;)

A perusal of the source of natsemi.c along with the spec for the chip 
from National Semiconductor *seems* to indicate to me that this message 
results from a packet spanning multiple descriptors in the hardware.  
This *is* legal for the chip according to National's docs, but I can't 
find anything in the driver that seems to acknowledge this beyond the 
warning message.  My current working theory is that this doesn't happen 
very often, but when it does, the driver's not handling it properly.  
What I'm not so sure on is why that hangs the card.  Perhaps it's 
throwing the driver into an infinite loop or something.  Not really 
sure... I don't have the facilities needed to run debugging on kernel 
drivers.

At any rate, any input would be appreciated.  I've never coded hardware 
driver stuff before, so I may be misinterpreting things.

Additional info:
Kernel version: 2.4.19 (stock, no patches)
CPU: AMD K6-2 400
Motherboard: FIC (can't remember model number offhand)
Chipset is Via MVP3
128 megs of RAM

The card in question is a Netgear FA-311

Again, any help would be most appreciated.

Sincerely,
Jim Lucas