lkml.org 
[lkml]   [1998]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread+network crashes in 2.0/2.1

>>Ok, having decoded this a bit more, it look smore and more like a network
>>driver bug. I'm adding Donald to the Cc list..

Perhaps THIS crash is a network bug. However, the select bug you fixed
earlier is clearly a problem.

>>The above is part of the following code:
>>
>> /* Pass up the skbuff already on the Rx ring. */
>> skb = vp->rx_skbuff[entry];
>> vp->rx_skbuff[entry] = NULL;
>> temp = skb_put(skb, pkt_len);
>>
>>and in particular it seems that "skb" itself is NULL: the driver does no
>>sanity checking at all on whether the rx_skbuff[] array got depleted, so
>>when you see heavy network traffic it will go through the whole array and
>>start using NULL pointers.
>>
>>That's what it very much looks like, at least: it tries to avoid doing
>>this by having this "rx_work_limit" thing, but it is obviously not working
>>(at the very least there seems to be a off-by-one error, at worst the
>>whole idea is broken because once all the skb's are dirty the read routine
>>will never be able to do any work at all).

Hmm. That sounds ugly.

Unfortunately, I don't think we have any easily available network
cards. I guess we could swap cards from a Windows '95 box.

The downer is that THIS bug prevents us from doing any real testing.

Is it an easy fix to the network driver? If we could get a patch, then
we could see if we've truly flushed out the issue with the kernel.

In any case, we'll try and get some more crashes. Perhaps we'll get it
to die in a different area.

-Rob
rmf@highwind.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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