lkml.org 
[lkml]   [2003]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: natsemi.c: Oversized(?) ethernet frame message w/ card hang
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.048 / U:1.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site