Comment 205 for bug 124406

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

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 is fixed!

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 MISTAKE!

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

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 as possible!