[opensuse] Nic or Hub - Something is going PLONK soon?
Lately my 10.1 log is starting to get many instances of the following: ---------------- Dec 10 09:56:56 pen kernel: eth0: Transmit error, Tx status register 82. Dec 10 09:56:56 pen kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt Dec 10 09:56:56 pen kernel: Flags; bus-master 1, dirty 791618(2) current 791618(2) Dec 10 09:56:56 pen kernel: Transmit list 00000000 vs. e6110340. Dec 10 09:56:56 pen kernel: 0: @e6110200 length 80000042 status 00010042 Dec 10 09:56:56 pen kernel: 1: @e61102a0 length 80000534 status 80010534 Dec 10 09:56:56 pen kernel: 2: @e6110340 length 80000042 status 00010042 Dec 10 09:56:56 pen kernel: 3: @e61103e0 length 800005e2 status 000105e2 Dec 10 09:56:56 pen kernel: 4: @e6110480 length 80000042 status 00010042 Dec 10 09:56:56 pen kernel: 5: @e6110520 length 800002ff status 000102ff Dec 10 09:56:56 pen kernel: 6: @e61105c0 length 800005d6 status 000105d6 Dec 10 09:56:56 pen kernel: 7: @e6110660 length 800005d6 status 000105d6 Dec 10 09:56:56 pen kernel: 8: @e6110700 length 8000052f status 0001052f Dec 10 09:56:56 pen kernel: 9: @e61107a0 length 80000276 status 00010276 Dec 10 09:56:56 pen kernel: 10: @e6110840 length 80000056 status 00010056 Dec 10 09:56:56 pen kernel: 11: @e61108e0 length 800001cd status 000101cd Dec 10 09:56:56 pen kernel: 12: @e6110980 length 80000036 status 00010036 Dec 10 09:56:56 pen kernel: 13: @e6110a20 length 80000118 status 00010118 Dec 10 09:56:56 pen kernel: 14: @e6110ac0 length 80000042 status 00010042 Dec 10 09:56:56 pen kernel: 15: @e6110b60 length 80000042 status 00010042 -------------------- This is a 3com nic: Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) (I have been violating my own advice which is to listen for the nice plonk sound any 3com nic makes as it hits the bottom of the waste basket. This one only survives because it has been running more or less flawlessly for many years.) The mentioned text file suggests a duplex mismatch, but this is not so, ethtool reports: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s <<<<<<<<<< Duplex: Half <<<<<<<<<< Port: MII PHYAD: 24 Transceiver: internal Auto-negotiation: on Current message level: 0x00000001 (1) Link detected: yes ----------------------- Its connected to a rather ancient 10meg hub that connects to my cable modem as there is no need for more than 10 meg to the cable modem, and I like a hub for this position so I can run ethereal on what is reaching the modem. That hub is only capable of 10mb/half Any clue what would cause a nic to all of a sudden decide that it had a duplex mismatch every so often? Occasionally it is so frequent as to make even web browsing difficult. -- _____________________________________ John Andersen
On Sunday 10 December 2006 5:12 pm, John Andersen wrote:
Lately my 10.1 log is starting to get many instances of the following:
---------------- Dec 10 09:56:56 pen kernel: eth0: Transmit error, Tx status register 82. Dec 10 09:56:56 pen kernel: Probably a duplex mismatch. See <trimmed>
The mentioned text file suggests a duplex mismatch, but this is not so, ethtool reports: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s <<<<<<<<<< Duplex: Half <<<<<<<<<< <trimmed>
Any clue what would cause a nic to all of a sudden decide that it had a duplex mismatch every so often? Occasionally it is so frequent as to make even web browsing difficult.
Here are a few things that I can think of: 1) Cable is bad 2) NIC or hub is bad (try a different port on the hub?) 3) Possible electrical interference passing through the cable (any electrical cords passing over this network cable?) 4) Auto-negotiation is not working as it should and/or reporting the correct value. You may want to ensure that the NIC is indeed using Half Duplex by issuing the command: ethtool -s eth0 duplex half I hope that this helps in some way. - James W. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 10 December 2006 18:09, James Wright wrote:
4) Auto-negotiation is not working as it should and/or reporting the correct value. You may want to ensure that the NIC is indeed using Half Duplex by issuing the command:
ethtool -s eth0 duplex half
Nick summarily ignored any ethtool commands. Hub replaced with 10/100 switch. Then nic would auto-negotiate 100Full. However, after some time it would drop to 10/half. So I invoked Andersen's rule of naughty nics and it went plonk. Slapped an intel nic in, and it negotiates 100/full and stays there. 3com. sigh..... But thanks for the suggestions. -- _____________________________________ John Andersen
John Andersen wrote:
On Sunday 10 December 2006 18:09, James Wright wrote:
4) Auto-negotiation is not working as it should and/or reporting the correct value. You may want to ensure that the NIC is indeed using Half Duplex by issuing the command:
ethtool -s eth0 duplex half
Nick summarily ignored any ethtool commands.
Hub replaced with 10/100 switch. Then nic would auto-negotiate 100Full. However, after some time it would drop to 10/half.
So I invoked Andersen's rule of naughty nics and it went plonk. Slapped an intel nic in, and it negotiates 100/full and stays there.
That's been my experience - in fact, as soon as I saw the nic errors on the initial posting, I said to myself "hmm, that looks like one of those broken 3com cards" Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
J Sloan
-
James Wright
-
John Andersen