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.
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