USB Mouse Freezes after a While

[bonefish]

After a while of use in Haiku, the USB mouse freezes and the serial debug output shows:

Disabling unhandled io interrupt 11

The touch pad continues to work.

Revision is hrev23895. Computer is a Lenovo Thinkpad T61 attached to a docking station. The mouse is connected to the USB port built-into the laptop (already before booting). When connected to the docking station USB ports it doesn't work at all. No other USB devices are attached. Unless I've overlooked it, there's no BIOS option to enable or disable USB legacy support (there's a "USB BIOS Support", which is enabled, but it is described as support for booting from USB disk/CD drive). IIRC, the attached serial debug output is from a session after a warm start.

[bonefish]

Serial Debug Output T61

[marcusoverhagen]

A list of your PCI devices that share IRQ 0xb (11)

[marcusoverhagen]

The message "Disabling unhandled io interrupt 11" at the end of your syslog indicates that some PCI device that uses interrupt 11 isn't properly handled by a driver, and keeps interrupting without beeing acknowledged. Can you please attach the output of the "int" KDL command?

2288 usb_ehci: controller is still bios owned, waiting 2289 Last message repeated 7 times. 2290 usb_ehci: bios won't give up control over the host controller 2291 usb_ehci: bus failed init check

indicates that there is a problem with a USB controller.

[marcusoverhagen]

To narrow down the source of the problem, you should first remove the HDA audio driver and test again.

Continue with removing uhci and then ehci drivers.

[bonefish]

int output:

kdebug> int
int   0, enabled 1, handled        0, unhandled        0
        0x80090040
int   1, enabled 1, handled        9, unhandled        0, ACTIVE
        0x9080ed4c
int  10, enabled 2, handled     4727, unhandled        0
        0xa3288178      0x802a8fe0
int  11, enabled 6, handled       13, unhandled      273
        0xa3288178      0xa3288178      0xa3288178      0xa3288178      0xa3248b24      0x80456820
int  12, enabled 1, handled       17, unhandled        0
        0x9080ed4c
int  14, enabled 1, handled      319, unhandled        0
        0x802fdac8
int  15, enabled 1, handled        0, unhandled        0
        0x802fdac8
int 219, enabled 1, handled   106428, unhandled        0
        0x8008f138
int 221, enabled 1, handled    30338, unhandled        0
        0x8008f14c
int 222, enabled 1, handled        0, unhandled        0
        0x8008f174
int 223, enabled 1, handled        0, unhandled        0
        0x8008f160
kdebug> ls 0xa3288178
0xa3288178 = InterruptHandler__4UHCIPv + 0x0 (/boot/beos/system/add-ons/kernel/busses/usb/uhci)
kdebug> ls 0xa3248b24
0xa3248b24 = InterruptHandler__4EHCIPv + 0x0 (/boot/beos/system/add-ons/kernel/busses/usb/ehci)
kdebug> ls 0x80456820
0x80456820 = em_intr_fast + 0x0 (/boot/beos/system/add-ons/kernel/drivers/dev/net/ipro1000)

I'll start with removing the ipro1000. The problem isn't that quickly reproducible, though. With "after a while" I mean like half an hour or more.

[bonefish]

Unless I remove both UHCI, EHCI, and ipro1000 drivers, "int" still shows lots of unhandled interrupts for vector 11. If I remove them all, interestingly the USB mouse still works. I can't find a related BIOS option, that sounds like it would enable a PS/2 emulation, though.

[bonefish]

When I remove only the HDA driver, the touch pad, track point, and built-in keyboard don't work. The USB mouse still works, though. PS/2 related serial output:

ps2_hid: init_hardware
ps2_hid: init_driver
ps2_hid: publish_devices
ps2_hid: publish_devices() returned NULL.
ps2_hid: uninit_driver
ps2: devfs_publish_device input/mouse/ps2/0, status = 0x00000000
ps2: devfs_publish_device input/keyboard/at/0, status = 0x00000000
ps2: probe_mouse reset failed
ps2: probing mouse input/mouse/ps2/0 failed
ps2: devfs_unpublish_device input/mouse/ps2/0, status = 0x00000000
ps2: keyboard reset failed, status 0x80000009, data 0x00
ps2: keyboard probing failed
ps2: devfs_unpublish_device input/keyboard/at/0, status = 0x00000000

[mmlr]

While it might not sound like that, the "USB BIOS Support" most certainly is USB legacy support. If you can remove UHCI and EHCI and the mouse still works it must be legacy support. That's by the way why EHCI reports that the controller is BIOS owned. You could simply switch that option in the BIOS and see if the mouse then behaves differently.

[marcusoverhagen]

Trying again to comment on this:

The ps2 debug output indicates that the BIOS is trapping access to the PS/2 io-ports, but is not providing legacy emulation. I don't know how this can happen, but you are not the only one with this problem. There is at least one similar bug.

The interrupt debug code will disable an interrupt when less than 1% of 100000 interrupts was handled. The code seems to be broken for ISA interrupts, but thats not an issue here. Linux uses 0.1%

Why the HDA driver has such an influence I don't know. I also don't understand why it's not using any interrupt.

The BIOS might provide legacy keyboard/mouse support regardless of the "USB BIOS Support" setting, you can test this by removing uhci, ohci and ehci drivers, and testing both settings.

Complete syslogs would be nice, especially with/without the HDA driver. You should also cold-reboot between tests.

[mmlr]

I had this happening for me yesterday, just for the keyboard and not the mouse. The reason is the disabling of the interrupt. Like for you it disabled interrupt 11 after about half to a three quarter of an hour. The reason is clearly the disabling as this is a shared interrupt that in my setup is used by VGA, some "communication device", a video capture and multimedia device, one of the SATA controllers and 3 UHCI and 1 EHCI controller. My mouse kept working, as it apparently happened to be on one of the other 3 UHCI controllers that use interrupt vector 9. At first I thought it might be the multimedia device which should be HDA, but enabling extra debug output revealed that there is an unhandled interrupt for vectors 10 and 11 happening very frequently (more than once a second). That's the two interrupts that the two SATA controllers use, so I assume it really is a problem with that.

[mmlr]

Any chance that the forced initialization order changed the behaviour? In theory at least the "BIOS won't give up control over the host controller" could be fixed by that. Also there should be a change, as we do currently not disable shared interrupts anymore. On the other hand the message about unhandled interrupts should show up earlier and more frequent now, so a new serial/syslog would be interesting.

[stippi]

I have not tested again after the recent changes, but I can add that I experienced the mouse freeze on a system that was running ZETA with Haiku's USB stack. So it should definitely be (or have been) a problem in the USB stack itself and has nothing to do with the interrupt handling, unless there are two issues with the same symptoms.

[bonefish]

Since your change I haven't run Haiku over a longer time yet, but after a short test everything looks fine. "int" doesn't show any unhandled interrupts anymore. My external keyboard works again (it didn't for a while). I can arbitrarily plug mouse and keyboard into different ports (docking station and internal) and they continue to work. Everything seems to work like a charm now. :-)