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.
I use 2.4.23-pre3 + 2 bridging related patches:
shemminger 1.1109.2.4 [BRIDGE]: Clear hw checksum flags when bridging.
karlis 1.1063.40.5 [BRIDGE]: kfree --> kfree_skb.
[both of them are in 2.4.23-pre4]
I was able to reproduce this only once: I did a ^Z on the bash of the listening 'nc':
uml:~# ps -o pid,stat,cmd,wchan=WIDE-WCHAN-COLUMN 2179 2188
PID STAT CMD WIDE-WCHAN-COLUMN
2179 T nc -n -l -p 8888 signal
2188 S nc localhost 888 wait_for_tcp_memory
It didn't continue when I sent a SIGCONT but stayed in 'T'-state. Then I did a 'fg':
uml:~# ps -o pid,stat,cmd,wchan=WIDE-WCHAN-COLUMN 2179 2188
PID STAT CMD WIDE-WCHAN-COLUMN
2179 S nc -n -l -p 8888 read_chan
2188 S nc localhost 888 wait_for_tcp_memory
I thought that 'read_chan' is stange an hit Return. Then everything resumed back to normal (i.e. tcpdump shows lots of packets).
I have 3 bridges active and one of them has blocked port, but I don't think this is related to the bridging code.
Perhaps you could try again with 2.4.23-pre[456].
Hannes - : 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
