At 22:22 Uhr +0200 27.09.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. > 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
