Messages in this thread | | | Date | Sat, 27 Feb 1999 19:00:53 +0100 (CET) | From | Matthias Moeller <> | Subject | Re: TCP quickack race ? (Was Problem: ...) |
| |
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.
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/
| |