Turning off/on screen causes severe USB stall problems

[jessicah]

If I turn off my monitor and turn it on again, my USB devices such as keyboard & mouse end up suffering from severe USB stall problems.

[pulkomandy]

Is there anything special with the monitor? eg. does it include an USB hub or something similar?

Also, I think you mentionned interrupt problems, so output of the KDL "ints" command (before and after the problem) could be useful.

[jessicah]

Sorry, I must have remembered incorrectly or imagined something. I can't seem to find any mention of interrupt issue in my logs.

Anyway, the monitor does have an inbuilt USB hub, however, it isn't connected to the PC. Only connection between monitor and PC is the DisplayPort cable.

[mmlr]

If it's not even connected to the USB then the it can't really be a USB issue. The USB driver is most likely a victim of an interrupt sharing issue. Looking at your log there's a lot of contention on interrupt line 0x0b (11):

device 0162: Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
interrupt_line 0b, interrupt_pin 01, min_grant 00, max_latency 00

device 1e31: 7 Series/C210 Series Chipset Family USB xHCI Host Controller
interrupt_line 0b, interrupt_pin 01, min_grant 00, max_latency 00

device 1e3a: 7 Series/C210 Series Chipset Family MEI Controller #1
interrupt_line 0b, interrupt_pin 01, min_grant 00, max_latency 00

device 1e2d: 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2
interrupt_line 0b, interrupt_pin 01, min_grant 00, max_latency 00

device 1e10: 7 Series/C210 Series Chipset Family PCI Express Root Port 1
interrupt_line 0b, interrupt_pin 01

device 1e22: 7 Series/C210 Series Chipset Family SMBus Controller
interrupt_line 0b, interrupt_pin 03, min_grant 00, max_latency 00

Unfortunately the only 3 drivers using MSIs (ahci, ipro1000 and hda) actually have devices on unshared interrupts anyway. This means they don't alleviate the situation at all. The EHCI controllers do not advertise MSI capabilities, so MSIs aren't used for them.

Obviously the vesa driven graphics controller is the prime suspect here. It does share an interrupt with one of the EHCI controllers which can easily explain the problem. To verify that, please plug your USB devices to a port handled by the other EHCI controller (i.e. so that it gets an address of /dev/bus/usb/1/0/x):

device 1e26: 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1
interrupt_line 04, interrupt_pin 01, min_grant 00, max_latency 00

This one doesn't share its interrupt and should therefore not be affected, unless the stall is actually an interrupt storm and hangs the whole system.

[jessicah]

After finding a USB port that's on the other EHCI controller, I have confirmed that turning off & on the monitor no longer interferes with the keyboard/mouse USB devices.

~> listusb
8087:0024 /dev/bus/usb/0/0/hub "Intel Corp." "Integrated Rate Matching Hub" ver. 0000
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "EHCI RootHub" ver. 0200
045e:07a5 /dev/bus/usb/1/0/6 "Microsoft Corp." "Microsoft 2.4GHz Transceiver v9.0" ver. 0767
8087:0024 /dev/bus/usb/1/0/hub "Intel Corp." "Integrated Rate Matching Hub" ver. 0000
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "EHCI RootHub" ver. 0200