3c59x timeout problem

[Terence C. Haddock]

I have had the identical problem, but I was able to fix it. What I did was
take the 0.99E drivers and copy them over the 0.99H drivers in the 2.2.1
kernel. It gave some compiler warnings, but amazingly it works. This tells
me the problem began somewhere in the 0.99F-0.99H drivers, not specific to
the kernel or hardware.

Here the info when the 3com card timed out:

3c59x.c:v0.99H 11/17/98 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c905 Boomerang 100baseTx at 0xfcc0,  00:10:4b:9a:f7:02, IRQ 11
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
  MII transceiver found at address 24, status 786d.
  Enabling bus-master transmits and whole-frame receives.

Here's the info now that it works fine:

3c59x.c:v0.99E 5/12/98 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c905 Boomerang 100baseTx at 0xfcc0, 00:10:4b:9a:f7:02, IRQ 11
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/NWay Autonegotiation
interface.
  MII transceiver found at address 24, status 786d.
  Enabling bus-master transmits and whole-frame receives.

	Note the difference in the fourth line: "autoselect/NWay
Autonegotiation interface" verses "autoselect/MII interface". Anybody know
the difference there, or what that means? Is it possible to tell the newer
driver to use "autoselect/MII interface" to see if that's what's causing
the problem?
	I would like to work with someone to help find the problem, but I
have got just about zero response from the developers...

Sincerely,
Terence Haddock

Terence Haddock | "Life would be so much easier      | haddock@
 www.TRIPI.com  |   if we only had the source code." |   tripi.com

For my PGP key, finger haddock at tripi.com.

On Tue, 27 Apr 1999, Brian D. Winters wrote:

> > What's odd is that it happens with 3c595-T4 as well as 3c590!
> 
> I have that problem in one of my machines (an ALR dual P166) with both
> 3c597 cards I've tried, and would love to hear from anyone with an
> idea as to the cause.  It didn't show up on 2.0 kernels (although I
> was getting data corruption, which is gone with 2.2), but on 2.2
> kernels it is easy to trigger.  Flood pinging with large packets will
> kill the adapter very quickly, but ifdown/ifup brings it right back.
> 
> I tried one of those cards in a different EISA machine, a 486 without
> a PCI bus (and no SMP...), and it seemed to work ok in that system.
> Since the 905 I put in the problem machine seems to work ok, I've just
> written it off for the time being as one of life's little mysteries.
> 
> Brian
>