Messages in this thread | | | From | Michel Bouissou <> | Subject | Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble | Date | Wed, 13 Jul 2005 00:01:06 +0200 |
| |
Le Mardi 12 Juillet 2005 23:37, Alan Stern a écrit : > > Then it's definite. The EHCI controller is issuing interrupt requests on > IRQ 21, but its driver is registered on a different IRQ. Hence the > interrupts aren't getting handled correctly. > > So probably the usb_handoff parameter won't be needed. And if you leave > USB 2.0 disabled in the BIOS then there's no need to hide ehci_hcd.ko, as > it won't get loaded anyway. You should be able to remove the test patch > and resume normal operations.
I've just booted an IO-APIC capable kernel without the test patch (but with Nathalie's 2 patches), without "usb_handoff", with USB 2.0 DISABLED and USB mouse support ENABLED in BIOS.
It seems it works good, and ehci support is not loaded.
[root@totor etc]# cat /proc/interrupts CPU0 0: 425367 IO-APIC-edge timer 1: 1698 IO-APIC-edge i8042 2: 0 XT-PIC cascade 4: 1169 IO-APIC-edge serial 7: 2 IO-APIC-edge parport0 14: 3337 IO-APIC-edge ide4 15: 3346 IO-APIC-edge ide5 16: 15142 IO-APIC-level nvidia 18: 1707 IO-APIC-level eth0, eth1 19: 25211 IO-APIC-level ide0, ide1, ide2, ide3 21: 3210 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3 22: 2761 IO-APIC-level VIA8233 NMI: 0 LOC: 425302 ERR: 0 MIS: 0
Plugging or unplugging USB devices doesn't cause no IRQ insults anymore ;-)
> On Tue, 12 Jul 2005, Protasevich, Natalie wrote: > > I suspect that some device is actually on the IRQ 21, and that's how its > > IO-APIC line is set up. Later on, its driver tries to assign different > > IRQ, due to some discrepancy, and the handler gets registered on say IRQ > > 11, and to a wrong pin, so the actual interrupts go unattended. If this > > what's happening, the trace will hopefully tell the story. I suggest to > > boot with "apic=debug" and also perhaps with "pci=routeirq" and collect > > the trace. You can attach the part up to the point when it reports usb > > devices set up. > > At this point I can leave it up to the two of you.
Well, many thanks again for you precious help Alan !
> Now that we know which is the offending device, it should be easy to find > out why the IRQ assignments go wrong. That certainly needs to be fixed, > even though Michel's problem appears to be solved.
Well, it's solved by currently giving me the choice between no USB 2.0 and IO-APIC, or USB 2.0 and no IO-APIC. That makes a temporary solution, but I'd love to have both (and recall the happy times of 2.4x that was happy with both ;-)
Natalie, could you please tell me which kernel (I have started to have a number of them ;-) you'd like me << to boot with "apic=debug" and also perhaps with "pci=routeirq" and collect the trace >>, and with which BIOS setup ? (i.e. USB 2.0 enabled or disabled ?).
When you speak about "collecting the trace", I assume you mean the dmesg or /var/log/messages I'll get after booting this way ?
Thanks again to both of you Alan and Natalie. Everytime I run into serious trouble I remember why I love Free Software and the Free Software Community ;-)
Cheers.
-- Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |