On 28 Jan 2002, Justin A wrote:
> Ok, it was working for a while, even after a reboot...
> but now
> 21:04:33 up 2 days, 20 min, 10 users, load average: 0.12, 0.47, 0.38
>
> Jan 28 01:39:10 bouncybouncy kernel: eth0: Transmitter underflow?,
> status 2008.
This is not a transmit underflow (I was lazy when adding that message,
this is what the ? is about). It is a transmit abort caused by excessive
collisions.
2000 - transmit abort because of excessive collisions
0008 - transmit error
It is interesting that the linuxfet driver does not fail/recovers. I have
added some more code from that driver and attached a new version of the
patch. It re-initializes the ring pointer and tells the card to try to
transmit the packet again.
> Jan 28 20:26:06 bouncybouncy kernel: eth0: reset finished after 10005
> microseconds.
The "You have reset me too many times. Go away." error.
> After reloading the driver it started working again:
>
> linuxfet.c : v3.23 05/15/2001
> The PCI BIOS has not enabled the device at 0/144! Updating PCI
> command 0003->0007.
> eth0: VIA PCI 10/100Mb Fast Ethernet Adapter
> eth0: IO Address = 0xe800, MAC Address = 00:50:2c:01:64:a9, IRQ = 11.
> eth0: MII PHY found at address 1, status 0x782d advertising 01e1 Link
> 0021.
> eth0: netdev_open() irq 11.
> eth0: Done netdev_open(), status 881a MII status: 782d.
0003->0007 is that it turns on bus mastering. I have copied the code from
the linuxfet driver that sets that bit. But for me that is set later by
the pci_set_master function, and I think the warning is incorrect.
After reloading the linuxfet driver, does the via-rhine driver work better
if you switch back to it without rebooting?
> I think that last message might be a clue on why this is happening...
Which message are you refering to? I don't feel particularly clueful after
reading any of it. :)
/Urban
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:06 EST