David Woodhouse <[email protected]> : > From: David Woodhouse <[email protected]> > > The TX timeout handling has been observed to trigger RX IRQ storms. And > since cp_interrupt() just keeps saying that it handled the interrupt, > the machine then dies. Fix the return value from cp_interrupt(), and > the offending IRQ gets disabled and the machine survives.
I am not fond of the way it dissociates the hardware status word and the software "handled" variable. What you are describing - RX IRQ storms - looks like a problem between the irq and poll handlers. That's where I expect the problem to be solved. Sprinkling "handled" operations does not make me terribly confortable, especially as I'd happily trade the old-style part irq, part napi processing for a plain napi processing (I can get over it though :o) ). Once the code is past the "if (!status || (status == 0xFFFF))" test - or whatever test against some mask - I don't see why the driver could refuse to take ownership of the irq. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
