Bug 13505
| Summary: | USB keyboard/mouse unresponsive for few seconds at a time | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Marcus Better (marcus) |
| Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | akpm, diegocg, mr, stern |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
kernel config
output of lspci -v |
||
Created attachment 21851 [details]
output of lspci -v
Any strange message in dmesg? (In reply to comment #2) > Any strange message in dmesg? Yes, I see messages about auto-suspend. When I start using the keyboard, I get: Jun 15 09:53:07 better kernel: uhci_hcd 0000:00:1d.0: release dev 2 ep81-INT, period 8, phase 4, 118 us Jun 15 09:53:07 better kernel: uhci_hcd 0000:00:1d.0: release dev 2 ep82-INT, period 8, phase 4, 118 us Jun 15 09:53:07 better kernel: usb 5-1: usb auto-suspend Jun 15 09:53:09 better kernel: hub 5-0:1.0: hub_suspend Jun 15 09:53:09 better kernel: usb usb5: bus auto-suspend Jun 15 09:53:09 better kernel: usb usb5: suspend_rh Jun 15 09:53:10 better kernel: usb usb5: usb resume Jun 15 09:53:10 better kernel: usb usb5: wakeup_rh Jun 15 09:53:10 better kernel: hub 5-0:1.0: hub_resume Jun 15 09:53:10 better kernel: uhci_hcd 0000:00:1d.0: port 1 portsc 01a5,01 Jun 15 09:53:10 better kernel: hub 5-0:1.0: port 1: status 0303 change 0004 Jun 15 09:53:10 better kernel: hub 5-0:1.0: state 7 ports 2 chg 0002 evt 0000 Jun 15 09:53:10 better kernel: uhci_hcd 0000:00:1d.0: port 1 portsc 01a5,01 Jun 15 09:53:10 better kernel: usb 5-1: usb wakeup-resume Jun 15 09:53:10 better kernel: usb 5-1: finish resume Jun 15 09:53:10 better kernel: uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period 8, phase 4, 118 us Jun 15 09:53:10 better kernel: uhci_hcd 0000:00:1d.0: reserve dev 2 ep82-INT, period 8, phase 4, 118 us Jun 15 09:53:10 better kernel: hub 5-0:1.0: resume on port 1, status 0 Jun 15 09:53:10 better kernel: hub 5-0:1.0: port 1, status 0303, change 0004, 1.5 Mb/s After a few seconds the keyboard stops working and I get this: Jun 15 09:53:16 better kernel: uhci_hcd 0000:00:1d.0: release dev 2 ep81-INT, period 8, phase 4, 118 us Jun 15 09:53:16 better kernel: uhci_hcd 0000:00:1d.0: release dev 2 ep82-INT, period 8, phase 4, 118 us Jun 15 09:53:16 better kernel: usb 5-1: usb auto-suspend Jun 15 09:53:18 better kernel: hub 5-0:1.0: hub_suspend Jun 15 09:53:18 better kernel: usb usb5: bus auto-suspend Jun 15 09:53:18 better kernel: usb usb5: suspend_rh The problem seems to go away if autosuspend is disabled for the hub with "echo on > /sys/bus/usb/devices/5-1/power/level".
I find this comment from Documentation/usb/power-management.txt interesting:
>Sometimes it turns out that even when a device does work okay with
>autosuspend there are still problems. For example, there are
>experimental patches adding autosuspend support to the usbhid driver,
>which manages keyboards and mice, among other things. Tests with a
>number of keyboards showed that typing on a suspended keyboard, while
>causing the keyboard to do a remote wakeup all right, would
>nonetheless frequently result in lost keystrokes.
lsusb output:
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 046d:c512 Logitech, Inc. LX-700 Cordless Desktop Receiver
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
An interesting question is how the power/level value got changed from "on" (the default) to "auto" in the first place. Is there a udev script which does it? If there is, it should be possible to disable the script. (In reply to comment #5) > An interesting question is how the power/level value got changed from "on" > (the > default) to "auto" in the first place. Is there a udev script which does it? > If there is, it should be possible to disable the script. That'll probably be hard to work out. Perhaps add a bit of debug code to the kernel which tells us when something enables auto mode? Print the pid and ->comm? Marcus, if you want to try that, look at the code in set_level() in drivers/usb/core/sysfs.c where buf is compared with auto_string. (In reply to comment #5) > An interesting question is how the power/level value got changed from "on" > (the default) to "auto" in the first place. Is there a udev script which > does it? Indeed there is. I overlooked it at first since it was in /lib/udev rather than /etc/udev. I installed it myself last year... I guess autosuspend functionality for keyboards was recently enabled in the kernel, since I didn't have any problems before. same problem here; I had usb autosuspend enabled and had no issues with my USB keyboard and mouse before 2.6.30. so why is this invalid? Shouldn't USB auto suspend work correctly in a sense that it doesn't interrupt the device's usual functionality? On Mon, 29 Jun 2009 bugzilla-daemon@bugzilla.kernel.org wrote: > so why is this invalid? Shouldn't USB auto suspend work correctly in a sense > that it doesn't interrupt the device's usual functionality? Of course it should. But in some cases the hardware doesn't allow it -- and the HID spec allows mice to behave in this braindead way. Furthermore, there's no way for the kernel to tell whether or not a mouse will wake up when it is moved. So there's nothing we can do about it. The problem is in the mouse, not in the kernel. The solution is: If your mouse doesn't support remote wakeup properly, then don't enable autosuspend. Alan Stern |
Created attachment 21850 [details] kernel config After upgrading from 2.6.29.4, the USB-attached Logitech keyboard and mouse started losing key presses and mouse events. It occasionally ignores all keystrokes and mouse events for 5-10 seconds at a time. Then it just starts working again. It happens a few times per minute. The built-in keyboard continues to work all the time. This is a Thinkpad T61 running Linux x86_64, Debian, X.org 1.6.1.901, Intel X.org driver 2.7.99.1 with KMS.