Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble

[Michel Bouissou]

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@xxxxxxxxxxxx> OpenPGP ID 0xDDE8AC6E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/