eepro100: wait_for_cmd_done timeout

eepro100: wait_for_cmd_done timeout

[Dionysius Wilson Almeida]

Hi,

I'm running Linux 2.4.5 from kernel.org on my Sony VAIO PCG-FX140 notebook.
I'm runing it on Debian Sid.  The problem i'm facing is that the ethernet card
hangs after every 2 minutes or so and this is consistent.  I've to bring down
the interface and bring it back up and then it works for another 2 minutes 
before freezing.

When i run Redhat 7.1 using redhat supplied intel's e100 driver, everything
works fine.  I tried compiling and loading this driver under Debian, but it
does not work (i.e. does not recognize any adapter).

I tried downloading the e100 driver from Intel site and loading that too..
but that too loads but does not find my adapter.  Further the sources which
came with redhat 7.1 does not compile under Debian Sid.

I tried looking for specific info but i've not been sucessful so far.

Here's what lspci outputs :
00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 11)
00:02.0 VGA compatible controller: Intel Corporation: Unknown device 1132 (rev 11)
00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03)
00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03)
00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03)
00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03)
00:1f.3 SMBus: Intel Corporation 82820 820 (Camino 2) Chipset SMBus (rev 03)
00:1f.4 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 03)
00:1f.6 Modem: Intel Corporation: Unknown device 2446 (rev 03)
01:00.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8021 (rev 02)
01:02.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
01:02.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
01:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 03)


And this is the log when the card hangs :
=========================================
Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050  0c80 at 314/342 command 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump,  Tx queue 342 / 314:
Jun 20 16:10:18 debianlap kernel: eth0:     0 200c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     1 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     2 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     3 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     4 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     5 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     6 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     7 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     8 200c0000.
Jun 20 16:10:18 debianlap kernel: eth0:     9 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    10 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    11 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    12 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    13 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    14 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    15 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    16 200c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    17 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    18 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    19 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    20 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    21 400c0000.
Jun 20 16:10:18 debianlap kernel: eth0:   =22 000ca000.
Jun 20 16:10:18 debianlap kernel: eth0:    23 000ca000.
Jun 20 16:10:18 debianlap kernel: eth0:    24 200ca000.
Jun 20 16:10:18 debianlap kernel: eth0:    25 000ca000.
Jun 20 16:10:18 debianlap kernel: eth0:  * 26 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    27 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    28 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    29 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    30 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0:    31 000c0000.
Jun 20 16:10:18 debianlap kernel: eth0: Printing Rx ring (next to receive into 977, dirty index 977).
Jun 20 16:10:18 debianlap kernel: eth0:     0 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     1 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     2 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     3 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     4 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     5 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     6 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     7 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     8 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:     9 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    10 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    11 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    12 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    13 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    14 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    15 00000001.
Jun 20 16:10:18 debianlap kernel: eth0: l  16 c0000001.
Jun 20 16:10:18 debianlap kernel: eth0:  *=17 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    18 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    19 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    20 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    21 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    22 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    23 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    24 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    25 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    26 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    27 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    28 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    29 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    30 00000001.
Jun 20 16:10:18 debianlap kernel: eth0:    31 00000001.
Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
Jun 20 16:14:38 debianlap last message repeated 5 times

-Wilson

-- 
We'll try to cooperate fully with the IRS, because, as citizens, we feel
a strong patriotic duty not to go to jail.
		-- Dave Barry

Re: eepro100: wait_for_cmd_done timeout

[Andrey Savochkin]

What was the first error message from the driver?
NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more
important.  I wonder if you had some other messages before the watchdog one.

	Andrey

On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote:
> And this is the log when the card hangs :
> =========================================
> Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050  0c80 at 314/342 command 000c0000.
> Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump,  Tx queue 342 / 314:
> Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> Jun 20 16:14:38 debianlap last message repeated 5 times

Re: eepro100: wait_for_cmd_done timeout

[Dionysius Wilson Almeida]

No..that was pretty much what i saw in the logs.

I see wait_for_cmd_done timeout being the only one being repeated in the
logs

-Wilson
`
* Andrey Savochkin (saw@saw.sw.com.sg) wrote:
> What was the first error message from the driver?
> NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more
> important.  I wonder if you had some other messages before the watchdog one.
> 
> 	Andrey
> 
> On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote:
> > And this is the log when the card hangs :
> > =========================================
> > Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050  0c80 at 314/342 command 000c0000.
> > Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump,  Tx queue 342 / 314:
> > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > Jun 20 16:14:38 debianlap last message repeated 5 times

-- 
Eat shit -- billions of flies can't be wrong.

Re: eepro100: wait_for_cmd_done timeout

[Rafael Martinez]

---Reply to mail from Dionysius Wilson Almeida about eepro100: wait_for_cmd_done timeout
> No..that was pretty much what i saw in the logs.
> 
> I see wait_for_cmd_done timeout being the only one being repeated in the
> logs
> 

The same here with 2.4.1 and 2.4.3.

Rafael Martinez

Re: eepro100: wait_for_cmd_done timeout

[Masaru Kawashima]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

Hi!

On Wed, 20 Jun 2001 16:31:34 -0700
Dionysius Wilson Almeida <Dionysius Wilson Almeida <dwilson@technolunatic.com>> wrote:
> Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> Jun 20 16:14:38 debianlap last message repeated 5 times

I saw the same message.

The comment before wait_for_cmd_done() function in
linux/drivers/net/eepro100.c says:
/* How to wait for the command unit to accept a command.
   Typically this takes 0 ticks. */

And the initial value for the bogus counter, named "wait", is 1000.
Is it enough for your machine?

I applied attached patch, eepro100.patch.  After that, I've never seen
the message from wait_for_cmd_done().  And, my NIC works fine.

You may want to adjust the initial value for the bogus counter.
I don't know the appropriate value for this bogus counter.

I hope this helps you.

-- 
Masaru Kawashima

[-- Attachment #2: eepro100.patch --]
[-- Type: application/octet-stream, Size: 386 bytes --]

--- linux-2.4.5/drivers/net/eepro100.c.org	Wed Feb 14 06:15:05 2001
+++ linux-2.4.5/drivers/net/eepro100.c	Thu Jun 21 16:33:00 2001
@@ -310,7 +310,9 @@
 {
 	int wait = 1000;
 	do   ;
-	while(inb(cmd_ioaddr) && --wait >= 0);
+	while(inb(cmd_ioaddr) && --wait >= 0){
+		udelay(1);
+	}
 #ifndef final_version
 	if (wait < 0)
 		printk(KERN_ALERT "eepro100: wait_for_cmd_done timeout!\n");

Re: eepro100: wait_for_cmd_done timeout

[John Madden]

> Dionysius Wilson Almeida <Dionysius Wilson Almeida <dwilson@technolunatic.com>> wrote:
> > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > Jun 20 16:14:38 debianlap last message repeated 5 times
> 
> I saw the same message.
> 
> The comment before wait_for_cmd_done() function in
> linux/drivers/net/eepro100.c says:
> /* How to wait for the command unit to accept a command.
>    Typically this takes 0 ticks. */
> 
> And the initial value for the bogus counter, named "wait", is 1000.
> Is it enough for your machine?
> 
> I applied attached patch, eepro100.patch.  After that, I've never seen
> the message from wait_for_cmd_done().  And, my NIC works fine.
> 
> You may want to adjust the initial value for the bogus counter.
> I don't know the appropriate value for this bogus counter.

int wait is set to 20000 in my eepro100.c (stock 2.2.19), and I still get these
errors.  Think the patch with the udelay() will still work?

John




-- 
John Madden
UNIX Systems Engineer
Ivy Tech State College
jmadden@ivy.tec.in.us

Re: eepro100: wait_for_cmd_done timeout

[Masaru Kawashima]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

Hi, again!
I'ts me, Masaru Kawashima, from home.

I'm sorry I made a stupid mistake last time!
This time, I promise you that I attach the proper patch for
linux/drivers/net/eepro100.c.  (running version)

On Thu, 21 Jun 2001 23:19:39 +0900
Masaru Kawashima <Masaru Kawashima <masaru@scji.toshiba-eng.co.jp>> wrote:

> Hi!
> 
> On Wed, 20 Jun 2001 16:31:34 -0700
> Dionysius Wilson Almeida <Dionysius Wilson Almeida <dwilson@technolunatic.com>> wrote:
> > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > Jun 20 16:14:38 debianlap last message repeated 5 times
> 
> I saw the same message.
> 
> The comment before wait_for_cmd_done() function in
> linux/drivers/net/eepro100.c says:
> /* How to wait for the command unit to accept a command.
>    Typically this takes 0 ticks. */
> 
> And the initial value for the bogus counter, named "wait", is 1000.
> Is it enough for your machine?
> 
> I applied attached patch, eepro100.patch.  After that, I've never seen
> the message from wait_for_cmd_done().  And, my NIC works fine.
> 
> You may want to adjust the initial value for the bogus counter.
> I don't know the appropriate value for this bogus counter.
> 
> I hope this helps you.
> 
> -- 
> Masaru Kawashima

--
Masaru Kawashima

[-- Attachment #2: eepro100.correct.patch --]
[-- Type: text/plain, Size: 441 bytes --]

--- linux-2.4.5/drivers/net/eepro100.c.org	Fri May 25 18:59:03 2001
+++ linux-2.4.5/drivers/net/eepro100.c	Fri Jun 22 00:55:03 2001
@@ -309,8 +309,9 @@
 static inline void wait_for_cmd_done(long cmd_ioaddr)
 {
 	int wait = 1000;
-	do   ;
-	while(inb(cmd_ioaddr) && --wait >= 0);
+	while(inb(cmd_ioaddr) && --wait >= 0){
+		udelay(1);
+	}
 #ifndef final_version
 	if (wait < 0)
 		printk(KERN_ALERT "eepro100: wait_for_cmd_done timeout!\n");

Re: eepro100: wait_for_cmd_done timeout

[Masaru Kawashima]

On Thu, 21 Jun 2001 09:37:47 -0500
John Madden <jmadden@ivy.tec.in.us> wrote:
> errors.  Think the patch with the udelay() will still work?

In my system, the patch with the udelay() is working.

--
Masaru Kawashima

Re: eepro100: wait_for_cmd_done timeout

[Dionysius Wilson Almeida]

I tried inserting a udelay(1) and increasing the count ..but
the same behaviour.  

any clues ? btw, i've been able to compile the redhat 7.1 intel e100
driver and it works fine for my card.

-Wilson

* Dionysius Wilson Almeida (dwilson@technolunatic.com) wrote:
> No..that was pretty much what i saw in the logs.
> 
> I see wait_for_cmd_done timeout being the only one being repeated in the
> logs
> 
> -Wilson
> `
> * Andrey Savochkin (saw@saw.sw.com.sg) wrote:
> > What was the first error message from the driver?
> > NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more
> > important.  I wonder if you had some other messages before the watchdog one.
> > 
> > 	Andrey
> > 
> > On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote:
> > > And this is the log when the card hangs :
> > > =========================================
> > > Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > > Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050  0c80 at 314/342 command 000c0000.
> > > Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump,  Tx queue 342 / 314:
> > > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > > Jun 20 16:14:38 debianlap last message repeated 5 times
> 
> -- 
> Eat shit -- billions of flies can't be wrong.
> -
> 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/

-- 
Fortune's Office Door Sign of the Week:

	Incorrigible punster -- Do not incorrige.

Re: eepro100: wait_for_cmd_done timeout

[Andrey Savochkin]

On Thu, Jun 21, 2001 at 06:36:03PM -0700, Dionysius Wilson Almeida wrote:
> I tried inserting a udelay(1) and increasing the count ..but
> the same behaviour.  
> 
> any clues ? btw, i've been able to compile the redhat 7.1 intel e100
> driver and it works fine for my card.

Your problem is different from anyone else's, as I explained.
You see "netdev watchdog" message first.
It means that the card just stopped to transmit packets.
All other messages printed after that, including wait_for_cmd_done timeout,
are irrelevant to this problem.  Your card just doesn't transmit.

Please send me a complete log of what the kernel prints, since powering up
the computer.

	Andrey

Re: eepro100: wait_for_cmd_done timeout

[Dionysius Wilson Almeida]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

Hi Andrey,

I'm attaching the log file.. please let me know if u need other
details.

-Wilson

* Andrey Savochkin (saw@saw.sw.com.sg) wrote:
> On Thu, Jun 21, 2001 at 06:36:03PM -0700, Dionysius Wilson Almeida wrote:
> > I tried inserting a udelay(1) and increasing the count ..but
> > the same behaviour.  
> > 
> > any clues ? btw, i've been able to compile the redhat 7.1 intel e100
> > driver and it works fine for my card.
> 
> Your problem is different from anyone else's, as I explained.
> You see "netdev watchdog" message first.
> It means that the card just stopped to transmit packets.
> All other messages printed after that, including wait_for_cmd_done timeout,
> are irrelevant to this problem.  Your card just doesn't transmit.
> 
> Please send me a complete log of what the kernel prints, since powering up
> the computer.
> 
> 	Andrey
> -
> 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/

-- 
Boy!  Eucalyptus!

[-- Attachment #2: kernel.log.gz --]
[-- Type: application/x-gzip, Size: 6389 bytes --]

Re: eepro100: wait_for_cmd_done timeout

[Jeff Garzik]

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

Re: eepro100: wait_for_cmd_done timeout

[Chris Bacott]

> 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

Re: eepro100: wait_for_cmd_done timeout

[Paul Rolland]

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

Re: eepro100: wait_for_cmd_done timeout

[Andrey Nekrasov]

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.

eepro100: wait_for_cmd_done timeout

[Paul Rolland]

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