2.2.19: eepro100 and cmd_wait issues

I'm having trouble on one machine out of about 20 that run with eepro100's. This one in particular happens to be a dual port. I searched through the archives for this, but I didn't find any definite solutions (one thread, on "2.2.18 and laptop problems," provided a patch that doesn't seem to make any difference).

After roughly 30 days of uptime, I get a lot of kernel messages like the following:

kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!

I'd like to assume that this is bad hardware, but since the problem only happens every 30 days or so (and every 30 days or so), I wanted to check here to make sure it wasn't a driver issue.

The only solution I've found that works is to reboot, and since this is probably the most production machine I'm responsible for (couldn't be any other one, right?), I'd like to make sure I don't have to schedule a reboot every 29 days or something. :)

More info:
Kernel 2.2.19 SMP,
lspci:
01:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05)
Subsystem: Intel Corporation EtherExpress PRO/100+ Dual Port Adapter
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fafff000 (32-bit, prefetchable)
I/O ports at ece0
Memory at fcf00000 (32-bit, non-prefetchable)
Expansion ROM at fd000000 [disabled]
Capabilities: [dc] Power Management version 1

01:05.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05)
Subsystem: Intel Corporation EtherExpress PRO/100+ Dual Port Adapter
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at faffe000 (32-bit, prefetchable)
I/O ports at ecc0
Memory at fce00000 (32-bit, non-prefetchable)
Expansion ROM at fd000000 [disabled]
Capabilities: [dc] Power Management version 1

dmesg:
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/driv
ers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin <s [email protected]> and others
eepro100.c: VA Linux custom, Dragan Stancevic <[email protected]> 2000/11/15

Thanks!

John

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

I have the same problem, since a long time, with various 2.2 and 2.4 kernels running on a i815 motherboard, with on-board eepro100 net card.

For me, it's enough to "ifconfig down" then "ifconfig up" the interface.

I will probably buy another network card, since changing the OS is not an option, and Linux seems to not like eepro100 that much... :-/

Florin Andrei

Or you could keep your hardware and try the Intel driver, which seems to work fine. It only works as a module, though. This might also help narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.

Personally, I've found the EtherExpress hardware and eepro100 driver to be flawless in production on both single and dual units, card and built-in. It's the first choice for Linux now that Tulip has somewhat faded from view, AFAIC. I have heard mentioned on this list that the Intel driver is necessary for some (older?) cards, however.

OT: does anyone know what the current state of the Tulip driver is and if there is good hardware out there? SMC left Tulip and went through at least two other chipsets, so the only Tulip card I could find as of a couple of years ago was Digital's. But it was astonishingly expensive and not clearly supported by the Linux driver.

Thanks,
--
Ken.

The current state seems to be 'BUSTED', at least for the cards that I am trying (ZNYX 4-port, D-LINK 4-port). (I'm using the 2.4 drivers, btw.)

However, I'm hoping that it will be fixed soon, because the D-LINK 4-port is very cheap compared to other 4-ports out there, and in fact I haven't found a 4-port card that is NOT tulip based (please let me know if you have 4-port suggestions!)

Other than one really old EEPRO card I have, the EEPRO cards seem to be very stable, fast, and feature-complete.

Ben

Ben Greear <[email protected]>          <[email protected]>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

I am useing the D-link 4 port card without running into problems (admittidly I have not been stressing it much yet)

David Lang

I was able to get the D-Link to work in half-duplex (100bt), but not in auto-negotiate or full-duplex mode. (Packets would pass, but there would be huge number of carrier and other bad packets.)

I get a similar problem with the ZNYX 4-port, but I can't even force it to half-duplex, or any other fixed speed (it just won't go). It kinda autonegotiates something, claiming to be full-duplex, but it still shows collisions and I can't get through-put above about 10Mbps bi-directional, and its dropping many packets.

Ben Greear <[email protected]>          <[email protected]>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Yes. Exactly my experience (with 2.2.18 / 19 / 20pre). It is simply not possible to make a tulip based card work reliably against our Cisco Catalyst switches in these days. Sadly, because under 2.0.x, these were rock-solid.

So I started to use 3COM exclusively (which work perfectly with our switches) and eepro100 if necessary (or built onboard).

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

I did that, and it seems to be the right solution. ;-) No problem until now (i got the old problem at least once every day).

Hmmm... Seems like Intel did a good job with this driver... :-)

Florin Andrei