Kernel is 2.6.16.16 with my patches, including a patch to the e1000. I also rebuilt a fresh kernel with only the attached send-to-self patch. I see the hang, but there was no OOM messages, probably because the machine was freshly rebooted and had plenty of buffers available. I will try to reproduce this with some other NICs next... I am running 2 TCP connections between two ports of a pro/1000 NIC with fiber interfaces. Both connections are trying to send 200Mbps in both directions. Each write to the socket is 5000 bytes. MTU is 1500. After maybe 10 seconds, I see out-of-memory errors on the console and then the connections hang and send no more traffic. However, the NICs are still showing ~215kpps. According to ethereal, these are duplicate acks. 0.928361 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 4#1389] 33020 > 33019 [ACK] Seq=4294967208 Ack=32 Win=23 Len=0 TSV=1278643133 TSER=1278356385 0.928618 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 2#1300] 33018 > 33017 [ACK] Seq=0 Ack=0 Win=538 Len=0 TSV=1278643133 TSER=1278338974 0.928858 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 4#1390] 33020 > 33019 [ACK] Seq=4294967208 Ack=32 Win=23 Len=0 TSV=1278643134 TSER=1278356385 0.929190 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 2#1301] 33018 > 33017 [ACK] Seq=0 Ack=0 Win=538 Len=0 TSV=1278643134 TSER=1278338974 0.929461 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 2#1302] 33018 > 33017 [ACK] Seq=0 Ack=0 Win=538 Len=0 TSV=1278643134 TSER=1278338974 0.929716 172.1.5.169 -> 172.1.5.168 TCP [TCP Dup ACK 4#1391] 33020 > 33019 [ACK] Seq=4294967208 Ack=32 Win=23 Len=0 TSV=1278643134 TSER=1278356385 107215 packets dropped Stopping the TCP connection does not appear to immediately fix the problem: The connections are in the FIN_WAIT1 state and the dup acks continue to flow. ifdown/ifup after stopping the connections seems to clear the problem. I saw no more OOM messages with TOE disabled, but the connection still hangs. The OOM related console messages are attached. The problem also happens when no OOM messages are printed, but it runs slightly longer (maybe 15-20 seconds). I suspect that a dropped packet or packets is somehow the problem. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com