Stephen, Have you looked into this? Thank you On Sat, 27 Sep 2003, Santiago Garcia Mantinan wrote: > Hi! > > Since the change to 2.4.22 I've been experimenting problems here, after > many tests I have seen what I think is the problem that is causing this. > > The problem I'm seing is the loopback starts loosing packages, I don't know > if this could also happen on other interfaces. I'm testing this by starting > a: > tcpdump -n -i lo port > then a: > nc -n -l port >/dev/null > and a: > nc localhost port </dev/zero > > If everything is fine my cpu goes to 100% and I see the packages all the way > in my tcpdump screen, great. But there are sometimes when this doesn't go > smooth and the tcpdump starts to show only one or two packages each N > seconds, till it ends up showing the resend of the last package which is > never acknowledged, you can even see that the timings of this packages that > are being repeated match those of tcp backoff, my cpu charge is then really > really low, nc disconnects after a while, ... > > When does this happen? > > It took me a while to find this out, but it happens when you have a bridge > interface and one of the ports of the bridge is told to drop packages, like > when they detect a loop in the net and an interface is set to a blocking > state. > > Of course that the loopback is not a part of any bridge in any of my setups, > and I've seen this in a couple of machines, one SMP and the other one single > micro, 2.4.21 worked ok, at least I could not reproduce this on that one. If > the interfaces have been in a forwarding state all the time since the bridge > was setup, without being in a blocking state, then this problem does not > seem to happen. > > I believe that the changes the bridge went through from 2.4.21 to 2.4.22 are > to blame on this one, but this is just a guess. > > Hope we can find a fix for this so that it is integrated in 2.4.23 kernel, > I'll be happy to make any tests you want to track this farther down. > > Regards... > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html