2003-02-27 16:46:04

by Paul Rolland

[permalink] [raw]
Subject: eepro100: wait_for_cmd_done timeout

Hello,

We have a server that has gone thru that :
21:30:02.231737 rms-01 network: Result 0 for gateway 192.168.0.254
Feb 26 21:30:29 rms-01 Feb 26 21:30:29:517449 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 26 21:30:30 rms-01 Feb 26 21:30:30:514068 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 26 21:30:30 rms-01 Feb 26 21:30:30:514094 kernel: eepro100:
wait_for_cmd_don
e timeout!
...
Feb 27 13:48:15 rms-01 Feb 27 13:48:15:940827 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 27 13:48:16 rms-01 Feb 27 13:48:16:940946 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 27 13:48:20 rms-01 Feb 27 13:48:20:766987 kernel: NETDEV WATCHDOG:
eth0: tra
nsmit timed out
Feb 27 13:48:20 rms-01 Feb 27 13:48:20:767007 kernel: eth0: Transmit
timed out:
status 0090 0c80 at 162209/162269 command 000ca000.
Feb 27 13:48:20 rms-01 Feb 27 13:48:20:842320 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 27 13:48:20 rms-01 Feb 27 13:48:20:842333 kernel: eepro100:
wait_for_cmd_don
e timeout!
Feb 27 13:50:01 rms-01 Feb 27 13:50:01:30726 kernel: eepro100:
wait_for_cmd_done
timeout!

The only way to get it out of that is a reboot...
The kernel is a 2.4.19 and dmesg says :
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.
html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@sa
w.sw.com.sg> and others
eth0: OEM i82557/i82558 10/100 Ethernet, 00:06:5B:39:69:2B, IRQ 16.
Board assembly 02d484-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
eth1: OEM i82557/i82558 10/100 Ethernet, 00:06:5B:39:69:2C, IRQ 17.
Board assembly 02d484-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).

Anyone knows why ?

Regards,
Paul


2003-02-27 20:20:01

by Andrey Nekrasov

[permalink] [raw]
Subject: Re: eepro100: wait_for_cmd_done timeout

Hello Paul Rolland,

> Feb 27 13:50:01 rms-01 Feb 27 13:50:01:30726 kernel: eepro100:
> wait_for_cmd_done
> timeout!
>
> eth0: OEM i82557/i82558 10/100 Ethernet, 00:06:5B:39:69:2B, IRQ 16.
> Board assembly 02d484-000, Physical connectors present: RJ45
> Primary interface chip i82555 PHY #1.
> General self-test: passed.
> Serial sub-system self-test: passed.
> Internal registers self-test: passed.
> ROM checksum self-test: passed (0x04f4518b).
> Anyone knows why ?

try update bios on motherboard.
i am use INTEL STL2 and after update bios to last version network card work ok

--
Any statement is incorrect.

2003-02-28 06:40:12

by Paul Rolland

[permalink] [raw]
Subject: Re: eepro100: wait_for_cmd_done timeout

Hello,

> Hello Paul Rolland,
>
> > Feb 27 13:50:01 rms-01 Feb 27 13:50:01:30726 kernel: eepro100:
> > wait_for_cmd_done timeout!
> >
> > eth0: OEM i82557/i82558 10/100 Ethernet, 00:06:5B:39:69:2B, IRQ 16.
> > Board assembly 02d484-000, Physical connectors present: RJ45
> > Primary interface chip i82555 PHY #1.
> > General self-test: passed.
> > Serial sub-system self-test: passed.
> > Internal registers self-test: passed.
> > ROM checksum self-test: passed (0x04f4518b).
> > Anyone knows why ?
>
> try update bios on motherboard.
> i am use INTEL STL2 and after update bios to last version
> network card work ok

Thanks for the suggestion...
I got another one, telling me to have a look at the e100 driver,
and this raises a question I have for quite a long time : why does
the Kernel have two different supports for the same hardware ?
Is this a migration plan, a long run "please switch from eepro100
to e100" ?
Is there a better working one ?

I don't say that, once a driver exists, no one should ever think
of doing another one, but there are little indication as to which
one people should select...

Quite puzzling ;-)

Regards,
Paul

2003-03-28 17:30:20

by Chris Bacott

[permalink] [raw]
Subject: Re: eepro100: wait_for_cmd_done timeout

> Thanks for the suggestion...
> I got another one, telling me to have a look at the e100 driver,
> and this raises a question I have for quite a long time : why does
> the Kernel have two different supports for the same hardware ?
> Is this a migration plan, a long run "please switch from eepro100
> to e100" ?
> Is there a better working one ?
>
Becuase, IIRC, eepro100 is the original EtherExpress100 Nic driver written by
Becker. the e100 Driver is written initially by Intel, and is a obviously
newer. Question is, would you want to use a driver written by the
manufacturer of the chip itself, or use a driver that has been in use for
MANY years, and has been proven solid. I have an eepro in my laptop, and I
just bought two IBM Etherjet NICs, all use this chip. I'm currently using the
eepro100 driver, as thats the one I've used for years, but from what I've
seen. e100 is going to be the one actively updated, as its Intel's driver.
This is the info I got from the IBM and Intel site when I was looking up
whether those Etherjet cards were supported in Linux before I bought them.

If any of the above is wrong, some one *please* correct me. I'd rather be told
I'm wrong rather than be wrong and thinking I'm right.

--
Chris Bacott

2003-03-28 17:48:11

by Jeff Garzik

[permalink] [raw]
Subject: Re: eepro100: wait_for_cmd_done timeout

On Fri, Mar 28, 2003 at 11:42:00AM +0000, Chris Bacott wrote:
> > Thanks for the suggestion...
> > I got another one, telling me to have a look at the e100 driver,
> > and this raises a question I have for quite a long time : why does
> > the Kernel have two different supports for the same hardware ?
> > Is this a migration plan, a long run "please switch from eepro100
> > to e100" ?
> > Is there a better working one ?
> >
> Becuase, IIRC, eepro100 is the original EtherExpress100 Nic driver written by
> Becker. the e100 Driver is written initially by Intel, and is a obviously
> newer. Question is, would you want to use a driver written by the
> manufacturer of the chip itself, or use a driver that has been in use for
> MANY years, and has been proven solid.

This statement is utterly ridiculous, considering that the poster is
having problems with the eepro100 driver. It is obviously, provably
_NOT_ solid.

In Red Hat's experience, some people find eepro100 very stable for
them, some people find e100 very stable for them. There is no driver
which is 100% stable for all people at all times.

Jeff