Frank, It is possible that since this IRQ line is shared with device 00:07.2 that the interrupt is being asserted by the other device, but only the pcnet32 (device 00:0b.0) driver has registered to service the interrupt. As the interrupt is enabled, the pcnet32 driver finds no interrupt pending for the pcnet, and returns. The sharing driver should then (or previously) be called. If no other driver exists, the interrupt will not be cleared, resulting in infinite interrupts, like what you are seeing. Good luck with your debugging. FYI this also is seen on 2.6 kernels. On Fri, May 13, 2005 at 07:07:23PM +0200, Salomon, Frank wrote: > Hi Don, > in the meantime I find out that the system generates permanently > interrupts from the pcnet32 chip after calling request_irq. > You are correct, the problem is outside of the pcnet32 driver, because > the driver from kernel version 2.4.18 is also producing that problem. In > both driver version, the code near by the call request_irq is the same. > Next week I will go forward to analyze that problem. I think the article > you found is helpful. > > Many thanks to you, best regards, Frank -- Don Fry brazilnut@xxxxxxxxxx - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
