I'm seeing this problem on 2.2.13 running on a PPC, an using DEC/Intel
21143 ethernet interface & the tulip 0.91g driver. Packets are delayed
for many seconds, up to 15, and are then all sent at once.
The system got into this state after about 6 hours of heavy network
traffic (NFS and SMB), and could not be recovered until a reboot.
This affected all network traffic; I'm using ping as an example
below.
I noticed in Alan's 2.2.13 release notes that a bug with these
symptoms was supposed to have been fixed. I hadn't seen anything
like this until 2.2.13.
$ ping -s 10.1.16.14
PING 10.1.16.14: 56 data bytes
64 bytes from test1 (10.1.16.14): icmp_seq=25. time=5. ms
64 bytes from test1 (10.1.16.14): icmp_seq=0. time=25001. ms
64 bytes from test1 (10.1.16.14): icmp_seq=1. time=24006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=2. time=23006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=3. time=22006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=4. time=21006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=5. time=20006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=6. time=19007. ms
64 bytes from test1 (10.1.16.14): icmp_seq=7. time=18008. ms
64 bytes from test1 (10.1.16.14): icmp_seq=8. time=17009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=9. time=16010. ms
64 bytes from test1 (10.1.16.14): icmp_seq=10. time=15011. ms
64 bytes from test1 (10.1.16.14): icmp_seq=11. time=14012. ms
64 bytes from test1 (10.1.16.14): icmp_seq=12. time=13013. ms
64 bytes from test1 (10.1.16.14): icmp_seq=13. time=12014. ms
64 bytes from test1 (10.1.16.14): icmp_seq=14. time=11015. ms
64 bytes from test1 (10.1.16.14): icmp_seq=15. time=10016. ms
64 bytes from test1 (10.1.16.14): icmp_seq=16. time=9017. ms
64 bytes from test1 (10.1.16.14): icmp_seq=17. time=8018. ms
64 bytes from test1 (10.1.16.14): icmp_seq=18. time=7019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=19. time=6019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=20. time=5019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=21. time=4019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=22. time=3019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=23. time=2019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=24. time=1019. ms
64 bytes from test1 (10.1.16.14): icmp_seq=29. time=14003. ms
64 bytes from test1 (10.1.16.14): icmp_seq=28. time=15004. ms
64 bytes from test1 (10.1.16.14): icmp_seq=27. time=16005. ms
64 bytes from test1 (10.1.16.14): icmp_seq=30. time=13006. ms
64 bytes from test1 (10.1.16.14): icmp_seq=31. time=12007. ms
64 bytes from test1 (10.1.16.14): icmp_seq=32. time=11008. ms
64 bytes from test1 (10.1.16.14): icmp_seq=33. time=10009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=34. time=9009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=35. time=8009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=36. time=7008. ms
64 bytes from test1 (10.1.16.14): icmp_seq=37. time=6009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=38. time=5009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=39. time=4009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=40. time=3009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=41. time=2009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=42. time=1009. ms
64 bytes from test1 (10.1.16.14): icmp_seq=63. time=3. ms
Here's the network traffic according to snoop, on the Solaris x86
ping source:
1 0.00000 host -> test1 ICMP Echo request
2 0.99525 host -> test1 ICMP Echo request
3 0.99984 host -> test1 ICMP Echo request
4 0.99997 host -> test1 ICMP Echo request
5 0.99999 host -> test1 ICMP Echo request
6 1.00014 host -> test1 ICMP Echo request
7 0.99985 host -> test1 ICMP Echo request
8 1.00000 host -> test1 ICMP Echo request
9 1.00002 host -> test1 ICMP Echo request
10 0.99997 host -> test1 ICMP Echo request
11 1.00029 host -> test1 ICMP Echo request
12 1.00042 host -> test1 ICMP Echo request
13 0.99928 host -> test1 ICMP Echo request
14 0.99999 host -> test1 ICMP Echo request
15 1.00000 host -> test1 ICMP Echo request
16 1.00013 host -> test1 ICMP Echo request
17 1.00032 host -> test1 ICMP Echo request
18 0.99956 host -> test1 ICMP Echo request
19 0.99997 host -> test1 ICMP Echo request
20 1.00000 host -> test1 ICMP Echo request
21 1.00018 host -> test1 ICMP Echo request
22 0.99983 host -> test1 ICMP Echo request
23 0.99998 host -> test1 ICMP Echo request
24 1.00000 host -> test1 ICMP Echo request
25 1.00000 host -> test1 ICMP Echo request
26 1.00076 host -> test1 ICMP Echo request
27 0.00079 test1 -> host ICMP Echo reply
28 0.00026 test1 -> host ICMP Echo reply
29 0.00016 test1 -> host ICMP Echo reply
30 0.00014 test1 -> host ICMP Echo reply
31 0.00014 test1 -> host ICMP Echo reply
32 0.00014 test1 -> host ICMP Echo reply
33 0.00014 test1 -> host ICMP Echo reply
34 0.00014 test1 -> host ICMP Echo reply
35 0.00014 test1 -> host ICMP Echo reply
36 0.00014 test1 -> host ICMP Echo reply
37 0.00014 test1 -> host ICMP Echo reply
38 0.00014 test1 -> host ICMP Echo reply
39 0.00015 test1 -> host ICMP Echo reply
40 0.00014 test1 -> host ICMP Echo reply
41 0.00014 test1 -> host ICMP Echo reply
42 0.00015 test1 -> host ICMP Echo reply
43 0.00015 test1 -> host ICMP Echo reply
44 0.00015 test1 -> host ICMP Echo reply
45 0.00016 test1 -> host ICMP Echo reply
46 0.00015 test1 -> host ICMP Echo reply
47 0.00015 test1 -> host ICMP Echo reply
48 0.00016 test1 -> host ICMP Echo reply
49 0.00015 test1 -> host ICMP Echo reply
50 0.00015 test1 -> host ICMP Echo reply
51 0.00015 test1 -> host ICMP Echo reply
52 0.00016 test1 -> host ICMP Echo reply
Thanks,
J
-
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/