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

[Lennart Schulte]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/