netdev - Re: [Bugme-new] [Bug 12877] New: tg3: eth0 transit timed out, resetting -> dead NIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49C01F7F.9030306@birkenwald.de>
Date:	Tue, 17 Mar 2009 23:09:03 +0100
From:	Bernhard Schmidt <berni@...kenwald.de>
To:	Michael Chan <mchan@...adcom.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Carlson <mcarlson@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"bugme-daemon@...zilla.kernel.org" <bugme-daemon@...zilla.kernel.org>
Subject: Re: [Bugme-new] [Bug 12877] New: tg3: eth0 transit timed out, resetting
 -> dead NIC

On 16.03.2009 22:23, Michael Chan wrote:
> On Sun, 2009-03-15 at 14:32 -0700, Andrew Morton wrote:
>>> [784063.389142] tg3: eth0: transmit timed out, resetting
>>> [784063.447106] tg3: DEBUG: MAC_TX_STATUS[ffffffff] MAC_RX_STATUS[ffffffff]
>>> [784063.524104] tg3: DEBUG: RDMAC_STATUS[ffffffff] WDMAC_STATUS[ffffffff]
>
> At the time of tx timeout, the registers all return 0xffffffff.  Does
> the subsequent reset bring the device back?  If the device is brought
> back, there should be a link up message and traffic should resume.  If
> not, please provide lspci -vvvxxx on the eth0 device after the failure.

Attached, both after the crash (tg3.crashed) and after I reloaded the 
module (tg3.reloaded). Additional info, ifdown/ifup does not fix the 
situation, both take pretty long

# ifdown eth0
tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear 
MAC_TX_MODE=ffffffff
# ifup eth0
tg3 0000:03:04.0: irq 1272 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready

and it stays dead.

# rmmod tg3
tg3 0000:03:04.1: PCI INT B disabled
tg3 0000:03:04.0: PCI INT A disabled
# modprobe tg3
tg3.c:v3.94 (August 14, 2008)
tg3 0000:03:04.0: enabling device (0000 -> 0002)
tg3 0000:03:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
eth0: Tigon3 [partno(N/A) rev 9003 PHY(5714)] (PCIX:133MHz:64-bit) 
10/100/1000Base-T Ethernet 00:21:5a:99:0a:28
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76148000] dma_mask[40-bit]
tg3 0000:03:04.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
eth1: Tigon3 [partno(N/A) rev 9003 PHY(5714)] (PCIX:133MHz:64-bit) 
10/100/1000Base-T Ethernet 00:21:5a:99:0a:29
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76148000] dma_mask[40-bit]
# ifup eth0
ADDRCONF(NETDEV_UP): eth0: link is not ready
device eth0 entered promiscuous mode
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is off for TX and off for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

and I'm up and running again.

> Also, when one ethernet port fails, does the other port (from the same
> dual port device) function ok?

Still no clue about that, I need to find someone who can connect 
something there.

Bernhard

View attachment "tg3.crashed" of type "text/plain" (51423 bytes)

View attachment "tg3.reloaded" of type "text/plain" (51456 bytes)