Re: 1000ms delay in networking stack or driver, new bug?

Karsten Keil (kkeil@suse.de)
Wed, 22 Sep 1999 19:46:42 +0200


On Wed, Sep 22, 1999 at 07:58:11PM +0400, kuznet@ms2.inr.ac.ru wrote:
> > just a question: could it be that the inconsistent manner in which
> > drivers manipulate dev->tbusy flag is related to the problem?
> > (Some drivers use atomic bitops, others -- as well as the packet scheduler --
> > access it by plain C language constructs).
>
> Not on UP and not in 2.2.
> 2.2 queueing is so paranoid (exactly to workaround wrong tbusy handling
> inside drivers), that the only effect of misused tbusy should be only
> excessive cpu eating.
>
> I see two explanations:
> 1. device is lost from run queue because of some bug in scheduler.
> 2. device stopped to receive rx interrupts.

Definitly not 2. because I checked this with one guy, who has that problem
via a ISDN line. And from postings on our ISDN mailling lists, it seems
that this Problem wasn't in 2.2.5 but in >= 2.2.10.

>
> I repeat the request: gentlemen, please, make tcpdump both on
> wire and on local host with "tcpdump -i eth0 -n -v -s 256 -x icmp",
> when pinging. The investigation even will not be started until
> I get at least one report of this kind.

It told ISDN people with this effect, to make such logs.

The guy where I checked the internal state of the isdn device driver, made
allready such logs, but I think he didn't stored it.
What he saw was:
Line slows down, a running ping (direct to the peer) freezed. He started
started tcpdump and a new ping, now he saw that with the new ping
also the missing packets from the old ping are seen in tcpdump, and also get
a quick response.

Karsten

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/