> The problem comes when two devices share an IRQ line and at least one of > them is actively generating interrupt requests. An ethernet interface or > a USB controller would make a good example, if they weren't shut down > properly during a kexec reboot. > > Let's say devices A and B share the same IRQ, and B has an interrupt > request pending. Initially all the IRQ lines are disabled; they only get > enabled as drivers request them. So consider what happens when the driver > for A is initialized. It will probe A and will request the IRQ line be > enabled. B's outstanding request will immediately interrupt the > processor. But since there's no driver loaded for B, nobody will claim > the interrupt or clear its source. > > Result: The kernel warns about interrupts not owned by a driver, and > automatically disables the IRQ line. Now device A is in trouble. > Obviously it can't function correctly without interrupts. B will be in > trouble too, when its driver loads.
Will "noirqdebug" command line option help in this case as a temporary solution? > > This is exactly what happened to Laurent Riffard in > > http://bugme.osdl.org/show_bug.cgi?id=4294 > > Read his full dmesg attachment; you can see where IRQ 5 was triggered as > soon as one of the USB controllers enabled it. Apparently the other USB > controller had a pending interrupt. > > Things wouldn't be quite so bad if setup_irq() would re-enable a disabled > shared IRQ when another driver requests it, but it doesn't. Is this > behavior a bug or is it deliberate? > > Alan Stern > > _______________________________________________ > fastboot mailing list > [EMAIL PROTECTED] > http://lists.osdl.org/mailman/listinfo/fastboot ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
