VIA Rhine problem in 2.4.9-pre4

It seem that my built-in ethernet NIC has either gone bad, or the 2.4.9-pre4 drivers are bad. It only seems to happen with this one machine, so it could be hardware. The symptom is that the NIC looses the ability to transmit. It does receive pkts OK (ie it received an ARP request from my other machine, and answered according to tcpdump, but the pkt was never put on the wire it seems.

Here is a snippet of the dmesg:

eth0: VIA VT2043 Rhine at 0xe000, 00:50:08:00:35:c6, IRQ 11.
eth0: MII PHY found at address 1, status 0x782d advertising 05e1 Link 0021

This last time it happened, I noticed this printed to the console:

eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x9 length 0 status 00000600
eth0: Oversized Ethernet frame c7572090 vs c7572090.

I looked at /proc/net/dev and didn't see too many errors (there were a few, though, including carrier errors). I tried replacing the cable but that did not fix the problem. The link does come back up after reboot...

Thanks,
Ben

Ben Greear <[email protected]>          <[email protected]>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

I can't answer what this is, but I can point you to a prevous discussion on the subject:

    http://uwsg.iu.edu/hypermail/linux/net/0006.1/0005.html

I assume that this is not a problem that you only get on 2.4.9-pre4, but on any kernel version you try?

Drivers for other cards have also reported this (search on google).

Donald Beckers answer to a question on this subject:

    http://uwsg.iu.edu/hypermail/linux/net/9801.1/0159.html

Does unloading the modules and then reloading it help? (assuming you run it as a module). ifconfig down/up is another variant some people have used for other problems.

/Urban

I believe the problem was that my program that reads information out of the drivers (IP, mask, MTU, QLEN, and the MII-diag flags) was in a very tight loop, and so was almost constantly trying to read the information.

I fixed that problem, and haven't seen the NIC lock up since. If I get a chance, I'm going to make a stand-alone GPL version of that code, and when I do I'll add an option to stress the kernel/drivers and see if I can reproduce this NIC lockup.

Thanks,
Ben

ifup/down didn't help, but I didn't try reloading the module.

Ben Greear <[email protected]>          <[email protected]>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Ah ...

Reading the MII in the driver is done while holding the driver lock, so there could definitly be some interaction with the xmit. That was suggested before, but I couldn't see how.

Or it could just be that if someone does mdio things at the wrong time the chip gets "confused".

I for one would be interested in an isolated testcase of this failure, GPL or otherwise, and see if I can trigger this on my machines.

/Urban