Description of Problem:
Kernels 2.4.9-31 and 2.4.9-21 make ethernet interface (eepro100) in
Acer Travelmate laptop unusable.
I have here now such laptop where top of 'dmidecode' output shows
DMI type 0, 19 bytes.
BIOS Information Block
Version: V3.3 R01-A2j EN
BIOS base: 0xF0000
ROM size: 448K
DMI type 1, 25 bytes.
System Information Block
Product: TravelMate 740
Serial Number: 9142R012051410013AM000
It has a built-in ethernet card which is detected as eepro100
"eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<firstname.lastname@example.org> and others
PCI: Guessed IRQ 10 for device 02:08.0"
'lspci -tv' and 'lspci -tvn' show these:
--+-00.0 Intel Corporation: Unknown device 3575
+-01.0-----00.0 ATI Technologies Inc: Unknown device 4c59
+-1d.0 Intel Corporation: Unknown device 2482
+-1d.1 Intel Corporation: Unknown device 2484
+-1d.2 Intel Corporation: Unknown device 2487
+-1e.0---+-08.0 Intel Corporation: Unknown device 1031
| +-09.0 O2 Micro, Inc. OZ6933 Cardbus Controller
| \-09.1 O2 Micro, Inc. OZ6933 Cardbus Controller
+-1f.0 Intel Corporation: Unknown device 248c
+-1f.1 Intel Corporation: Unknown device 248a
+-1f.3 Intel Corporation: Unknown device 2483
+-1f.5 Intel Corporation: Unknown device 2485
\-1f.6 Intel Corporation: Unknown device 2486
| +-09.0 1217:6933
| \-09.1 1217:6933
When trying to use with 2.4.9-31 (and at least 2.4.9-21) kernels from
7.2 distro updates ethernet connections go away rather quickly filling
logs with messages:
eepro100: wait_for_cmd_done timeout!
eepro100: wait_for_cmd_done timeout!
"Quickly" means in this context that an attempt to grab over NFS
a binary rpm of a kernel require multiple executions (three, four,...)
of 'ifdown eth0; ifup eth0' after which transfers usually resume.
ssh connection lock up unpredictably and often even before completing
a login sequence or soon thereafter.
'mii-tool -v' invariably shows:
eth0: no autonegotiation, 10baseT-HD, link ok
product info: vendor 00:aa:00, model 51 rev 0
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 10baseT-HD
The only possible clue comes from 'eepro100-diag', which has to be
called with '-p 0x7000' as it is not finding the card by itself, which
gives that with '-mm' flags:
eepro100-diag.c:v2.05 6/13/2001 Donald Becker (email@example.com)
Assuming a Intel i82557/8/9 EtherExpressPro100 adapter at 0x7000.
EEPROM contents, size 64x16:
00: 0000 52e2 bf23 1a03 0000 0201 4701 0000
0x08: 0000 0000 49a2 1017 1025 0000 0000 0000
0x10: 0000 0000 0000 0000 0000 0000 0000 1031
0x20: 0000 0000 0000 1031 0000 0000 0000 0000
0x30: 002c 0000 0000 0000 0000 0000 0000 0000
0x38: 0000 0000 0000 4030 0000 0000 0000 7b14
The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:00:E2:52:23:BF.
Board assembly 000000-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
Sleep mode is enabled. This is not recommended.
Under high load the card may not respond to
PCI requests, and thus cause a master abort.
It is not clear what enables this "sleep mode" and how possibly to
The problem does not seem to occur with the original 2.4.7-10 kernel
from distribution CDs as I run the whole update of this installation
from an NFS mounted directory without any incidents.
It does not seem to be a problem of only a network driver as with
both incriminated kernels from time to time screen updates slow down
to ridiculous pace and one can see a terminal window "scrolling" in
distinct multiple "waves".
The current solution seem to be to replace the whole kernel with the
one from "skipjack" public beta. At least nominally the same version
of a network driver is in use. Still I just copied around 1.5 GB of
data from an NFS mounted directory to a destination on a laptop and it
survived. Not everything is perfect as there was one incident during
this transfer when a network temporary wedged but it recovered by
itself. I attach a dmesg output for this exercise. All transfers
are on my "home" network between machines sitting side by side on
Version-Release number of selected component (if applicable):
Created attachment 50004 [details]
dmesg output from an NFS session
On the less optimistic note just now an ssh session _to_ this laptop
running 2.4.18-0.4 wedged up and it does not look that it is going to
recover. :-( It is already few minutes with a dead network.
One more possible clue. After I did 'ifdown eth0; iup eth0' on a laptop
a network is back and dmesg reports a bunch of
eepro100: wait_for_cmd_done timeout!
("last message repeated 4 times" and "last message repeated 13 times")
eth0: 0 multicast blocks dropped.
I'm getting this same thing with kernel 2.4.8-0.16, under RH7.2. Everything
works fine after a reboot/startup, but after suspending and unsuspending, I get
(copied from /var/log/messages):
Apr 8 10:44:07 rain kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker
Apr 8 10:44:07 rain kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified
by Andrey V. Savochkin <firstname.lastname@example.org> and others
Apr 8 10:44:07 rain kernel: PCI: Enabling device 08:04.0 (0000 -> 0003)
Apr 8 10:44:07 rain kernel: PCI: Setting latency timer of device 08:04.0 to 64
Apr 8 10:44:07 rain kernel: eth0: Invalid EEPROM checksum 0xff00, check
settings before activating this device!
Apr 8 10:44:07 rain kernel: eth0: OEM i82557/i82558 10/100 Ethernet,
FF:FF:FF:FF:FF:FF, IRQ 10.
Apr 8 10:44:07 rain kernel: Board assembly ffffff-255, Physical connectors
present: RJ45 BNC AUI MII
Apr 8 10:44:07 rain kernel: Primary interface chip unknown-15 PHY #31.
Apr 8 10:44:07 rain kernel: Secondary interface chip i82555.
Apr 8 10:44:07 rain kernel: Self test failed, status ffffffff:
Apr 8 10:44:07 rain kernel: Failure to initialize the i82557.
Apr 8 10:44:07 rain kernel: Verify that the card is a bus-master capable slot.
diff -u of 'lspci -vv' from pre and post suspend shows a number of differences:
--- ee.pre Tue Apr 9 11:40:57 2002
+++ ee.post Tue Apr 9 11:40:35 2002
@@ -1,15 +1,13 @@
08:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
Subsystem: Action Tec Electronics Inc: Unknown device 1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
-- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 14000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f8fff000 (32-bit, non-prefetchable) [size=4K]
Region 0: [virtual] Memory at f8fff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at ecc0 [size=64]
Region 2: Memory at f8e00000 (32-bit, non-prefetchable) [size=1M]
Region 2: [virtual] Memory at f8e00000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at f9000000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot
Status: D2 PME-Enable- DSel=0 DScale=2 PME-
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=2 PME-
(I hope bugzilla doesn't mangle this)
2.4.18-0.13 from the current "public beta" included e100 among "addon"
drivers. This one seems to work without going away after a while.
It also survives suspend.
The value of this report seems to be mostly historical. I did not hear
from the owner about network problems; but he is using e100 driver.
Ok, closing since e100 appears to work. We are deprecating eepro100
in favor of e100.