[vortex-bug] sporadic "eth0: Transmit error, Tx status register 82." Errors
Andi Hechtbauer
anti-drv@spin.de
29 Jul 2000 18:54:30 +0200
Hi,
I'm using 3c59x.c:v0.99H 11/17/98 Donald Becker with two
3Com 3C905B 100bTX (rev 48) NICs in a AMD-K6(tm) 3D /400
Linux 2.2.12 Machine.
The system is a server under high network load and works
reliably; every some weeks or so, though, the NIC which
really does all the work (eth0), stops doing just that.
We admin the box remotely, so it took us some time to figure
that it was the card that stopped working, and this time
- yesterday - I sneaked in via the other NIC (privately
assigned IP) and ifconfiged eth0 down/up, and it continued
its task.
Since then I'm seeing sporadic
"eth0: Transmit error, Tx status register 82." Messages in
our logs, and reading the list archive I found this may be
caused by various things:
- flaky hardware / cable.
I doubt that, cause I'm only seeing 1 or two of those msgs
per hour, and the system's really doing a lot of network
stuff.
- wrongly configured drivers.
From what I read, Donald Becker seems to go for the "do not
config" statement and well, we're doing that. No options to
modprobe/insmod. Stock kernel 2.2.12 module.
- a driver/kernel bug.
That, too, seems unprobable. Seeing how many People use just
our configuration under heavy network traffic conditions, I'd
guess there had to be more issues...
Anyway, here's some diagnostics:
$> ./mii-diag -v
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
MII PHY #24 transceiver registers:
3000 786d 0000 0000 01e1 0080 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
8000 0008 0090 0000 0000 0005 2001 0000
0000 204b 0105 1c11 0002 1000 0000 0000.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner is generating 100baseTx link beat (no autonegotiation).
looking good to me. The "link partner" is a 3Com SuperstackII BTW.
$> sudo ./vortex-diag -v
vortex-diag.c:v2.02 7/1/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xdc00.
Indication enable is 06c6, interrupt enable is 06de.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings: half-duplex.
Station address set to 00:10:5a:1c:34:3c.
Configuration options 000a.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address 00:10:5A:1C:34:3C (used as a unique ID only).
OEM Station address 00:10:5A:1C:34:3C (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 8/31/1998, division 6, product QP.
Options: none.
Vortex format checksum is incorrect (006e vs. 10b7).
Cyclone format checksum is correct (0x06 vs. 0x06).
Hurricane format checksum is correct (0x06 vs. 0x06).
MII PHY found at address 24, status 786d.
MII PHY found at address 0, status 786d.
MII PHY 0 at #24 transceiver registers:
3000 786d 0000 0000 01e1 0080 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
8000 0008 0090 0000 0000 0005 2001 0000
0000 204b 0105 1c11 0002 1000 0000 0000.
MII PHY 1 at #0 transceiver registers:
3000 786d 0000 0000 01e1 0080 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
8000 0008 0090 0000 0000 0005 2001 0000
0000 204b 0106 1c11 0002 1000 0000 0000.
Well. Whatever. I don't think the incorrect Vortex format checksum
is doing anything here, is it?
$> ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:10:5A:1C:34:3C
inet addr:111.222.333.444 Bcast:111.222.333.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1974491954 errors:56 dropped:0 overruns:88458 frame:89
TX packets:2070054685 errors:0 dropped:0 overruns:0 carrier:0
collisions:707739 txqueuelen:100
Interrupt:10 Base address:0xdc00
This bothers me. (and I'm not talking about the inet addr part ;-)
Please tell me it should not?!
$> uptime
6:31pm up 37 days, 9:13, ...
I wonder if a reboot or delmod/insmod would change the current
behaviour, but unless I have to, I'd rather not do something
like that remotely.
Thanks for your time and answers,
regards
--
Andi Hechtbauer anti@spin.de
System Administration voice: +49 941 94 65 937
SPiN GmbH http://www.spin.de/ fax: +49 941 94 65 938
------- web design - java chats - guestbooks - java/cgi coding -------