eepro100 problems with 2.2.19 _and_ 2.4.0

eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

Hello everybody,

I'm having a ton of problems with a set of boxes that use an onboard
variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
documentation - motherboard is model D815EEA2) but eepro100-diag reports:

eepro100-diag.c:v2.05 6/13/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82562 Pro/100 V adapter at 0xdf00.
i82557 chip registers at 0xdf00:
  00000000 00000000 00000000 00080002 183f0000 00000000

Okay, now for the bad part. Symptoms:

* slow transfers (internet ftps are the case) hard lock box.
* interactive use hard locks box.
* basic Netperf tests run fine.
* wget of > 20MB files from local server run fine.

Steps to reproduce problem:

* Run large ( > 2MB works ) ftp transfer in box.
* ssh in from another box and attempt an ls -lR /

So it seems that only when the network i/o is low does the lock occur.

I've tried up to now four sets of drivers (all non-modules):

* 2.2.19 straight (Andrey?)
	Kills networking, but stays alive - reports (typed in):
	epro100: cmd_wait for (0xffffff00) timedout with (0xffffff00)!

* 2.2.19 with Donald's eepro100.c scyld:network/
	Hard lock (seems to take longer to hang) - it also creates
	8 devices eth0-eth7!

* 2.2.19 with Donald's eepro100.c fromscyld:network/test/
	Hard lock (pretty fast) - no multiple creation bugs

* 2.4.5 straight
	Hangs ssh connection, reports (typed in):
	epro100: wait_for_cmd_done timeout!
	Data socket timed out:
	eth0: Transmit timed out: status 0050  0c00 at 907/935 command 000c0000.

So now I'm left here stuck with a stupid unworking on-board card.

Donald, Andrey, anyone? have you seen this before? What can I do to help
this get diagnosed properly?

BTW: eepro100-diag reports sleep mode on - this is bad, right? And I can
turn it off?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

Just noticed:

On Sat, 16 Jun 2001, Christian Robottom Reis wrote:

> Steps to reproduce problem:
>
> * Run large ( > 2MB works ) ftp transfer in box.
> * ssh in from another box and attempt an ls -lR /

Note below:

> * 2.2.19 with Donald's eepro100.c scyld:network/
> 	Hard lock (seems to take longer to hang) - it also creates
> 	8 devices eth0-eth7!
>
> * 2.2.19 with Donald's eepro100.c fromscyld:network/test/
> 	Hard lock (pretty fast) - no multiple creation bugs

Actually, they don't hang _immediately_. They report:

eth0: Transmit timed out: status 0050  0000 at 6022/6034 commands 000c0000
000c0000 000c0000
Command 0000 was not immediately accepted, 10001 ticks!

And the ssh connection stalls but does on trying (it eventually hangs, but
not after a lot of errors are reported on the problem-box's console)

And then the box hard locks. Interesting to see that only when I run the
ssh ls -lR is that any error at all is produced. The lockups I was seeing
were all interactive use and I never really noticed if errors were showing
up or not; I just assumed they weren'.

Any help you can provide is very much appreciated. I'm about to try
Intel's drivers to see how they do.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

On Sat, 16 Jun 2001, Christian Robottom Reis wrote:

> I'm having a ton of problems with a set of boxes that use an onboard
> variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
> documentation - motherboard is model D815EEA2) but eepro100-diag reports:
>
> eepro100-diag.c:v2.05 6/13/2001 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Intel i82562 Pro/100 V adapter at 0xdf00.

I've just tested with Intel's epro-1.6.6 driver, and it does work (the
full bonanza works; simultaneous netperf and ftp and whatnot run with no
errors or hangs). This makes my situation a bit easier (and my head a bit
less confused, specially with Andrey pointing out the different versions
to the driver).

I am _very_ willing to devote some time to getting this fixed in both the
kernel and Donald's drivers if anyone is interested in tracking down the
problem. I'm not very familiar with the hardware, but I have a test box I
can use freely, a bit of time spare, and I can reproduce the problem
easily. I'd hate to see somebody else go through what I have just had to,
so it would be nice to see this fixed or documented in an official-ese
place.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Jeff Chua]

Try to add "options eepro100 options=0" to your /etc/modules.conf
to default the speed to 10Mbps if you're using 10BaseT.

add to /etc/modules.conf ...
# options=0x30 100mbps full duplex
# options=0x20 100mbps half duplex
# options=0     10mbps half duplex
options eepro100 options=0

then run "depmod -a"

Thanks,
Jeff
[ jchua@fedex.com ]
----- Original Message ----- 
From: "Christian Robottom Reis" <kiko@async.com.br>
To: <eepro100@scyld.com>
Cc: <saw@saw.sw.com.sg>; <linux-kernel@vger.kernel.org>
Sent: Sunday, June 17, 2001 10:43 AM
Subject: Re: eepro100 problems with 2.2.19 _and_ 2.4.0



Just noticed:

On Sat, 16 Jun 2001, Christian Robottom Reis wrote:

> Steps to reproduce problem:
>
> * Run large ( > 2MB works ) ftp transfer in box.
> * ssh in from another box and attempt an ls -lR /

Note below:

> * 2.2.19 with Donald's eepro100.c scyld:network/
> Hard lock (seems to take longer to hang) - it also creates
> 8 devices eth0-eth7!
>
> * 2.2.19 with Donald's eepro100.c fromscyld:network/test/
> Hard lock (pretty fast) - no multiple creation bugs

Actually, they don't hang _immediately_. They report:

eth0: Transmit timed out: status 0050  0000 at 6022/6034 commands 000c0000
000c0000 000c0000
Command 0000 was not immediately accepted, 10001 ticks!

And the ssh connection stalls but does on trying (it eventually hangs, but
not after a lot of errors are reported on the problem-box's console)

And then the box hard locks. Interesting to see that only when I run the
ssh ls -lR is that any error at all is produced. The lockups I was seeing
were all interactive use and I never really noticed if errors were showing
up or not; I just assumed they weren'.

Any help you can provide is very much appreciated. I'm about to try
Intel's drivers to see how they do.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

-
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: eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

On Sun, 17 Jun 2001, Jeff Chua wrote:

> Try to add "options eepro100 options=0" to your /etc/modules.conf
> to default the speed to 10Mbps if you're using 10BaseT.

I'm not using modules for this driver (can't see the point, really); does
this fix anything if I change it to 0x20 for 100BaseT?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Jeff Chua]

On Sun, 17 Jun 2001, Christian Robottom Reis wrote:

> > Try to add "options eepro100 options=0" to your /etc/modules.conf
> > to default the speed to 10Mbps if you're using 10BaseT.
>
> I'm not using modules for this driver (can't see the point, really); does
> this fix anything if I change it to 0x20 for 100BaseT?
>
try to pass the options when you boot up linux and see if it helps

Jeff

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Andrey Savochkin]

On Sun, Jun 17, 2001 at 12:40:34AM -0300, Christian Robottom Reis wrote:
> 
> I am _very_ willing to devote some time to getting this fixed in both the
> kernel and Donald's drivers if anyone is interested in tracking down the
> problem. I'm not very familiar with the hardware, but I have a test box I
> can use freely, a bit of time spare, and I can reproduce the problem
> easily. I'd hate to see somebody else go through what I have just had to,
> so it would be nice to see this fixed or documented in an official-ese
> place.

I'm obviously interested in tracking it down.
I'll contact you with what we can test on you comp a couple of days later,
I'm quite busy right now, ok?

	Andrey