[eepro100] kernel: eepro100: wait_for_cmd_done timeout!
anderson@facstaff.wisc.edu
anderson@facstaff.wisc.edu
Wed Jan 9 08:52:02 2002
Morten Primdahl <morten@caput.com>:
> Hi folks, the following snippet from /var/log/message is the last
> I get before the machine (RH7.2 kernel 2.4.17) seemingly freezes:
>
> Jan 8 15:59:07 job2000 kernel: eepro100: wait_for_cmd_done timeout!
> Jan 8 15:59:21 job2000 last message repeated 25 times
> Jan 8 15:59:24 job2000 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jan 8 15:59:24 job2000 kernel: eth0: Transmit timed out: status 0050
> 0c80 at 312/340 command 200c0000.
> Jan 8 16:13:16 job2000 kernel: eepro100: wait_for_cmd_done timeout!
> Jan 8 16:13:30 job2000 last message repeated 9 times
>
> I've browsed around, and it seems that the eepro100 driver is to blame,
> and that the recommended fix is to use the driver supplied by Intel at
>
> <url:http://downloadfinder.intel.com//scripts-df/Detail_Desc.asp?strState=LIVE&ProductID=583&DwnldID=2896>
>
> Is this correct? Or should I ignore that I'm RH7,2 w. 2.4.17 and go with
> the instructions from http://www.scyld.com/network/updates.html?
>
> Any tips appreciated - thanks,
I'm in much the same boat. The machine is a new IBM A30 laptop,
RH 7.2 (2.4.7), 933 MHz P3, 256MB ram. I'm not a kernel hacker,
still less a driver hacker. As far as I can tell, this timeout
message from the eepro100 driver does not necessarily hang the
network. Sometimes, after a short delay, things get going again.
But sometimes they don't. After it hangs, ifconfig still shows
the interface as up. Another small clue is that thanks to some
TTL or other, it sometimes works to restart the network if you
do it soon enough (/etc/init.d/network restart). A partially
completed transfer might then continue where it left off. Or it
might not.
Another *possible* clue is that fragmentation or timing problems
might be involved. The problem seems to arise when network traffic
(always inbound, as far as I know) is heavy and the file is large,
the packet arrival rates varies over a big range. When the transfer
is in this jerky mode, sometimes I see a whole flock of packets
arrive more or less simultaneously.
None of this is much help, I suspect. I'm pretty much dependent
on getting a binary version of the driver in module form that
that solves my problem, but of course any and all help or advice
is welcome.
TIA
--
[] If you were arrested, would you get down on your knees and
[] gratefully thank the cop for not beating you to death as
[] well?
[] -- Clay Bond
[] anderson@facstaff.wisc.edu <http://www.jessanderson.org/> []
[] Copyright 2002 Jess Anderson madison.wi.us []