eepro100: wait_for_cmd_done timeout

DISCUSSION Dionysius Wilson Almeida 6 participants 11 messages Jun 20, 2001 – Jun 22, 2001 Network drivers

Share & tools

Dionysius Wilson Almeida

author

2001-06-20 23:32 UTC #0 lore raw

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

Signature · 3 lines

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

Andrey Savochkin

2001-06-20 23:53 UTC #1 lore raw

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

Quoted 7 lines · Dionysius Wilson Almeida

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

Dionysius Wilson Almeida

author

2001-06-21 00:02 UTC #2 lore raw

In reply to 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
`

Quoted 14 lines · * Andrey Savochkin ([email protected]) 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
Quoted 7 lines · Dionysius Wilson Almeida
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

Signature · 1 line

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

Rafael Martinez

2001-06-21 12:48 UTC #3 lore raw

---Reply to mail from Dionysius Wilson Almeida about eepro100: wait_for_cmd_done timeout

Quoted 5 lines

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

Masaru Kawashima

2001-06-21 14:20 UTC #4 lore raw

In reply to Dionysius Wilson Almeida

Hi!

Quoted 2 lines · On Wed, 20 Jun 2001 16:31:34 -0700 Dionysius Wilson Almeida <Dionysius Wilson…

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.

Signature · 1 line

Masaru Kawashima

drivers/net/eepro100.c renamed from drivers/net/eepro100.c.org +3 -1

@@ -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");

Masaru Kawashima

2001-06-21 16:29 UTC #5 lore raw

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)

Quoted 17 lines · On Thu, 21 Jun 2001 23:19:39 +0900 Masaru Kawashima <Masaru Kawashima…

Hi!
Quoted 2 lines · On Wed, 20 Jun 2001 16:31:34 -0700 Dionysius Wilson Almeida <Dionysius Wilson…
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?

Quoted 10 lines

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.
Signature · 1 line
Masaru Kawashima

--
Masaru Kawashima

drivers/net/eepro100.c renamed from drivers/net/eepro100.c.org +3 -2

@@ -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");

John Madden

2001-06-21 14:39 UTC #6 lore raw

In reply to Dionysius Wilson Almeida

Quoted 11 lines

Quoted 2 lines · Dionysius Wilson Almeida <Dionysius Wilson Almeida…
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. */

Quoted 8 lines

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

Signature · 4 lines

John Madden
UNIX Systems Engineer
Ivy Tech State College
[email protected]

Masaru Kawashima

2001-06-22 01:27 UTC #7 lore raw

Quoted 1 line · On Thu, 21 Jun 2001 09:37:47 -0500 John Madden <[email protected]> wrote:

errors. Think the patch with the udelay() will still work?

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

--
Masaru Kawashima

Dionysius Wilson Almeida

author

2001-06-22 01:36 UTC #8 lore raw

In reply to 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

Quoted 30 lines · * Dionysius Wilson Almeida ([email protected]) 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
`
Quoted 14 lines · * Andrey Savochkin ([email protected]) 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
Quoted 7 lines · Dionysius Wilson Almeida
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
Signature · 6 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Signature · 3 lines

Fortune's Office Door Sign of the Week:

	Incorrigible punster -- Do not incorrige.

Andrey Savochkin

2001-06-22 13:33 UTC #9 lore raw

In reply to Dionysius Wilson Almeida

Quoted 5 lines · 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.

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

Dionysius Wilson Almeida

author

2001-06-22 20:06 UTC #10 lore raw

In reply to Dionysius Wilson Almeida

Hi Andrey,

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

-Wilson

Quoted 22 lines · * Andrey Savochkin ([email protected]) wrote:

Quoted 5 lines · 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.
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 1 line

Boy!  Eucalyptus!