On Sun, 26 Aug 2001, Ben Greear wrote:
> 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.
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 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.
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
-
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 Aug 31 2001 - 21:00:22 EST