I’ve had a problem with recent kernels. (I think it’s the kernel that’s doing this.) When my workstation is doing heavy I/O, it repeats keystrokes. For instance, while I was typing this paragraph, audacity was writing audio to disk, and I got this word:
heavvvvvvvvvvvy
It seems as if it thinks I haven’t let up on the keys.
I’ve seen this on two different machines and it seems to have started with 2.6.24 or 2.6.25.
Has anyone else seen this? Any ideas where I’d go to fix it? Incidentally, I’m in X when this happens. I don’t use the console much when there would be a chance for it to happen.
This is such a weird problem I’ve struck out googling, and I’m not even sure which mailing list to take it to.
I have also had this happen to me. I haven’t been able to track it down either. I don’t have access to the Linux box that does this right now, but the kernel in it is usually very up to date.
I also see this frequently happen. The chars keep on repeating until i press a key, then it stops.
I even managed to get letters in random order, some repeated, some suppressed, as my late powerbook’s kernel was stuck in some heavy loops (triggered by an uninvestigated bug related to the ‘eject’ key).
You can try showkey -s (as root), or showkey -k, showkey -m
This will tell you if the problem is in the kernel or in X.
You can also try putting some printk lines in either
drivers/input/keyboard/atkbd.c
drivers/hid/hid-input.c (USB keyboard)
If it is the kernel, these weird problems I think the only way to debug is to use git bisect. It uses a binary search to narrow down exactly which commit caused the problem.
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
http://www.kernel.org/doc/local/git-quick.html
As mentioned in the first link, you can probably cut down on the commits to test by only bisecting in the drivers subdirectory.
Yes, I have also seen this happen. It appears to happen only on multicore machines. One explanation I have heard is that after the key is pressed, there is a context switch to a different CPU core and the key release is lost somewhere. The likelihood of that happening is obviously higher if the machine is busy.
> It appears to happen only on multicore machines.
No, it happens on my laptop too, which is not multi-core.
There’s been some discussion of this issue on linux-kernel (not particularly recently, but in an appropriate timeframe given the kernels currenly in Debian).
Linux-kernel seems to mostly come to the conclusion that this is due to scheduling. X doesn’t take advantage of hardware keyboard repeats, instead synthesizing keyboard events from state and time. So something like: X sees “v” pressed, X doesn’t get scheduled for a while, X comes back and sends 30*”v”, then X sees “v” released.
XFree86/Xorg certainly used to rely on keyboard hardware repeat. If I unplugged a keyboard and plugged it back in, the effective repeat settings would return to the hardware defaults. Opening and closing GNOME keyboard properties would restore them. So perhaps it’s a recent change in Xorg, not the kernel, that has made keyboard repeat unreliable.
I fixed a similar problem like this: http://unrealvoodoo.org/hiteck/blog/hardware/repeating-key-bug-with-usb-keyboard/
I have the same problem too.. It even breaks the sound that I’m listening to, and this is a dual-core 2Ghz, 2Gb RAM machine..
It’s good to see I’m not the only one :-)
Hi,
I’ve seen this too on Debian systems. Could it be related to the CONFIG_GROUP_SCHED parameter set in the debian kernel configs? It’s not set on the fedora kernels and I haven’t seen this issue there. There are also bug reports with requests to change the settings for CONFIG_GROUP_SCHED in the debian kernel. Maybe they should enable the CGROUPS setting for CONFIG_GROUP_SCHED instead of the per_user setting?
Thanks to everyone for all the tips. It looks like this CONFIG_GROUP_SCHED is the most likely culprit; I will have to try tweaking that and see if it fixes things for me.
Did we file a bug yet? :)
I have also been seeing this, for at least a year, with both usb and ps2 keyboards and it drives me mad.
Thanks for investigating this