Messages in this thread | | | Date | Thu, 15 Jul 2010 14:55:27 +0200 | From | Lennart Schulte <> | Subject | Re: oops in tcp_xmit_retransmit_queue() w/ v2.6.32.15 |
| |
Since tcp_xmit_retransmit_queue also gets skb == NULL I'm pretty sure it is the same bug. Up to now I only experienced the problem with ACK loss (without ACK loss the test ran about 30min without problems, with ACK loss it had paniced within 10min). The data sender only has a HTB queue for traffic shaping (set to 20 Mbit/s). The ACK loss is done by another router. The setup looks like this. This way it seems to be the most realistic.
o sender with HTB | | o netem queue for forward path delay | o netem queue for a queue limit | o netem queue for backward path delay | o netem queue for ACK loss | | o receiver with HTB
Perhaps now it is a little big clearer.
On 15.07.2010 14:05, Eric Dumazet wrote: > Le jeudi 15 juillet 2010 à 13:58 +0200, Lennart Schulte a écrit : > >> I'm testing new reordering algorithms in a virtual testbed, that is the >> nodes are emulated with xen and all the network parameters can be tuned >> with queues. >> With one of the algorithms I also got tracebacks which include >> tcp_xmit_retransmit_queue. It only happens with ACK loss. The kernel >> version however is 2.6.31. >> When I read this thread I tried the debug patch and got the following: >> >> [ 2754.413150] NULL head, pkts 0 >> [ 2754.413156] Errors caught so far 1 >> >> Hope that is of any help. >> > Not sure I understand. > > Are you saying you reproduce same tcp_xmit_retransmit_queue() bug, with > a special tc qdisc/class droppping some ACK frames ? > > Could it be some sched problem and incorrect return codes in case of > congestion ? > -- 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/
| |