Messages in this thread | | | Date | Thu, 14 Jan 1999 12:15:05 -0500 (EST) | From | William Earnest <> | Subject | Lance driver sick with 2.2.0-prex changes |
| |
Hello,
It appears the patches in .132, pre1 and pre2 to the lance ether driver are interacting badly with something else, possibly the X screen blanking or monitor power save feature. System is a P-200, 64 MB, IDE and SCSI disks, etc. Ether card is Allied Telesys AT1500 connected to thin coax net of 6 machines, mix of Linux and Win95. Kernels up thru 2.1.131 have been running with no problem at all for some time. Using Redhat 5.2 except for kernel, a few old applications, and most current updates of various utilities, including net-tools. Ifconfig mentioned below is 1.35 from tools 1.46, have moved to tools 1.49 but no data yet.
Currently at pre6, but problem started several steps before. System boots normally, and network is OK. As long as it is used, continues to work, and ifconfig numbers are good (no errors). If I leave for a while, say 30 minutes or more, I return to a dead network interface. Ifconfig shows a large error count on the receive line. Any attempt to ping another machine shows occasional packets, usually in groups of 3, and then a bunch of spurious responses as if a buffer was being misread. During this time, the other machines are normal and can talk with each other normally. See below for a ping sample.
PING trix.wde.fast.net (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=8 ttl=255 time=1.3 ms 64 bytes from 192.168.1.3: icmp_seq=9 ttl=255 time=0.8 ms 64 bytes from 192.168.1.3: icmp_seq=10 ttl=255 time=1.1 ms 64 bytes from 192.168.1.3: icmp_seq=18 ttl=255 time=1.0 ms 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1005.0 ms 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1008.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1012.3 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1015.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1019.3 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1023.0 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=17 ttl=255 time=1026.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=31 ttl=255 time=0.8 ms 64 bytes from 192.168.1.3: icmp_seq=32 ttl=255 time=0.8 ms 64 bytes from 192.168.1.3: icmp_seq=33 ttl=255 time=0.8 ms 64 bytes from 192.168.1.3: icmp_seq=34 ttl=255 time=1.2 ms 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4005.3 ms 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4009.0 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4012.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4016.2 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4019.9 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4023.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4026.9 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4030.6 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4034.3 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4037.9 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4041.3 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=30 ttl=255 time=4045.0 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=42 ttl=255 time=0.9 ms 64 bytes from 192.168.1.3: icmp_seq=43 ttl=255 time=0.8 ms 64 bytes from 192.168.1.3: icmp_seq=44 ttl=255 time=1.1 ms 64 bytes from 192.168.1.3: icmp_seq=41 ttl=255 time=3005.1 ms 64 bytes from 192.168.1.3: icmp_seq=41 ttl=255 time=3008.7 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=41 ttl=255 time=3012.3 ms (DUP!) 64 bytes from 192.168.1.3: icmp_seq=41 ttl=255 time=3012.7 ms (DUP!) .....etc. I usually run X, and tried kicking the interface with ifconfig. A down command appears to succeed, the eth0 listing disappears from its report. An attempt to "ifconfig eth0 up" hangs the command, and cpu load goes to 100%. Even kill -9 won't stop ifconfig, but I can recover by shutting down X. Now the ifconfig up works from a normal console. Had been using the 3.3.3 release of X, so backed down to 3.2, and seemed a bit better, but still failed overnight.
If I stop X, ifconfig down and up restore network to normal. With X running, cannot ifconfig up even from a non-X console. But why should X be tangled with a low-level ethernet driver?
Would appreciate pointers to any fixes, or suggestions on further tests to run. No problem making changes here to isolate the bug, if someone can give a little guidance. TIA.
Bill Earnest wde@fast.net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open.
- 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/
| |