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