2.2.19: eepro100 and cmd_wait issues

2.2.19: eepro100 and cmd_wait issues

[John Madden]

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
aw@saw.sw.com.sg> and others
eepro100.c: VA Linux custom, Dragan Stancevic <visitor@valinux.com> 2000/11/15


Thanks!

John


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

Re: 2.2.19: eepro100 and cmd_wait issues

[Florin Andrei]

On 12 Jun 2001 13:00:41 -0500, John Madden wrote:
> 
> kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
> kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!

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.

> The only solution I've found that works is to reboot, and since this is

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

Re: 2.2.19: eepro100 and cmd_wait issues

[Ken Brownfield]

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.

On Tuesday, June 12, 2001, at 11:51 AM, Florin Andrei wrote:

> On 12 Jun 2001 13:00:41 -0500, John Madden wrote:
>>
>> kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
>> kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
>
> 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.
>
>> The only solution I've found that works is to reboot, and since this is
>
> 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
>
> -
> 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/

Re: 2.2.19: eepro100 and cmd_wait issues

[Ben Greear]

Ken Brownfield wrote:

> 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.

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 <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: 2.2.19: eepro100 and cmd_wait issues

[David Lang]

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

David Lang

On Tue, 12 Jun 2001, Ben Greear wrote:

> Date: Tue, 12 Jun 2001 17:51:08 -0700
> From: Ben Greear <greearb@candelatech.com>
> To: Ken Brownfield <brownfld@irridia.com>
> Cc: Florin Andrei <florin@sgi.com>, linux-kernel@vger.kernel.org
> Subject: Re: 2.2.19: eepro100 and cmd_wait issues
>
> Ken Brownfield wrote:
>
> > 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.
>
> 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 <greearb@candelatech.com>          <Ben_Greear@excite.com>
> President of Candela Technologies Inc      http://www.candelatech.com
> ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear
> -
> 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/
>

Re: 2.2.19: eepro100 and cmd_wait issues

[Ben Greear]

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

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 <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: 2.2.19: eepro100 and cmd_wait issues

[Henning P. Schmiedehausen]

Ben Greear <greearb@candelatech.com> writes:

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

>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.)

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     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: 2.2.19: eepro100 and cmd_wait issues

[Florin Andrei]

On 12 Jun 2001 12:20:58 -0700, Ken Brownfield wrote:
> 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.

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

Re: 2.2.19: eepro100 and cmd_wait issues

[Jason Murphy]

I would suggest that you use the e100 driver instead of the eepro100 driver.

We switched to the e100 driver from the eepro100 driver, and a number of our 
FTP, NFS and rsync (IE: High bandwidth apps) problems went away.

Our system are mostly 6 Proc boxes with 4 gigs of memeory.

--
Jason Murphy

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com