Messages in this thread | | | Date | Wed, 22 Sep 1999 19:46:42 +0200 | From | Karsten Keil <> | Subject | Re: 1000ms delay in networking stack or driver, new bug? |
| |
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/
| |