[tulip] Transmit Timeout

[C. R. Oldham]

Greetings,

Two issues below:

1) I have a NetGear ethernet adapter that the Tulip driver reports as

Digital DS21140 Tulip rev 34 at 0xd400, 00:40:05:A2:C4:32, IRQ 9.
Jun 12 10:52:03 rack kernel: eth1:  EEPROM default media type Autosense.

Jun 12 10:52:03 rack kernel: eth1:  Index #0 - Media MII (#11) described
by a 21140 MII PHY (1) block.
Jun 12 10:52:03 rack kernel: eth1:  MII transceiver #0 config 1000
status 782d advertising 01e1.

A few days ago I noticed that sometimes the link light for this adapter
on my LinkSys 100 Mb/s (only--it's not a 10/100) hub would go out.
ifconfig down/up would not fix the problem, neither would power cycling
the hub.  At the time I did not have the driver compiled as a module, so
I had to reboot the machine to get it back up.

Right now I can't try the rmmod/insmod thing because I'm remote, and
I'll lose connectivity to the machine if I do that.  Unless someone can
tell me how to remove the module for just one adapter.

Now that I have the driver as a module, I upped the debug level and I'm
getting lots of

Jun 13 08:07:52 rack kernel: eth1: Transmit error, Tx status 7fffbc00.
Jun 13 08:07:52 rack kernel: eth1: Transmit error, Tx status 7fffbc00.

Is the is a problem with the card, or the hub?  What exactly does that
mean above?

2) I have a cablemodem connected to another adapter (A Kingston) that
the Tulip driver reports as

Jun 12 10:52:03 rack kernel: tulip.c:v0.91g-ppc 7/16/99
becker@cesdis.gsfc.nasa.gov
Jun 12 10:52:03 rack kernel: eth0: Digital DC21041 Tulip rev 33 at
0xd800, 00:C0:F0:23:80:1D, IRQ 10.
Jun 12 10:52:03 rack kernel: eth0: 21041 Media table, default media 0800
(Autosense).
Jun 12 10:52:03 rack kernel: eth0:  21041 media #0, 10baseT.
Jun 12 10:52:03 rack kernel: eth0:  21041 media #4, 10baseT-FD.

When I upgraded to 2.2.15 I noticed that if my cablemodem is
power-cycled or loses blocksync long enough to initiate a self-test, the
adapter drops offline.  ifconfig down/up doesn't fix it.  Again, I
haven't tried the insmod/rmmod thing but the earlier drivers didn't
behave like this.  Is there a switch to the driver I could use to
prevent this behavior?

Are these really the same problem?

--
| Charles R. (C. R.) Oldham     | NCA Commission on Schools        |
| cro@nca.asu.edu               | Arizona St. Univ., PO Box 873011,|
| V:480/965-8700 F:480/965-9423 | Tempe, AZ 85287-3011           _ |
| "I like it!"--Citizen G'Kar   | #include <disclaimer.h>       X_>|