Re: oops in tcp_xmit_retransmit_queue() w/ v2.6.32.15

Lennart Schulte
2010-07-15T12:55:30Z

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 ?
>