lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectLance 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.127 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site