On Tue, 8 Mar 2005, vivek goyal wrote: > > > 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?
I don't think so; more likely it will cause the system to hang. You'll have an IRQ stuck on, constantly interrupting the CPU. But I haven't tried it, so maybe I'm wrong. Alan Stern ------------------------------------------------------- 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
