lkml.org 
[lkml]   [1999]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: TCP quickack race ? (Was Problem: ...)
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.051 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site