Bug 110134 - e100 driver gives lots of "e100_wait_exec_simple: failed"
e100 driver gives lots of "e100_wait_exec_simple: failed"
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jeff Garzik
Depends On:
  Show dependency treegraph
Reported: 2003-11-14 19:56 EST by Chris Adams
Modified: 2013-07-02 22:16 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-20 11:24:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Adams 2003-11-14 19:56:40 EST
I installed FC1 on an old Intergraph 625R server (quad PPro 200) with
an integrated Intel Ethernet Pro 100 interface.  This worked under RHL
7.1 and with an older 2.4 kernel (don't know the exact version as the
disc died).  Now I get lots of the message:

Nov 14 18:25:19 mirror kernel: e100: eth0: e100_wait_exec_simple: failed
Nov 14 18:26:34 mirror last message repeated 5 times
Nov 14 18:28:28 mirror last message repeated 11 times
Nov 14 18:30:04 mirror last message repeated 17 times
Nov 14 18:31:39 mirror last message repeated 12 times

Is this a problem?  I don't think I'm seeing actual problems with the
network (I saw some flakiness yesterday, but it looked like the switch
and the interface get stuck in auto-negotiation - reset both and both
were happy at 100/full).
Comment 1 Rich 2003-12-29 09:13:31 EST

You can fix the autonegotiation by telling it not to.  The driver
really goes nuts trying to autonegotiate with *cheaper* switches.

In the modules.conf add:

alias eth0 e100
options e100 e100_speed_duplex=1
# 1 - 10/HD
# 2 - 10/FD
# 3 - 100/HD
# 4 - 100/FD
# 0 - AutoNegotiate (default)

This solved the cards mysterical disappearence every 10 minutes. 
But.. this worked for about a month.  Now I am just starting to
receive these wait_exec_simple errors with is resulting in the card
still responding locally, interface is still operational, except
cannot access anything external to the machine.  Recylcing the
interface does do the trick..  but can't take the chance it not being

I read somewhere that someone saw it happen when the machine tried
going into a Suspend mode.  I have all power managment turned off, not
sure if something is still actively being monitored.

Another post I saw said to go back to the older driver - eepro100. 
I've used this one before, on other machines and had no problems.  I
will see if this fixes it for now.


Comment 2 Chris Adams 2003-12-30 17:49:54 EST
Actually, it is working okay at auto/auto on both ends at 100/full.
Also, it isn't exactly a cheap switch at the other end; it is connected
to a Cisco Catalyst 5500 (older model but good switch).
Comment 3 Scott Feldman 2004-02-03 18:32:10 EST
Please try the e100-3.0.13 driver from http://sf.net/projects/e1000.  
This is a new development driver, and it handles command timouts much 
better that the current e100 driver.   
Comment 4 Chris Adams 2004-02-06 16:52:00 EST
Okay, that made things much worse.  Instead of just getting error
messages, I got network dropouts of 5-20 seconds and error messages:

e100: Intel(R) PRO/100 Network Driver, 3.0.13
e100: Copyright(c) 1999-2004 Intel Corporation
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xffbe6000, irq 9, MAC addr 08:00:36:2E:A3:03
ip_tables: (C) 2000-2002 Netfilter core team
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
ip_tables: (C) 2000-2002 Netfilter core team
NETDEV WATCHDOG: eth0: transmit timed out
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
NETDEV WATCHDOG: eth0: transmit timed out
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Comment 5 Chris Adams 2004-02-20 11:24:18 EST
The "problem NIC" is a built-in interface on an old Intergraph server.
I scrounged an Intel "InBusiness 10/100" card and installed it, and
things are working good now.  I get a "hw tcp v4 csum failed" now and
then, but not that often.

I think we can chalk this one up to a flakey interface.  Thanks for the

Note You need to log in before you can comment on or make changes to this bug.