Messages in this thread | | | Date | Thu, 23 Sep 1999 23:47:56 +0200 | From | Henner Eisen <> | Subject | Re: 1000ms delay in networking stack or driver, new bug? |
| |
>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
Alan> The theory is that dev->tbusy may get incorrectly cleared, Alan> but should never be left incorrectly set. The reasoning here Alan> is that on the drivers transmit code sets it.
Maybe if it gets cleared incorrectly and the tx_interrupt later uses "if(test_and_clear_bit(0,dev-tbusy)) mark_bh(NET_BH);" then no other packets get passed until somebody else (e.g. the next incoming icmp echo reply, QUESTION: will another outgoing ping socket also kick net_bh?) marks NET_BH. If the error persisted for subsequent packets, this might explain the "with two simultaneous pings, the sum of the delays is the delay of a single ping" phenomenon because two simultaneous pings will mark net_bh twice as frequently.
If tbusy remained set incorrectly, then net_bh will call dev->hard_start_xmit once a second for allowing the device to perform tx_timeout recovery. With such an error, two simultaneous pings should not result in increased throughput.
Alan> If you can break that assumption you may be onto Alan> something. it doesnt seem to explain why a module reload not
Well, if hard_start_xmit gets called, realizes that transmitter is busy, returns with tbusy set, and a tx_interrupt clears tbusy in between, tbusy might remain incorrectly set. (But I donŽt see how this could cause persistent delays because the device should recover after the next tx_timeout).
What happens if tbusy is not set from dev->hard_start_xmit() but from some other xmit pass that bypasses hard_start_xmit? (maybe [i]pppd is such such bypass although I havnŽt found a hidden tbusy setting yet).
Alan> an ifdown/ifup would be needed
Henner
- 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/
| |