[Bug 124406] Re: Keyboard keys get stuck and repeat (Feisty, Gutsy)
donweber at starpower.net
Mon Dec 29 07:22:33 UTC 2008
At first, I thought my keyboard was going bad, so I replaced it with a
new keyboard. No change, so here I am, fully loaded for bear!
The following kernels -- vmlinuz-2.6.24-19-generic,
vmlinuz-2.6.24-21-generic, vmlinuz-2.6.24-22-generic -- all have this
problem. I'm sorry, I no longer have any earlier kernels which DON'T
have the "keys stick" problem, to estimate approximately when this
problem first appeared.
If I knew of or could find an earlier version of a kernel which does NOT
have the "keys stick" problem, I would download it immediately, and I
would revert to it instantly! It's that SERIOUS for me!
For me, since I spend most of my time in Linux using the keyboard, the
kernel frequently and unexpectedly drops/skips/misses REAL, ORDINARY
key-strokes/key-presses/key-releases, which SERIOUSLY interferes with my
This bug can even stop "mouse keys" and mouse clicks from working.
Deactivating and then reactivating "mouse keys" does NOT turn "mouse
keys" back on or start "mouse keys" working again. And sometimes it's
almost impossible to get mouse CLICKS to work again!
About half of the time, this problem also causes the "Caps Lock" Key and
the "Caps Lock" keyboard LED to get out of sync -- when the LED is OFF,
we get UPPER-CASE (should get lower-case) and when the LED is ON, we get
lower-case (should get UPPER-CASE)! I have not yet figured out any way
to get the two back in sync without rebooting.
For me, turning off "key repeat" does NOT really help! The key is still
"stuck"/unreleased, and while it is unreleased, other keys either don't
work at all or don't work right.
Quite often -- FAR TOO OFTEN! -- the only way to recover from a really
nasty "stuck key" situation is to REBOOT! (Sometimes unavoidably in the
middle of an "unsaved work" situation! Aarrgghh!) And even rebooting
is sometimes extremely difficult, because it's the kernel that's keeping
the keyboard and the mouse from working! Catch 22!
I have a very fast 3.2GHz dual-core AMD Athlon 6400+ CPU, but, of
course, that doesn't help if KEYBOARD INTERRUPTS are given a LOW
PRIORITY; that would mean, "We will ignore (LOSE!) all key-strokes/key-
presses/key-releases unless or until we have absolutely nothing else or
nothing better to do."
To try to minimize the occurrence of this problem for me, before
beginning any keyboard-intensive work (which is most of my work), I try
to turn Linux into a "zero"-tasking system -- no e-mail, no open
browser, no downloading, no grep-ing, no find-ing, no audio player, no
video player, no DVD burning, no searching, no installing, i.e., as much
as possible, no nothing! But sooner or later, the kernel finds
something to do that it thinks is "more important" than honoring
keyboard interrupts, so eventually, unexpectedly and unpredictably,
keystrokes suddenly get messed up again! Since this happens completely
randomly, there is no reproducible "test case" for this bug. Until the
appearance of this "keys stick" bug, I enjoyed having Linux successfully
do MANY things simultaneously in the background while I merrily did my
keyboard-intensive work, with NO problems! But NO MORE!, until this bug
This feels like the resurfacing of a very old programming logic error.
When programming a real-time module's interrupt priorities, it's easy to
forget that the most important part of any computer system is the *User*
-- the HUMAN at the KEYBOARD! Thus, the *KEYBOARD'S* interrupts (and
the MOUSE'S actions) should have the very highest priority (of course,
the Real-Time Clock must have the *VERY* HIGHEST priority!). If any
disk I/O, network I/O, multi-tasking interrupts, etc., are given higher
priorities than the keyboard and the mouse, then any run-away or high-
intensity activity can take over the system, and the User would have no
way of regaining control of the system! The *User*'s *KEYBOARD*/*MOUSE*
actions *MUST* take priority over EVERYTHING else (except the RTC)!
Thinking that other activities are "more important", "more urgent",
"more demanding", or "more critical", it is very tempting to give all
those "other activities" higher priorities than the lowly keyboard (and
mouse), but, from experience, that ALWAYS turns out to be a SERIOUS
In my 48+ years of system programming experience, I have seen this well-
intended, but BADLY MIS-GUIDED ERROR of giving the "lowly" keyboard
interrupts a low priority, far too many times, always with BAD
consequences! If the keyboard cannot interrupt ANYTHING and EVERYTHING
that's going on, then the User/HUMAN loses control of the system!
Or, at the very least, his typing -- his use of the keyboard -- gets
messed up, like what's currently happening!
The above explanation may not exactly describe the cause of the current
problem, but I hope it can help lead to finding and fixing the real
cause of the current problem, or at least help to AVOID creating a new
problem (like the one described above) while trying to FIX the current
I'm really appreciate that someone mentioned that the new 8.10
Intrepid/Infected Ibex is also afflicted with this crippling "stuck
keys" bug. Although I have the new 8.10 DVD, I will now be aware, if I
should decide to install it, that I will be stuck with a sick Ibex,
since I will not be able to revert it or uninstall it!
I desperately need a GOOD kernel which does NOT mess up my key-strokes
or mouse-clicks! I'm hoping that a new kernel that doesn't ignore or
lose any key-strokes/key-presses/key-releases will be released as soon
Keyboard keys get stuck and repeat (Feisty, Gutsy)
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.
More information about the kernel-bugs