Kernel version exhibiting the problem: 2.6.34.4-41.fc13.i686.PAE from koji. It seems the input subsystem/driver is losing the first keystroke in a sequence: 1. After idling some seconds in the tty2 console bash prompt I hit Q, W and E at "typing speed". 2. Only 'w' and 'e' are echoed. 3. If I keep typing it's OK. If I stop and resume typing after some seconds the 1st keystroke is lost again. I used evtest on the device and it too doesn't get the 1st keystroke in a sequence so the problem seems to be indeed inside the kernel. The current F13 kernel version 2.6.33.6-147.2.4.fc13.i686.PAE works OK. Any hints on debugging this further? Some kernel boot flags perhaps?
I'm seeing this too, but not on every machine. What kind of hardware is it happeing on for you? Please attach (as attachments, not inline text) output of the 'lspci -vnn' command and contents of /proc/cpu. Also, is your keyboard USB or PS/2?
Created attachment 440093 [details] lspci -vnn
Created attachment 440094 [details] /proc/cpuinfo
Created attachment 440095 [details] lsusb -v The keyboard is USB. It's the Lite-On Tech IBM USB Travel Keyboard with UltraNav. Here's what the kernel prints about it: usb 2-1.5.3: new low speed USB device using ehci_hcd and address 4 usb 2-1.5.3: New USB device found, idVendor=04b3, idProduct=3019 usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1.5.3: Product: IBM USB Travel Keyboard with UltraNav usb 2-1.5.3: Manufacturer: Lite-On Tech input: Lite-On Tech IBM USB Travel Keyboard with UltraNav as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.3/2-1.5.3:1.0/input/input9 generic-usb 0003:04B3:3019.0001: input,hidraw0: USB HID v1.00 Keyboard [Lite-On Tech IBM USB Travel Keyboard with UltraNav] on usb-0000:00:1d.0-1.5.3/input0 input: Lite-On Tech IBM USB Travel Keyboard with UltraNav as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.3/2-1.5.3:1.1/input/input10 generic-usb 0003:04B3:3019.0002: input,hidraw1: USB HID v1.00 Device [Lite-On Tech IBM USB Travel Keyboard with UltraNav] on usb-0000:00:1d.0-1.5.3/input1
*** Bug 626219 has been marked as a duplicate of this bug. ***
Does booting with the kernel option "usbcore.autosuspend=-1" make any difference?
(In reply to comment #6) > Does booting with the kernel option "usbcore.autosuspend=-1" make any > difference? That makes it worse: no input from the USB keyboard is registered with that option.
Try running this command as root instead of using the usbcore.autosuspend option: for node in /sys/bus/usb/devices/*/power/control; do echo "on" >$node ; done
(In reply to comment #8) > Try running this command as root instead of using the usbcore.autosuspend > option: > > for node in /sys/bus/usb/devices/*/power/control; do echo "on" >$node ; done This seems to fix it, yes.
With: # uname -a Linux zeus.lan 2.6.34.5-44.fc13.x86_64 #1 SMP Mon Aug 23 00:25:05 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux The following: # echo on > '/sys/class/input/input4/device/power/control' fixes the problem. Which is the end effect of: for i in /sys/class/input/input*/device; do C=`cat $i/bInterfaceClass` SC=`cat $i/bInterfaceSubClass` P=`cat $i/bInterfaceProtocol` # 03 01 01 == Human Interface Device, Boot Interface SubClass, Keyboard if [[ $C$SC$P == 030101 ]]; then echo "${i}" echo on > "${i}/power/control" fi done 2>/dev/null
Should be fixed in 2.6.34.5-45
Posted upstream: http://marc.info/?l=linux-usb&m=128272657410313&w=2
I confirm this is a problem in f13 updates-testing, and that it is fixed by kernel-PAE-2.6.34.6-47.fc13.i686 (and probably earlier).
Closing this now since the bug never hit a released kernel.