Re: eepro100 lockup after months of no problems (v1.06, 2.2.10ac5)

Miquel van Smoorenburg (miquels@cistron.nl)
Mon, 29 Nov 1999 11:35:38 +0100


According to Simon Kirby:
> Nov 28 20:31:15 worf kernel: eth1: Transmit timed out: status 0050 0080 at -816260625/-816260610 command 000c0000.
> Nov 28 20:31:15 worf kernel: eth1: Trying to restart the transmitter...

Oh yes this looks veerrry similar to what I am seeing. If you check out
the eepro100 mailing list archive you'll see that a lot of people are
in the same boat.

> Removing and reinserting the eepro100 module (remotely) seemed to have
> fixed it. This is the output I get when inserting the module:

That is the work around I'm using as well, automated by a script.

> If this is a known problem, please, let me know! I've never seen it
> before on any servers, which is odd. Nothing has changed for months that
> would have caused this, except perhaps gradually increasing load.

There's your problem. It seems that the eepro100 (and the tulip and
the epic100) drivers lock up under load especially when memory gets tight.

If you check out the threads of the last week about "bug in tulip_rx"
you'll see that a lot of Donald's drivers seem to share the same
problem and that it is reasonably easily solved.

For the eepro100, a pointer to an updated driver was posted here 2
days ago by Savochkin Andrey Vladimirovich <saw@msu.ru> with subject
"Re: NFS Client in 2.2.13 (eepro100 problem)". His driver is at

ftp://ftp.nc.orc.ru/pub/Linux/people/saw/kernel/eepro100.c
ftp://ftp.nc.orc.ru/pub/Linux/people/saw/kernel/eepro100.changelog

I've been using this driver since saturday. I used to get a lockup
every two hours, with this driver I haven't had _any_ lockups in
two days (and still counting).

Here's the patch you need to use the driver with 2.2.x :

--- eepro100.c.andrey Mon Nov 29 11:28:18 1999
+++ eepro100.c Sat Nov 27 14:23:26 1999
@@ -130,6 +130,10 @@
#define virt_to_le32desc(addr) cpu_to_le32(virt_to_bus(addr))
#define le32desc_to_virt(addr) bus_to_virt(le32_to_cpu(addr))

+#if LINUX_VERSION_CODE < 0x020314
+# define net_device device
+#endif
+
#define dev_free_skb(skb) dev_kfree_skb(skb);
#if ! defined(HAS_NETIF_QUEUE)
#define netif_wake_queue(dev) mark_bh(NET_BH);
@@ -565,9 +569,14 @@
{
struct pci_dev *pdev = pci_find_slot(pci_bus, pci_device_fn);
#ifdef USE_IO
- pciaddr = pdev->resource[1].start; /* Use [0] to mem-map */
+ int elem = 1; /* IO */
+#else
+ int elem = 0; /* memory mapped */
+#endif
+#if LINUX_VERSION_CODE >= 0x020314
+ pciaddr = pdev->resource[elem].start;
#else
- pciaddr = pdev->resource[0].start;
+ pciaddr = pdev->base_address[elem];
#endif
irq = pdev->irq;
}

-- 
First things first, but not necessarily in that order.

- 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/