> 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!)
I don't think this is a X11 specific problem because today i ran into
a similar problem. Well, it doesn't have to do with X11 screen blanking
(screen wasn't blank) or a monitor power save feature (don't have such
thing).
Kernel is 2.2.0-pre7 SMP, gcc-2.7.2.3 compiled, machine is a dual
PentiumPro-180, 64MB RAM Ethernet is an onboard AMD PCnet/PCI-II 79C970A
connect with coax to only one machine and managed by `lance.c'. The card
became unusable after 2h uptime while a PPP connection to my provider was
running and another Linux PC was connected via eth0. This client runs Linux
2.0.33 and gets its root filesystem via NFS.
The kernel log is filled with
Jan 16 18:46:12 nomad kernel: eth0: Tx FIFO error! Status a2e2.
Another way to trigger these messages is to run the X11 version of the
Super Nintendo Emulator from www.snes9x.com.
The behaviour of the pcnet32.c driver (same computer) is even worse. When
eth0 and a PPP connection or `x11perf -a' is running the kernel log is
filled with
Jan 15 19:34:34 nomad kernel: eth0: transmit timed out, status 0063, resetting.
With Linux 2.1.105 it wasn't even necessary to start an PPP connection to
get these messages. A way to reduce these messages then was to set the Tx
timeout from 20 to 500.
2.0.33 had no such problems as far as I've seen.
Hope this helps,
Mark
+-----------------------------------------------------+----------------------+
| the wizard himself, Mark-André Hopf | Every sufficiently |
| hopf@informatik.uni-rostock.de | developed technology |
| Visit the TOAD GUI Toolkit Project Homepage at | is indistinguishable |
| http://toad.home.pages.de/ | from magic. (A.C.C.) |
+-----------------------------------------------------+----------------------+
-
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/