I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't
seen any - that's why I hadn't updated. I gather that the change in question
is at a higher level?
Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages:
Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010,
CSR12
00000000, resetting...
but instead of hanging completely the connection just gets extremely slow
and "bursty" as shown by the following fragment of ping output:
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255
time=130 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255
time=358 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255
time=6.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255
time=12.001 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255
time=1.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255
time=368 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255
time=361 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255
time=395 usec
So the behavior is quite a bit better (at least I can telnet in to
ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work OK.
Thanks!
-- Manuel A. McLure - Unify Corp. Technical Support <mmt@unify.com> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good.""Jeff Garzik" wrote: > "Manuel A. McLure" wrote: > > > > System: > > AMD Athlon Thunderbird 900MHz > > MSI K7T Pro (VIA KT133 chipset) > > Network card: Linksys LNE100TX Rev. 4.0 (tulip) > > Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, > 2.4.2, 2.4.2-ac11 > > > > With all the above kernel revisions/drivers, my network > card hangs at random > > (sometimes within minutes, other times it takes days). To > restart it I need > > to do an ifdown/ifup cycle and it will work fine until the > next hang. I > > upgraded to 2.4.2-ac11 because of the documented tulip > fixes, but after a > > few days got this again. The error log shows: > > In Alan Cox terms, that's a long time ago :) > > Can you please try 2.4.2-ac20? It includes fixes > specifically for this > problem.
I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't seen any - that's why I hadn't updated. I gather that the change in question is at a higher level?
Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages:
Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting...
but instead of hanging completely the connection just gets extremely slow and "bursty" as shown by the following fragment of ping output:
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255 time=130 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255 time=358 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255 time=6.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255 time=12.001 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255 time=1.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255 time=368 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255 time=361 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255 time=395 usec
So the behavior is quite a bit better (at least I can telnet in to ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work fine until the problem starts again.
Thanks! -- Manuel A. McLure - Unify Corp. Technical Support <mmt@unify.com> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:15 EST