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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
