Re: TCP quickack race ? (Was Problem: ...)

Andi Kleen (ak@muc.de)
28 Feb 1999 09:51:58 +0100


mattes@ice.robin.de (Matthias Moeller) writes:

> On Fri, 26 Feb 1999, Pete Wyckoff wrote:
>
> > Whew. Nothing to do with quickack. That just gave the server side of
> > the connection more opportunity to fill the pipe faster. It's still a
> > bad sign that the client's receive queue is empty even though we see the
> > packets going by with tcpdump.
> >
> > Can you go back down the tree until you find one which will not stall
> > for you? Another idea would be to turn off SMP if you'd had it on in
> > the kernels you used for the tests. These timing-related thing are
> > notoriously hard to debug.
>
> Compiling with/without SMP doesn't change anything (have only one cpu).
>
> I spend the last hours to go back the kernel tree. It appears that
> 2.1.127 is the first kernel where the stall happens. But it is much
> harder to reproduce. I had to play around with different read and
> write sizes. So I wouldn't take it for too sure that the bug really
> was intoduced with 2.1.127 and not earlier.

2.1.127 was the first kernel to process packets with PSH bit set in
the fast input path. So it could still be a even more obscure timing race,
or a bug in the header predicted fast path

-Andi

-- 
This is like TV. I don't like TV.

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