I saw a mention of interrupt handling for forcedeth cards is the
2.6.19.1 changelog, but I still see this error in 2.6.19.1. It started
in 2.6.19, and it didn't happen in 2.6.18.1.
Dec 17 05:35:29 butterfly kernel: [184432.371636] eth3: Tx timed out,
lost interrupt? TSR=0x3, ISR=0x97, t=2222.
Dec 17 05:35:31 butterfly kernel: [184433.370864] NETDEV WATCHDOG: eth3:
transmit timed out
Dec 17 05:35:31 butterfly kernel: [184433.370871] eth3: Tx timed out,
lost interrupt? TSR=0x3, ISR=0x3, t=1190.
Dec 17 05:35:34 butterfly kernel: [184434.869718] NETDEV WATCHDOG: eth3:
transmit timed out
Dec 17 05:35:34 butterfly kernel: [184434.869725] eth3: Tx timed out,
lost interrupt? TSR=0x3, ISR=0x3, t=1189.
Dec 17 05:35:37 butterfly kernel: [184436.368072] NETDEV WATCHDOG: eth3:
transmit timed out
Dec 17 05:35:37 butterfly kernel: [184436.368080] eth3: Tx timed out,
lost interrupt? TSR=0x3, ISR=0x97, t=2189.
Dec 17 05:35:39 butterfly kernel: [184437.367308] NETDEV WATCHDOG: eth3:
transmit timed out
Dec 17 05:35:39 butterfly kernel: [184437.367315] eth3: Tx timed out,
lost interrupt? TSR=0x3, ISR=0x3, t=1188.
Is this the same issue? Thanks.
--
John M Flinchbaugh
[email protected]
On Tue, 19 Dec 2006, John M Flinchbaugh wrote:
> I saw a mention of interrupt handling for forcedeth cards is the
> 2.6.19.1 changelog, but I still see this error in 2.6.19.1. It started
> in 2.6.19, and it didn't happen in 2.6.18.1.
Nope; the issue fixed in 2.6.19.1 has always existed (provided you had
hardware suitable to trigger it). And it was an issue of getting bogus
legacy interrupts when using MSI, which would lead to some other device on
the same legacy interrupt getting disabled.
I'd suggest reverting 0a07bc645e818b88559d99f52ad45e35352e8228 (fixes a
lockdep warning, stuff with interrupts, only build tested) as a first
guess.
-Daniel
*This .sig left intentionally blank*