Opened 10 years ago
Last modified 10 years ago
#12060 new bug
Turning off/on screen causes severe USB stall problems
Reported by: | jessicah | Owned by: | mmlr |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/USB | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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.
Attachments (3)
Change History (7)
by , 10 years ago
Attachment: | usb-stall.log added |
---|
by , 10 years ago
Attachment: | listdev.txt added |
---|
by , 10 years ago
Attachment: | listusb.txt added |
---|
comment:2 by , 10 years ago
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.
comment:3 by , 10 years ago
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.
comment:4 by , 10 years ago
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
Is there anything special with the monitor? eg. does it include an USB hub or something similar?