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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |