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

[Alan Stern]

On Tue, 12 Jul 2005, Michel Bouissou wrote:

> I've booted with the patched kernel in the following way:
> 
> - BIOS option for mouse support still off ;
> 
> - Kernel commandline:
> kernel /vmlinuz-2.6.12-6mib7test root=/dev/evms/lv_racine ro 3 usb-handoff 
> devfs=nomount noquiet vga=791

Okay, good.

> - USB mouse plugged to what I believe to be the USB 2.0 controller (according 
> to the motherboard manual)
> 
> First thing I notice at boot is that "mouse doesn't work".

As I explained in the previous message, the mouse ends up being connected 
to a UHCI controller no matter what port you plug it in to.

> cat /proc/interrupts shows :
>            CPU0       
>   0:     208937    IO-APIC-edge  timer
>   1:        334    IO-APIC-edge  i8042
>   2:          0          XT-PIC  cascade
>   4:        464    IO-APIC-edge  serial
>   7:          3    IO-APIC-edge  parport0
>  14:       1321    IO-APIC-edge  ide4
>  15:       1330    IO-APIC-edge  ide5
>  18:        822   IO-APIC-level  eth0, eth1
>  19:      14157   IO-APIC-level  ide0, ide1, ide2, ide3, ehci_hcd:usb4
>  21:      33962   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
>  22:          0   IO-APIC-level  VIA8233
> NMI:          0 
> LOC:     208855 
> ERR:          0
> MIS:          0

Interesting, isn't it?  Even though the UHCI controllers are unable to 
generate interrupts, you're still getting thousands of interrupts requests 
on IRQ 21.

> Looking at dmesg or /var/log/mesages shows a huge number of :
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.0: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.1: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
> 
> (3043 similar lines...)
> 
> ...immediately at startup, then it stops complaining
> 
> The interesting thing is that I unplugged my USB mouse at 19:45 -- nothing 
> happened, and plugged it back at 19:45:40, while looking at a "tail 
> -f /var/log/messages"
> 
> And see what happened in the attached copy of my /var/log/messages for this 
> session...
> 
> Doesn't mean anything to me ;-) but I hope it will be of some help for you...

Status = 0 means the UHCI controller has no reason to request an
interrupt.  Given the good record of your hardware in the past, this
probably means that the controllers really were not generating interrupt
requests.  The alternative is that one of them _is_ generating an IRQ when 
it's not supposed to -- this seems pretty unlikely.

On the other hand, _something_ was generating an interrupt request that 
got mapped to IRQ 21 by the hardware.  And these requests do seem to be 
associated with USB activity.  Maybe the EHCI controller is responsible?
One of your postings showed both uhci_hcd:usb2 and ehci_hcd:usb4 mapped to 
IRQ 11.  That could indicate a shared signal line, which is currently 
being mapped incorrectly.

You can test this a couple of ways.  The easiest is to rmmod ehci_hcd, or 
prevent it from being loaded in the first place, by renaming 
/lib/modules/.../drivers/usb/host/ehci_hcd.ko so that modprobe can't find 
it.  Also your BIOS may offer the option of disabling USB 2.0 support 
entirely.  Try doing this under the kernel that has the test patch 
installed.

Without ehci_hcd loaded, the EHCI controller should not generate any
interrupt requests.  If your problem then goes away, and plugging or
unplugging the mouse doesn't cause anything unusual to happen, that will
be a pretty clear indication.

Alan Stern

-
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/