Keyboard keys get stuck and repeat

[Guy Gur-Ari]

Keyboard keys such as the arrows, Alt-F4, PageUp/PageDown, etc. often get 'stuck' and continue being 'clicked' even after they are physically released. For example when clicking Alt-F4, sometimes it gets stuck so all the windows are closed instead of just one.

My configuration is Feisty + Xgl + Compiz Fusion. My previous configuration was Edgy + Xgl + Beryl, where this didn't happen. Others have reported the same problem without using either Xgl or Compiz.

The keyboard itself isn't the problem. When dual-booting to Windows, everything works fine. Also, the problem happens with two different keyboards (internal laptop, external USB).

My best guess is that the problem occurs at time of high system load. Somehow during these times the key-release signal gets lost and the key-press is repeated indefinitely. This happens more often with Compiz configurations because Compiz tends to increase system load. It also happens more often with power-hungry apps like Firefox and Acrobat Reader for similar reasons.

PS: When the keys would repeat all input devices would be locked up. ie. mouse won't move, clicks don't do anything, keyboard presses don't register. Then when it becomes unstuck, the mouse moves around and everything. Hope this helps.

See also this forum thread for other people with the same problem: http://ubuntuforums.org/showthread.php?t=432057

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Thank you for your bug report. Compiz Fusion is not part of Feisty official packages so we can't support it, I'm closing this. If this happens with Feisty's default compiz or with the compiz fusion's official packages in Gutsy, please reopen.

[Guy Gur-Ari (guygurari)]

Someone reported the same problem and he's not using compiz. He is using fglrx, as am I. So I'm reopening. In the forums he says:

 thomascj: I'm having the exact same problem, and I'm not running xgl, or compiz fusion. I am, however, running fglrx. Turning off keyboard repeat fixed it -- but I do use the terminal and it really sucks having to press backspace that many times... Anyone else fixed this problem?

Taken from: http://ubuntuforums.org/showthread.php?t=432057&page=2

By the way, canceling key repeat and lowering key repeat rate seem to be a good workarounds for now.

[JeDi (jeroen-dierckx)]

I am having the same problem, and I don't have XGL or beryl enabled at all. I'm not sure, but I think the problem started occurring after the latest kernel update. I am running an up-to-date feisty kubuntu.

In my opinion, a solution has to be provided as soon as possible, as this almost makes my system unusable at the moment.

Greetz,
JeDi

[Guy Gur-Ari (guygurari)]

Several people confirmed the problem who aren't using compiz fusion.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. JeDi seems to indicate that this started happening after a kernel update so it would be useful to know what kernel everyone is experiencing this with. Thanks in advance.

[Guy Gur-Ari (guygurari)]

For me the problem started when I upgraded from Edgy to Feisty on 22/6/07. Before that I was running the latest Edgy kernel, whatever it was.

Right now I'm running:
Linux thinkpad 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Timo Wiren (timo-wiren)]

I'm having the same problem with vanilla 2.6.22.1 kernel and Feisty. I don't use XGL, Compiz or Beryl. The problem is quite new, started maybe 3 weeks ago.

[Russ (ubuntu-bugs-thewarrens)]

I also have this (very annoying) problem...

2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux
Using fglrx
Definitely happening when XGL & Beryl are running
Also happens hen running a session with no XGL but beryl-manager still running (runs every session)
Unclear at the moment if it still happens after I remember to close beryl-manager

[xermán (xerman.soto)]

This issue happens with Feisty with no desktop effects operative too. I am running Feisty and not just the keyboard, but also the mouse has weird behaviour at times. NO XGL and NO Beryl running

This does not happen all the time. Seems kind of random but everyday happens a couple of times at least. The issue starts, then stops after a while.

Config:

DLink KVM 2 port (server + desktop)
Wacom Graphire 4 at usb port
Bluetooth dongle at usb port
Asus MW221u screen
Asus T3P5G965 barebone
1 GB Ram
Intel Core2duo E6400
1HD sata 160
1HD sata 250
Microsoft Wireles Natural Multimedia Keyboard and mouse

[bean77 (lydia-acheson)]

I have this issue too.

[Brian Murray (brian-murray)]

The full output of the 'dmesg' command after experiencing this event from someone not using Xgl or Beryl, as they are not supported on Feisty, would be quite helpful in tracking down this issue.

[Erkin Bahceci (cornelius1)]

I'm using Xgl + Compiz Fusion on fglrx, and I see this issue once or twice a day (at least since May 2007) on Feisty. I attached the full dmesg log right after the problem appeared, if it helps. The stuck key combination was Alt-Tab this time. It happens with other keys too.
System info:
Linux flux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Erkin Bahceci (cornelius1)]

This was on a 2 year-old Dell Inspiron 6000, with a mobility radeon x300 card, a Pentium M 1.86GHz processor, ipw2200 wireless driver connected via wireless.

I was wondering if it could be related to something else (like NetworkManager) blocking the cpu for a while right when I press a key, so that the key release signal is processed late causing a repeated-key behavior until the key release signal gets through.

The problem appeared at 12:17 on Aug 31 and this is the part of /var/log/daemon.log around that time.

Aug 31 12:16:44 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Aug 31 12:16:51 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
Aug 31 12:17:01 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
Aug 31 12:17:11 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Aug 31 12:17:15 localhost dhclient: No DHCPOFFERS received.
Aug 31 12:17:15 localhost dhclient: No working leases in persistent database - sleeping.
Aug 31 12:17:32 localhost dhclient: DHCPREQUEST on eth1 to 128.83.185.55 port 67
Aug 31 12:17:32 localhost dhclient: DHCPACK from 128.83.185.55
Aug 31 12:17:32 localhost NetworkManager: <information>^IDHCP daemon state is now 3 (renew) for interface eth1
Aug 31 12:17:32 localhost dhclient: bound to 128.62.102.217 -- renewal in 1650 seconds.

[Erkin Bahceci (cornelius1)]

Same thing happened with mouse getting stuck this time at 13:22. It got stuck clicked on acroread. Acroread uses 100% when you click and hold on a document.

/var/log/daemon.log:
Aug 31 13:22:00 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Aug 31 13:22:03 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Aug 31 13:22:07 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Aug 31 13:22:15 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Aug 31 13:22:27 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Aug 31 13:22:31 localhost dhclient: No DHCPOFFERS received.

So the problem could very well be related to dhclient.

[Erkin Bahceci (cornelius1)]

BTW eth0 is my wired network card. I'll try disabling that altogether (since I almost never use it) and see if the problem still persists.

[Erkin Bahceci (cornelius1)]

Didn't help, it still happens. And I see instances of the problem where nothing appears on any log in System Log at the time of the incident.

[Steve Perry (le-grimp)]

I have a USB keyboard and I was experiencing this key-repeat problem on Feisty 2.6.20-16-generic with no Xgl or Compiz. After a while I noticed that whenever I had a key repeat, my USB mouse LED blinked as well. The key repeat occurrences were correlated with a message in dmesg like the following:

[16705.323399] usb 1-2: reset low speed USB device using uhci_hcd and address 3

When I unplugged the USB mouse (the device at address 3) and then plugged it back in, the messages stopped and I no longer experience the intermittent keyboard repeats.

This may be a different problem than cornelius is experiencing but the symptoms (key repeats on Feisty) were the same.

[Benjamin (bvanheu)]

Same problem here.

- PS/2 keyboard very old keyboard (even without special « windows » keys)
- Linux 2.6.20 (Ubuntu Feisty)
- X Window System Version 7.2.0
- I am using GNOME.

dmesg:
[36358.898597] atkbd.c: Unknown key released (translated set 2, code 0x7c on isa0060/serio0).
[36358.898605] atkbd.c: Use 'setkeycodes 7c <keycode>' to make it known.
[36379.013404] atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
[36379.013412] atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.
[37631.831320] atkbd.c: Unknown key released (translated set 2, code 0x7c on isa0060/serio0).
[37631.831327] atkbd.c: Use 'setkeycodes 7c <keycode>' to make it known.

I suppose the keyboard is broken because it isn't sending the key-released signal.

Sorry for my english :)

[Mike (0x656b694d)]

The same problem here. Too annoying.

Keys stuck when they're "hot". I have never seen this bug initiated in a terminal window or any text area (only once, when i pressed space in the Google Reader to move to the next item and it started to read all items below the current, i switched with mouse to the terminal window and got spaces running there). Sometimes get cursor keys stuck.
We really miss KeyUp event.

- GNOME
- compiz-fusion
- Linux 2.6.20-16-386
- X Window System Version 7.2.0
- old good ps/2 keyboard

[Mark Schwartzkopf (kappa962)]

Same problem,it only began when I enabled the desktop effects via the System > Preferences menu. In order to get this to work, I installed Xgl as recommended in http://ubuntuforums.org/showthread.php?t=488385

However, I did not install Beryl or Fusion, so it would seem that the problem for me was either triggered by installing Xgl or by enabling the Desktop Effects in 7.04

[naxu (naxu)]

I saw this problem too. When the problem was active also processor load was above normal. I also have USB connected keyboard like someone else had. I also have usb dvb-t tuner Artec T14.

For some reason that tuner dongle was stuck and that caused extra traffic on usb bus. And that caused keys to stuck.

After removing and re-inserting Artec keyboard started to work normally.

Here is dmesg from situation:

.. lots of bulk message failed messages..
[ 1208.985627] dvb-usb: bulk message failed: -110 (1/0)
[ 1211.133604] dvb-usb: bulk message failed: -110 (1/0)
[ 1211.233218] usb 4-2: USB disconnect, address 2
[ 1211.233688] dvb-usb: Artec T14 - USB2.0 DVB-T successfully deinitialized and disconnected.
[ 1214.115975] usb 4-2: new high speed USB device using ehci_hcd and address 4
[ 1214.248214] usb 4-2: configuration #1 chosen from 1 choice
[ 1214.248353] dvb-usb: found a 'Artec T14 - USB2.0 DVB-T' in cold state, will try to load a firmware
[ 1214.319022] dvb-usb: downloading firmware from file 'dvb-usb-dibusb-6.0.0.8.fw'
[ 1214.385481] usb 4-2: USB disconnect, address 4
[ 1214.385508] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
[ 1216.136202] usb 4-2: new high speed USB device using ehci_hcd and address 5
[ 1216.277266] usb 4-2: configuration #1 chosen from 1 choice
[ 1216.277682] dvb-usb: found a 'Artec T14 - USB2.0 DVB-T' in warm state.
[ 1216.277778] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 1216.281920] DVB: registering new adapter (Artec T14 - USB2.0 DVB-T).
[ 1216.283485] DVB: registering frontend 0 (DiBcom 3000MC/P)...
[ 1216.332777] MT2060: successfully identified (IF1 = 1220)
[ 1216.793610] input: IR-receiver inside an USB DVB receiver as /class/input/input8
[ 1216.793646] dvb-usb: schedule remote query interval to 150 msecs.
[ 1216.793651] dvb-usb: Artec T14 - USB2.0 DVB-T successfully initialized and connected.

kernel:
2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux
Kubuntu gutsy, no desk top effects.

[coffeemug (coffeemug)]

I can confirm that this happens on Gutsy final, with or without compiz. I also have an ATI card (with restricted drivers turned off).

[txshtkckr (crf)]

It is rather unpleasant to have to watch in horror as the Ctrl-W you hit to close a single firefox tab blows away the 20 others you still wanted to keep open. :)

Kubuntu Gutsy Final
fglrx + Xgl + compiz + fusion
Linux crflkf 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
Nothing special reported in dmesg (just iptables drops)

At least where the keyboard is concerned, this only seems to involve things that are accelerators. That is, arrow keys get stuck, and Ctrl-W gets stuck, but an ordinary W never does.

[Mircea Deaconu (mirceade)]

Somewhat the same problem over here. But for me it seems to happen only in firefox. Page Up / Down, the arrow keys or the mouse scroll wheel gets stuck. Gutsy + fglrx + compiz fusion
Linux link 2.6.22-14-386 #1 Sun Oct 14 22:36:54 GMT 2007 i686 GNU/Linux.

[Mircea Deaconu (mirceade)]

Could this be related to xgl? Maybe the ati november driver (that will enable aixgl) will deny the need for a fix on this one.

[Mike (0x656b694d)]

Mircea,
not related to xgl (not totally sure), not related to Firefox, not related to ATI.

I run AIGLX, Opera, use nVidia card.

Get these repeats when switch applications with Alt+TAB.

[f66336pb (spamme2)]

I think it is a duplicate of 122118.

[remitaylor (remi-remitaylor)]

Same problem for me since Feisty. Upgraded from Edgy to Feisty and then had to move to a different distribution. Totally unusable. Booted a Gutsy LiveCD and the problem was still there. Booted the LiveCD again later and it appeared to be randomly gone so I installed Gutsy only to reboot back into keyboard hell. Totally unusabbbbbbbbbbbbbbbbbbbbbbbbbbble. ( <-- see what i mean? )

Does Ubuntu still have bounties? http://www.ubuntulinux.org/community/bounties/ doesn't go anywhere anymore. I ( <-- again ) would *DEFINATELY* add to a bounty for this. I've been driving me crazy since Feisty was released. I'm really, really sad to have to leave Ubuntu with this machine again ....

Fujitsy Lifebook N6010, Intelllllllllllllllllllllllllllllllllllll Pentium 4, ATI Mobility Radeon 9700
Linux haruko 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Disabling 'Repeat Keys' doesn't work for me. When I do, instead of getting thissssssssssssssssssssssssssss, I get something like this:
the quick fox jum[ system pauses ]y dog

reference: http://ubuntuforums.org/showthread.php?t=566216&page=2 ( full description & links to abunchof ubuntuforum threads with the same problem described )

[kervel (frank-dekervel)]

i'm also affected. on a thinkpad R51. most of the time it happens when i hit F12 to pop up yakuake (it keeps coming up and down and ...). happens very frequently, and i have the impression that, because of system load, the key release event gets to the X server too late so the x server thinks i'm holding the key down

[remitaylor (remi-remitaylor)]

kervel: i found another instance of this problem on a thinkpad (r40e) ... try adding this to your boot (grub) parameters ... ec_intr=0

might be a fluke, but after a few reboots ... i can still type (on gutsy, using liveCD)

i added acpi=off to my boot parameters. will post back if it stops working but ... i've tried putting the system under load and no repeats yet!

the quick brown fox jumps over the lazy dog :)

[santho (thomas-knauth)]

Boy, please somebody fix this. It's annoying. Running on a R52 Thinkpad, proprietary ATI drivers, standard Kubuntu install.

[zak317 (sobomsawin)]

Same problem here since Feisty... Upgraded to Xubuntu Gutsy recently and still have the "Sticky Keys of Death" bug...

I just watched my emails being deleted one by one till I found that my Del key was stucked.....

Some info:
Xubuntu Gutsy
Dell Inspiron 700m
Intel graphic card
IPW2200
Compiz with xgl enabled

Hope someone will find a fix soon!! Good luck!

[Mircea Deaconu (mirceade)]

Yeah! Unfortunately you're right Mike. Alt-Tab gets stuck for me too. So I guess it's a Compiz bug. Setting the package relation to Compiz. The title of the bug should also be changed. It happens in Gutsy too.

[santho (thomas-knauth)]

I am not running Compiz or any other fancy graphics stuff and have this problem. So I say it is _not_ related to Compiz.

[remitaylor (remi-remitaylor)]

Same here (happens *without* compiz). Including the LiveCD. For my hardware, it happens using Feisty or Gutsy, with or without effects (LiveCD can be used to reproduce).

I have a forum post (http://ubuntuforums.org/showthread.php?t=566216&page=2) where I've compiled a list of launchpad bugs that are likely duplicates of this, as well as forum threads, as well as some boot options I had tried and some I was going to try, but _using *acpi=off* seems to have worked for me_

I also opened a bounty for this, here - https://launchpad.net/bounties/bug-124406-keyboard-hangs-repeats - currently at $250 (not sure if there's a way people can contribute). Anyone know how active the Ubuntu bounties are and how people can contribute? Even if it's just $5, I'm sure many of you would like to get this bug noticed and fixed.

[ assuming no bug fix that works for everyone shows itself soon, there's a very good chance I'll be throwing up a website dedicated to this bug where we can compile a list of fixes and the hardware setups they work for - as well as track launchpad bugs ... this needs to be fixed in 8.04. this has caused a lot of people a lot of frustration and has kept a number of people from being able to use Ubuntu ... i'll post back here when it's ready ]

[lazyone (felix-fontein-deactivatedaccount)]

I think this one is also the same problem: https://bugs.launchpad.net/ubuntu/+bug/158436
I'm having the same problem since I upgraded to Gutsy last Sunday.

[Cruncher (ubuntu-wkresse)]

I'm the one that opened #158436, thanks lazyone. The main points and my setup are:
- many different key combinations are affected (1, 2, 3, ctrl-w, ...)
- not restricted to single application (Opera, xnview, ...)
- it *never* happened in Feisty for me, it started happening after upgrading to Gutsy
- I had Compiz installed in Feisty already (1:0.3.6-1ubuntu13), but never used it, since it does not work with nvidia-legacy drivers (did that change, btw?)
- currenty Compiz is installed (1:0.6.0+git20071008-0ubuntu1), but unused. I'll try uninstalling it and report back whether that changes anything.
- no xgl, no aiglx, no fglrx. nvidia-glx-legacy 1.0.7185+2.6.22.4-14.9
- Feisty kernel: 2.6.20-16-generic. Gutsy kernel: 2.6.22-14-386
- AMD-Desktop, no Thinkpad.

[Cruncher (ubuntu-wkresse)]

Purged compiz from the system, but it did not fix the problem. I don't use *any* fancy 3D accelerated X, just plain old nvidia-glx-legacy (GeForce2 GTS/Pro).

[Chad Johnson (chad-d-johnson)]

Confirmed for me, too. This happened when I was using Firefox, right after I had typed a long response in some forum...and now it's gone :( . VERY annoying. This happened in Fiesty and possibly Edgy as well.

* Ubuntu Gutsy
* ATI x1100 with standard proprietary fglrx drivers installed
* Acer Aspire 5050 laptop (using its keyboard)
* I was getting a "Composite extension is not available" error when enabling desktop effects, and installing xserver-xgl per this thread helped: http://ubuntuforums.org/showthread.php?t=576624

I have a desktop running an nVidia 8800GTS with the most recent nVidia drivers installed, but I don't recall this happening there. This DID happen on another (MSI) laptop I had which had an ATI x1600 mobility video card.

I appreciate the efforts with Compiz/Xgl/Beryl/Compiz-Fusion. Hope this gets fixed.

[positivek (anonyhole)]

This happens for me occasionally as well. I use the web browser a lot (Firefox). While I haven't lost "original work" due to this bug, I have lost work in web browsing. As mentioned above, I will use Ctrl-w to close a browser tab and many more that I wanted open will close. When using Ctrl-n to open a new window, I will get 20+ windows opened, bringing the system to a grinding slowdown while I frantically tap on keys (Ctrl) to register the keyup to stop the key repeat.

Machine: Compal CL56 laptop
Video: ATI Mobility Radeon 9600 (M10)
Graphics & desktop software: proprietary (restricted) drivers turned on; fglrx; xserver-xgl; compiz
Linux distro: Ubuntu 7.10 (Gutsy)
uname -a: Linux machname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
Firefox: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8

Thanks, all!

[Derek Anderson (derek-chargedmultimedia)]

I am encountering the same problem here. Very rare (happens only a couple of times per day), but it just re-occurred while deleting messages in my Inbox in evolution. Grrr.

Other users are definitely seeing this as well: http://ubuntuforums.org/showthread.php?t=599978&highlight=keyboard

I am running the stock xorg config for Gutsy (I have Xgl running on DIsplay :1.0 ) on an Asus laptop with old sk00l centrino and using a USB keyboard. Dmesg shows nothing interesting (events are from days before the last repeat event).

Kernel: /vmlinuz-2.6.22-14-386 ro quiet splash
Hardware:
enki@mobilepig:/opt/enomalism2/enomalism2/templates$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04)
01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce Go 6600] (rev a2)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
03:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
03:01.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
03:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network Connection (rev 05)

I have had instances of this bug in Evolution, Pidgin and Firefox. I have been lucky not to have it happen in scite yet (where I edit my source code).

[Paul Jaros (madmike77)]

Just adding my vote (and applying for news about it).

This is a very annoying bug, happens for me sometimes opening not one but an avalanche of tabs. I'm running Gutsy, ati + xgl.

[Daniele Besana (WP-OK) (daniele-wpok)]

Hi guys,
any update from the dev?
I'm running Gutsy, no desktop effects on it.

Thanks
--
Daniele

[no_treble (no-treble)]

Same problem on a IBM/Lenovo T60, no extra graphics packages installed, Ubuntu 7.04 w/ latest updates. Vanilla kernel from kernel.org. See attached dmesg output.

Many times, smacking the ctrl/alt/shift keys several times after they get "stuck" will release the key repeat, but sometimes I have to reboot to clear.

[Mircea Deaconu (mirceade)]

Someone suggested this (xset r rate 1000 50) on the forums as a temporary fix for the problem.

[stathissideris (sideris)]

I have experienced the same problem with Gutsy, with and without Compiz. Occurs mainly for ctrl+pageup/down (lot's of Firefox fun there) and for the combination of ctrl+alt+arrow keys (the shortcut I use for switching to a different desktop). Please, a fix would be greatly appreciated.

[Cruncher (ubuntu-wkresse)]

Could maybe somebody change the "Importance" setting of this bug, please? For example to "Critical", or at least to "High"? Maybe then it is more likely that somebody takes a closer look at this.

The bug was posted over 4 months ago, and for those who experience it, it either prevents useful working with the whole system, or is at least totally annoying.

Thank you a lot!

[Chad Johnson (chad-d-johnson)]

This still happens for me using xset r rate 1000 50.

[no_treble (no-treble)]

xset r rate 1000 50 doesn't work for me either. The shift key just got stuck again, and I had to close all applications (including a vmware machine, will a vpn connection and lots of applications open as well), then restart X to clear. No special X graphical madness installed... just straight X. This is ridiculous.

I've experienced this in some form or another for several years now. I think it's related to X in some way (https://bugs.freedesktop.org/show_bug.cgi?id=1162), but this version of Ubuntu (7.04) is much worse than usual.

Ubuntu Maintainers: If this is a known issue at Canonical, can someone paste a link to the main bug report, either for Ubuntu or upstream (if it's known)? It would be nice to get in on the "official" discussion, as this thread doesn't seem to be assigned to anyone.

Thanks.

[Chad Johnson (chad-d-johnson)]

I may actually take my last comment back. I had run the xset command as noted, but I must have rebooted since as the repeat rate is back to normal.

If this happens again with xset on, I will post back.

[Martin Garton (martingarton)]

I see this as well. Also, I think it is a duplicate of #161845. Does anyone agree?

[Per Baekgaard (baekgaard)]

Just want to add a "me too".

I see this rather annoying error very frequently on an AMD X2 XP3800 w/an Asus motherboard and NVidia graphics using the glx-new drivers.

It happens most often for me when I try to close a tab in firefox, and end up with all of them closed instead.

My system ran very stable under the previous releases, but has started to behave quite badly with the 7.10 final release, updated with all the latest patches. I'm running gnome w/ standard ubuntu compiz.

So far, I have found no workarounds ;-(

-- Per.

[Bruce Webber (brucewebber)]

I will also add a "me too". I am running Gutsy on a Dell Inspiron 8200 with NVidia graphics, running the nvidia driver (glx). It's running gnome and compiz-fusion.

The problem occurs occasionally for me, usually when pressing Ctrl-Alt-Left (or Right) to change desktops in Compiz, or in Firefox or other applications when clicking to scroll up or down. It happens often enough to be annoying. Slowing down the keyboard repeat delay and rate have not seemed to help. I cannot turn off repeat; I rely on holding down my cursor keys when editing source files.

This did not happen under Feisty. (My current install is a fresh install of Gutsy, not an upgrade.) I was running neither Compiz nor Beryl under Feisty.

MartinG: I do not think this is a duplicate of #161845. That bug includes keys not working at all.

Regards,
Bruce

[Krucova (toni00)]

I upgraded to kernel 2.6.22-gentoo-r9 (I am using Gentoo, so it's not Ubuntu specific) and the same thing happens to me, seemingly randomly.

(Ctrl+T "locks up" for a few seconds in which time dozens of empty pages opens and with my luck this problem reappears again when I close them with Ctrl+W all of the pages close in couple of seconds lag and then the browser window closes itself as by closing the last active tab in Firefox does.)

Before this upgrade, I had 2.6.21-gentoo-r4 and didn't experience this problem.

This has happened previously as well (I had newer kernel version than 2.6.21 (can't remember which version exactly) back then when this occured and this was among one of the problems why I was forced to downgrade back to 2.6.21-gentoo-r4 where I don't experience this problem)

--- Hardware
Processor: AMD Athlon 64 3200+
Motherboard: Asus A8N-SLI Premium
NVIDIA GeForce 6600GT (proprietary nvidia module loaded for X 3D acceleration)

No other modules loaded, all configs can be verified in the 2.6.22-gentoo-r9's kernel .config file I attach to this post (next post contains 2.6.21-gentoo-r4's .config)

[Krucova (toni00)]

And here is the promised .config for 2.6.21-gentoo-r4

[Cruncher (ubuntu-wkresse)]

Thanks for this info, Krucova! It seems the bug might not be Ubuntu native after all, but rather depending on an upgrade to kernel version 2.6.22 (although some report problems with 2.6.20-16-generic, with which I never experienced any problems).
I found this recent bug at the kernel bugtracker and linked to this page there: http://bugzilla.kernel.org/show_bug.cgi?id=9448

[positivek (anonyhole)]

Re my previous comment (positivek wrote on 2007-11-09):
I also experience a key repeat problem while using Google's web email (Gmail) within Firefox. Specifically, when using their "compose" view, it performs an autosave every so often. It seems that if I type during the autosave, the same key-repeat behavior occurs within the composition text box: "I get something liiiiiiiiiiiiiike this." Perhaps this is related? Note that in this case I am not pressing <Ctrl>. Also note that I am not commenting on or endorsing Gmail as a service here, but am using it to provide some info on this key repeat bug.

[Cruncher (ubuntu-wkresse)]

Good news!

For a different reason, I upgraded my kernel to the current Hoary Alpha2 version, 2.6.24-2-386. For several days now, the bug did not re-surface. Maybe the ones having the problem can do the same and see if it has been fixed already?

The upgrade into my Gutsy system worked without problem. I did the following:
1. Add this to /etc/apt/sources.list:
deb http://archive.ubuntu.com/ubuntu hardy main restricted multiverse
2. sudo aptitude update
3. sudo aptitude install linux-image-2.6.24-2-386
To get X working again with my graphics card, I also had to:
4. sudo aptitude linux-restricted-modules-2.6.24-2-386
5. sudo aptitude install nvidia-glx-legacy
, which also upgraded libc6, libc6-dev, libc6-i686
6. don't forget to re-enable your key repeat setting ;-)

Despite my worries, the rest of the system handles the upgrade of libc6 nicely and without any hiccups.

Can anyone confirm that the problem is gone after the upgrade?

[Mike (0x656b694d)]

The bug has gone after reinstalling Feisty from the CD.
Don't see it on Heron either.
So i think it comes with the upgrade to Feisty. Not with installing it.

[Bruce Webber (brucewebber)]

I have the problem after doing a fresh install of of Gutsy (not upgrade). I did not see in under Feisty. However, I'm now running Compiz, which I believe contributes to the problem by adding load to the system. I have not tried Hardy yet.

[Mircea Deaconu (mirceade)]

"I upgraded my kernel to the current Hoary Alpha2 version, 2.6.24-2-386". You mean Hardy instead of Hoary, Cruncher. Am I right?

[Cruncher (ubuntu-wkresse)]

Woops, hehe, of course. :-)
Since the kernel upgrade, the problem is definitely gone for me.

[Mircea Deaconu (mirceade)]

Still testing this on Hardy's kernel. The problem hasn't occured again so far.
So far, so good... :)

[kervel (frank-dekervel)]

i was bitten by this problem on gutsy standard with my old thinkpad R51 (especially easy to reproduce by hitting F12 and seeing yakuake going up and down and up and down and ..). now i have a new laptop (macbook pro C2D) , fresh gutsy install , and i had to install linux-2.6 git (1 week old checkout). Seems the problem is still there, most easy way to reproduce it now is hitting enter when apt-get asks me whether i want to continue installing (the "enter" goes on forever).

which leads me to believe the problem is either not kernel (but X server) related , or the problem is not ubuntu-specific.

[Theodore Book (tbook)]

Is there any chance that we will get a fix / workaround that doesn't involve installing an alpha kernel that might be incompatible with other parts of the OS? I am hesitant to try the Hardy kernel trick.

[guerilla (raspl)]

I'm also plagued by this problem. One hint that I found while googling was that one should specify that the graphics adapter is a PCI Express one (in case your graphics adapter is in fact a PCI-E one, of course) in the BIOS. Otherwise, the BIOS will check for a regular PCI graphics adapter first before it finally figures out that it is in fact in the PCI-E port. Well, I did that about 2-3 weeks ago, and the problem hasn't appeared again yet. I'm not yet convinced that this solves the problem, but it might be worthwhile if people with PCI Express (or maybe even AGP or other non-PCI graphics adapters) could check if the BIOS is set to assume the graphics adapter in the right place, eventually correct and report back if it did help.
I'm on Feisty, by the way.

[Theodore Book (tbook)]

In order to fix the mouse bug, I removed the Broadcom 43xx firmware. This fixed the both that problem and this one (although it cost me wireless) I think using ndiswrapper in place of the 43xx firmware cutter might solve the problem. Does anyone else find the same connection?

[Dana Goyette (danagoyette)]

I am also getting this even in the Hardy kernel; however, only my modifier keys ever get stuck down. Try doing anything productive with 'super' (or with 'shift', too, and firepaint!) held down..... it renders the desktop useless. I have to ctrl-alt-backspace to kill X; if I'm particularly unlucky, I'll have to alt-sysrq-k.

Note that I do run Compiz, as well as two instances of Folding@Home (see related bug here and on down the chain: https://bugs.launchpad.net/ubuntu/+bug/177713). I'll try again some time with other combinations of {folding,not folding} and {compiz,metacity}.

Since I see many comments about people losing e-mails and other sorts of data due to this bug, I believe this bug should be marked as at least high priority.

[Dana Goyette (danagoyette)]

Another note: I've now tested with folding@home stopped, and it seems to make no difference. However, switching from compiz-fusion to Metacity does prevent the problem occuring.

Just this evening (and now night), I've had to ctrl-alt-backspace the X server about 15 times times because my "Super" key got stuck almost EVERY time I used a feature bound to that key in compiz-fusion. I even switched from a git version back to the packaged version, but it changed nothing.
With Metacity, I have not once managed to make any keys get stuck.

[Michael (mathmike)]

As per Cruncher's suggestion, I installed the 2.6.24-7-386 kernel a couple days ago, and I haven't had any problems since.

[Derek (bugs-m8y)]

Am currently on Hoary. 2.6.24-8-generic.
Issue occurs for me every time I hold down a key (usually an arrow key ;) ) while clicking on mouse.
Immediately the key freezes, with repeat.
No info in dmesg, xsession-errors or Xorg log.

Unplugging keyboard and mouse does not help.
rmmod/modprobe of hid/usbhid doesn't help.
Using usbkbd/usbmouse instead of hid/usbhid doesn't help.

[Derek (bugs-m8y)]

Oh. And the issue only started after updating from Gutsy to Hoary alpha.
Any suggestions greatly appreciated.

[Derek (bugs-m8y)]

... turning off keyboard repeat does seem to work as a workaround of course.
An annoying workaround.

[Richard J. Korman (winter-blood)]

I can confirm this bug resurfacing in hardy using kernel 2.6.24-10-generic.

[Theodore Book (tbook)]

After several months, I can say that this bug has not reappeared since I disabled the Broadcom 43xx firmware. Have others noticed that connection? Should this bug be associated with that package?

[Derek (bugs-m8y)]

I have no Broadcom devices of any firmware type. The bug is highly repeatable in Hardy with my USB kbd/mouse with keyboard repeat enabled.
I just hold down the key while repeatedly clicking on the mouse.
It happens almost immediately.
Oddly, once I disabled keyboard repeat, it no longer seems to want to activate keyboard repeat. I can enable/disable it all I want, and it stays disabled. Perhaps a different bug, perhaps related to whatever is causing this bug. No clue.

[Cruncher (ubuntu-wkresse)]

How do you mean? Clicking the mouse is not influencing key repeat, so of course the key will repeat if you hold it down...
What is odd is that the gnome-terminal is not being refreshed when holding down a mouse button while a key is being pressed - key repeat kicks in, but the characters appear on the screen only after the mouse button is released.

Try "xset r on" in a terminal to enable key repeat.

[Richard J. Korman (winter-blood)]

I believe he means that is a way to cause the bug. However, following those instructions hasn't caused the bug for me, i've only had this bug happen twice since my upgrade, and i'm not sure how to reproduce it.

[fyhuang (fyhuang)]

I don't know about your experiences, but for me this only seems to be happening in GNOME, and not in XFCE (I haven't tested KDE yet). Also, the key that repeats most often for me is CTRL+T, which is most prominent in Firefox.

[positivek (anonyhole)]

I believe this bug should be upgraded in importance as it can cause loss of work. More importantly, in my mind, are possible implications of input synchrony issues.

If an application is not guaranteed the complete sequence of user-input events (e.g. key-down, key-up, etc.), then I have doubts about how honestly the (buggy) system can be used in apps that require the guarantee. Imagine medical, financial, server, mathematical, scientific, or other "critical" apps. In my opinion, only under very specific situations should user-input be processed in probabilistic ways, yet a more general indeterminacy is suggested by this bug. I also ask if security issues might arise from the (synchrony issues) of this bug.

In short, this is not simply an annoying behavior of a user interface to be worked around by adjusting key-repeat settings, but is perhaps the symptom of deeper (and hidden) problems.

[stathissideris (sideris)]

This can certainly cause loss of work, especially a tab/application shortcut gets stuck. I have experienced Ctrl+W getting stuck in the past. Also, in many cases the repeat gets stuck in a desktop-switching key shortcut which makes X completely unusable. This can go on for ever, and the only way to stop it is to SSH from another machine and kill kwin or Xorg (I use KDE and it seems that kwin goes to 100% CPU during the infinite desktop switching). This is definitely a situation where you can lose data by forcibly killing X apps.

[Fred (eldmannen+launchpad)]

I have also experienced this problem.
And I have noticed that many other people have experienced this problem, and there is quite a few bug reports about this.

Bug #194214
Bug #192331
Bug #193545
Bug #194343
Bug #194637

I really hope it gets fixed soon.

[Derek (bugs-m8y)]

Cruncher, Richard, you're right. I was describing a reproduction.
I first noticed it in Spring when playing a unit in first-person mode.
I'd be holding down the arrow key to move it, while rapidly clicking the left mouse button to fire the unit weapons.
The arrow key would then lock, until I killed off my X session or turned off keyboard repeat.

After that, I discovered by simply holding down a key (with default keyboard repeat, which is reasonably fast) while repeatedly clicking the mouse, I was able to reproduce.
I do have both a usb keyboard and mouse. Perhaps it is related. Who knows, perhaps is also related to what addresses the USB devices are on. *shrug*

Perhaps this bug is covering a few related phenomenon.

[Derek (bugs-m8y)]

BTW. Whose bright idea was it to make this a dupe of a bug filed much later?
If it was due to additional/better information, it should be filed in the bug people are all subscribed to...

[Derek (bugs-m8y)]

Heck. All of us are commenting here because we searched for a bug and found this one and commented here instead.
The duping seems to be rewarding naughty behaviour.

[Guy Gur-Ari (guygurari)]

This bug has been open for eight months, a lot of folks have complained, and nothing has been done.
What's going on? What do we have to do to get someone's attention?

Guy

[stathissideris (sideris)]

It seems that 194214 <https://bugs.launchpad.net/bugs/194214> was getting
some attention and also it seemed to have multiple duplicates pointing to
it, so I made 124406 point to it just to link all bugs together (despite the
fact that this one is older). It seems that the importance of
194214<https://bugs.launchpad.net/bugs/194214>has been moved to high,
which is a step in the right direction I suppose...

On 05/03/2008, Guy Gur-Ari <email address hidden> wrote:
>
> *** This bug is a duplicate of bug 194214 ***
> https://bugs.launchpad.net/bugs/194214
>
>
> This bug has been open for eight months, a lot of folks have complained,
> and nothing has been done.
> What's going on? What do we have to do to get someone's attention?
>
>
> Guy
>
>
> --
> Keyboard keys get stuck and repeat (Feisty, Gutsy)
> https://bugs.launchpad.net/bugs/124406
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Johan Halse (halse)]

This bug, however, is quite different from 194214. I first ran into it about a year ago when I was running Edgy - I'm now running Gutsy on a Dell Inspiron 6000 laptop, but the problem's still there - under high system load, some key combinations will repeat wildly regardless of whether I've clicked the mouse or scrolled the mouse wheel. They "unstick" after a couple of seconds but by then the damage is already done: all my tabs or applications are closed. This is a serious bug for me, I've actually lost work because of it.

It seems to happen very often in Firefox, on "heavy" pages or when I have many tabs open and stuff running in the background. The key combinations that stick most often are Ctrl+W (and that's the worst one), Ctrl+T (you suddenly wind up with upwards of 100 tabs) and the arrow keys/page up/page down keys that just keep scrolling the page. So can we please un-duplicate this bug from the other one? I don't think they're related.

[MrAnt (mrant0)]

This bug just started to occur on my Ubuntu 7.10 system. I wanted tv output on my Thinkpad T42 with Radeon 9600M so I switched from the radeon drivers and compiz-fusion to fglrx drivers with xgl and compiz-fusion and dual-head xorg.conf for tv-out and all of a sudden random keypresses are repeated. Most commonly occurs in Firefox when using the down arrow to scroll, all of a sudden I end up at the bottom of the page. I can't seem to interrupt the repeat until it finishes. The issue seems to have resolved itself after I disconnected the second screen and restarted x (so there is only one connected screen). Though I also modified my xorg.conf to support horizontal scrolling and installed gsynaptics. I'm no expert by any means, but I feel like it has to do with some xorg.conf setting. When setting up dual screens I tried to use aticonfig to get things started, but I couldn't figure it out so I modified my xorg.conf manually. maybe aticonfig is the culprit? Will attach xorg.conf if requested. Will post back if problem recurs without second screen attached.

--MrAnt--

[Richard Klinda (rklinda)]

I just wanted to add "me too". :-(

My system is unusuable for work. For simple internet (no flash games!) / email it is bearable.

[Cruncher (ubuntu-wkresse)]

This bug might actually be _not_ a duplicate of #194214 after all. However, over there they appear to have found a workaround patch, so can those of you that still experience the bug update their xserver-xorg-core and report whether this also fixes the problem described here?
I'm rather reluctant to test it myself, since a) the kernel upgrade fixed the problem for me 100% and b) I am using xserver-xorg-core 1.3.0.0, which predates version 1.4.1 that apparently introduced the bug #194214).
Please look here for deb packages containing the patch:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/194214/comments/67

Which xserver-xorg-core versions are you all using?

[Cruncher (ubuntu-wkresse)]

The above permalink does not work as I hoped, it only displays that particular comment...
So go to bug #194214 and start reading at the comment containing the word "freedesktop". You can find links to various .deb packages there.

[Johan Halse (halse)]

I'm using xserver-xorg-core 2:1.3.0.0-dfsg-12ubuntu8.3. I looked at the page for 194214 and tried to install the i386 deb but I'm told "xserver-xorg-core conflicts with xserver-xorg-input", it won't install, and I don't know enough of what I'm doing to force an install. Is there an easy way to patch your xserver-xorg-core without having to compile your own deb?

[CarlosBrolo (carlos-brolotobar)]

SOLVED:

My keyboard is PS2, but the problem on DMESG said:
usb 2-3: reset low speed USB device using ohci_hcd and address 2
x100 times.... so was not a problem of my keyboard..... something on the USB needed to be reseted...

INSTRUCTIONS:
1.-Unplug all your USB devices
2.- Wait 10 seconds
3.-Plug them again

The problem of the keys being stuck should be gone... if persist, try to follow the steps 1 to 2....
then use the keyboard without plugin back the usb devices.... if it works, you have a bad mouse / or usb device.... if not..... is something else....

[Cruncher (ubuntu-wkresse)]

Good if this is a workaround working for you. However, it is not a general solution, since I don't have any active USB devices that I could unplug...
My keyboard is PS/2, too. And my machine doesn't have a USB 2.0 controller, only 1.1 (=slow USB)

[Johan Halse (halse)]

The culprit in my case was XGL! I'm now running the latest ATi drivers without XGL enabled as per these instructions: http://forlong.blogage.de/article/2007/10/23/fglrx-8423---finally-with-AIGLX-support and I haven't encountered the problem since. Hopefully this will work for other people as well.

[MrAnt (mrant0)]

I can confirm that xgl has something to do with the problem. My problem started when I started using proprietary ATI drivers, fglrx, with xgl for 3d desktop effects. Previously I had been using xorg radeon drivers without xgl with no problems. I recently went back to xorg radeon drivers and uninstalled xgl and havent experienced the problem since.

Hope this helps

--MrAnt--

[Cruncher (ubuntu-wkresse)]

Again, the problem is more complicated. *If* xgl is part of the problem, it is not the sole reason and/or cause.
I have no xgl, no aiglx, no fglrx, no compiz, no beryl, and nvidia-glx-legacy drivers. I still had the bug (until the kernel update).

[Cruncher (ubuntu-wkresse)]

Oh and:

Sorry for double posting, but can please somebody REMOVE the duplicate tag from this thread? To my knowledge it was quite well established by now that this is a different bug - for one, bug #194214 describes something where a key is permanently stuck and will most of the time only recover after an X reset. Here, the stuck key will get unstuck after a few seconds.

For all of you who actually use an xserver-xorg-core version of at least >=1.4 (I don't), PLEASE install and try the workaround/patch/deb-package posted in #194214 to make 100% sure that it is a different bug and that the patch will not help - or to check the off-chance that the patch works for this problem here as well. Thank you very much.

[zadig (zadig-jaja)]

This is not a duplicate of bug #194214 as Cruncher says.
In my case, i dont have to kill the xserver to get the keys
unstuck, after 30-50 repeats everything goes back to normal.
It only happens with key combinations, that is I dont see
wwwwwwwwwwwwww but alt-tab, alt-f4, ctrl-n repeats.

It's also noted by Chris Halse Rogers in the bug of #194214
this is NOT a duplicate of that bug.

[Tom Jaeger (thjaeger)]

How reliably can you reproduce the issue?

[Cruncher (ubuntu-wkresse)]

From his descriptions, the bug Derek is describing is bug #194214, too, not this one.

[Cruncher (ubuntu-wkresse)]

Tom Jaeger wrote:
> How reliably can you reproduce the issue?

Well, we can't... :-/
The problem appears sporadically. System load seems to help in making the bug occur, but to my knowledge there is no reliable way to consistently reproduce the bug.

NOTE TO ALL:
Please check whether you have this bug described here (repeating stops by itself), or whether it is bug #194214 you are experiencing instead (*endless* key repeats that "transfer" to other open applications and can only be stopped by X server reset, can probably be reproduced by holding down a key and lots of mouse activity).
If you have bug #194214 (such as Derek and Dana Goyette), please look there for a patch that fixes the issue.
If you have this bug instead, please try to upgrade your kernel to 2.6.24-2-386 or later ( https://bugs.launchpad.net/ubuntu/+bug/124406/comments/58 ), which seemed to have fixed the problem for some.

If you are certain you have *this* bug, please report back after the kernel upgrade, and tell us whether it worked or not.

[zadig (zadig-jaja)]

upgraded to hardy, 2.6.24.15-generic (see crunchers previous
post for a little how to i needed the xorg-fglrx driver) and did
not encounter the problem yet. The sleep problem is also solved!

I was not able reproduce this problem, it was happening randomly.
I dont think it's related with the cpu load either.

[Tom Jaeger (thjaeger)]

This is what I still had lying around from investigating the other bug. It collects key events from the kernel's fd in a separate thread to work around possible latency issues. I suspect the problem lies elsewhere, but I might be worth a try. I'd also be interested in an Xorg.0.log if you encounter the problem with this package installed.

[Ivan Mirić (imiric)]

I've been having this problem ever since Feisty, IIRC. It is most prone to happening in Firefox, which led me to believe for some time that a FF extension was the culprit. Among the ridiculous amount of extensions I use (30+), I use SwiftTabs and Locationbar². The first one ties my '1' and '2' keys to navigating between tabs, much like in Opera. The second one enhances my location bar to hide the protocol part, separate the directories in a cleaner way and allow me to navigate to any directory in the URL by simply clicking on them.

The reason I mention this is because 90% of the time (about 4-5 times a day), the keyboard gets stuck on either the '1' or '2' key, which makes FF scroll trough the opened tabs uncontrollably, making my CPU jump to 100% and the system completely unusable for 10-15 seconds (sometimes more or less, I haven't found out what determines the length). I can see the title bar change during that time, but can't control what is happening. Sometimes if I mash on the ESC key I think I manage to make it stop after a few seconds, but it might not be me doing this after all. After the title bar is done scrolling through the opened tabs, FF renders the page it decided to leave me on, but I still can't use anything, because the location bar now has to go through the same thing. This part is usually faster, but because I have Locationbar² it still takes almost the same amount of time as before.

The remaining 10% of the occurrence of this error is in cases the Ctrl+W combination gets stuck and I end up closing too many tabs than I'd like (sometimes it doesn't stop until all tabs are closed). And it also happens with Ctrl+T, where I end up with 20-30 new tabs, and have to close them manually afterwards.

Aside from FF, this has happened in OpenOffice and other apps, albeit not very often.

FWIW, I use btnx to add functionality to my mouse, and XBindKeys for a few custom shortcuts. I use Compiz, but this error seems to happen even more while I have it turned off and am using Metacity, so I doubt this is a Compiz/GLX issue.

This is a really frustrating bug. Hijacking my system like this is absolutely ludicrous. Among all the different errors my 6-month installation of Ubuntu has (having to run swapon manually, no text in virtual consoles, an audio issue that prevents me from playing audio two times in a row in the same application (watching YouTube freezes Firefox), the OpenOffice/Qt4 font aliasing bug, this repeating key problem, and a couple more) I was really ready to throw in the towel and do the Windows-maintenance-procedure (format, re-install). But since Hardy is just around the corner (and I don't plan on mucking around with pre-releases), I'm counting the days towards the moment I can have a fresh Ubuntu installation. It's painfully ironic that this paradigm of keeping a system in a healthy running operation exists on Ubuntu as well. I hope this gets ironed out in 8.04.

[Tom Jaeger (thjaeger)]

I can reproduce this now by typing 'sudo apt-get upgrade' and holding down Enter for about half a second. For me it's happening only with hardy (specifically 2.6.24-12-generic), not with gutsy.

What happens is that the kernel's 'key up' event (and also possible kernel or hardware generated autorepeat 'down' events) are delayed for about 1-2 seconds. Since this is even happening with a multi-threaded xserver-xorg-input-kbd, this can hardly be the x server's fault.
Please reassign this to linux-source and add a http://bugzilla.kernel.org/show_bug.cgi?id=9448 tracker.

[Tom Jaeger (thjaeger)]

The issue is present in the vanilla 2.6.24 kernel, and it's fixed in current git. Bisecting now...

[Tom Jaeger (thjaeger)]

My money is on this commit, but let's first see how the bisect turns out.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1868f958eb56fc41c5985c8732e564a400c5fdf5

[Tom Jaeger (thjaeger)]

Nope, it appears to be this one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=810b38179e9e4d4f57b4b733767bb08f8291a965

Trying to backport this to 2.6.24 vanilla now.

For completeness' sake, here's the log (note that good and bad are reversed).

git-bisect start
# bad: [6fdf5e67fe8d3c83500dad9acae985132c2459a3] Merge branch 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/ralf/upstream-linus
git-bisect bad 6fdf5e67fe8d3c83500dad9acae985132c2459a3
# good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24
git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8
# good: [fa4d3c6210380c55cf7f295d28fd981fbcbb828c] [NETNS]: Udp sockets per-net lookup.
git-bisect good fa4d3c6210380c55cf7f295d28fd981fbcbb828c
# good: [0cf975e16927fd70f34cee20d3856246c13bb4c8] Merge branch 'cris' of git://www.jni.nu/cris
git-bisect good 0cf975e16927fd70f34cee20d3856246c13bb4c8
# good: [b73384f06159d8388d7d17913b7e3a07e234c1ab] Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm
git-bisect good b73384f06159d8388d7d17913b7e3a07e234c1ab
# bad: [aa2ac25229cd4d0280f6174c42712744ad61b140] sched: fix overload performance: buddy wakeups
git-bisect bad aa2ac25229cd4d0280f6174c42712744ad61b140
# good: [a0863130757f32df602c1c60326530c0152b626b] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
git-bisect good a0863130757f32df602c1c60326530c0152b626b
# bad: [299601cfc0aabbabf82fca50652b7290cce7eb00] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
git-bisect bad 299601cfc0aabbabf82fca50652b7290cce7eb00
# bad: [fdcc53587fd2754ba87b0607b3f889520178a7af] BF54x LQ043 Framebuffer driver: fix bug NULL for gpio_request label is not allowed
git-bisect bad fdcc53587fd2754ba87b0607b3f889520178a7af
# bad: [bb641ab496d5b8eb835ae1933926fdf23feb5260] Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
git-bisect bad bb641ab496d5b8eb835ae1933926fdf23feb5260
# good: [d032b31a3a22a571cb50c0b5dffbe9ba9328d6e2] x86: fix typo in step.c
git-bisect good d032b31a3a22a571cb50c0b5dffbe9ba9328d6e2
# bad: [1d6789c3bc2b70bed1eb71aa616b1d94f9c23a63] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel
git-bisect bad 1d6789c3bc2b70bed1eb71aa616b1d94f9c23a63
# bad: [2692a2406b9262bbb101708815be99ec2988e48b] sched: rt-group: fixup schedulability constraints calculation
git-bisect bad 2692a2406b9262bbb101708815be99ec2988e48b
# bad: [6fa46fa526f2cab9ce21fa5e39501553a40d196d] sched: balance RT task resched only on runqueue
git-bisect bad 6fa46fa526f2cab9ce21fa5e39501553a40d196d
# bad: [810b38179e9e4d4f57b4b733767bb08f8291a965] sched: retain vruntime
git-bisect bad 810b38179e9e4d4f57b4b733767bb08f8291a965

[Tom Jaeger (thjaeger)]

Confirming that the attached patch solves the issue on a stock 2.6.24.4 kernel.

[Tom Jaeger (thjaeger)]

Expect some modules not to load in this version of the kernel since this also needs an updated linux-ubuntu-modules package, which I will have to wait until tomorrow. But it should be good enough for preliminary testing.

[Tom Jaeger (thjaeger)]

Headers, in case you want to build linux-ubuntu-modules yourself.

[dhaval (dhaval-giani)]

Are you sure that that patch fixes it? That is a patch which is specifically for the group scheduling extensions to CFS which has been in only since 2.6.24 timeframe. 2.6.22 did not even have the CFS. I believe the problem has been caused by something else.

[Tom Jaeger (thjaeger)]

The patch fixes _a_ bug that fits the exact description of this bug. Whether or not it's the same bug (the original bug is probably a scheduling issue as well), this one needs fixing too.

[dhaval (dhaval-giani)]

On Mon, Apr 7, 2008 at 7:51 PM, Tom Jaeger <email address hidden> wrote:
> The patch fixes _a_ bug that fits the exact description of this bug.
> Whether or not it's the same bug (the original bug is probably a
> scheduling issue as well), this one needs fixing too.
>

Right, it fixes a bug. It obviously is not the same bug as the bug
being discussed here has been on since 2.6.22 when CFS was getting
developed. I agree this one needs fixing as well, will ask for more
information soon.

Thanks,
Dhaval

[Tom Jaeger (thjaeger)]

The LKML-Thread leading to the patch in question:

http://lkml.org/lkml/2008/2/27/399

[dhaval (dhaval-giani)]

On Mon, Apr 7, 2008 at 9:05 PM, Tom Jaeger <email address hidden> wrote:
> The LKML-Thread leading to the patch in question:
>
> http://lkml.org/lkml/2008/2/27/399
>

Right. This is not of 2.6.22 timeframe. This bug has been since then.
That fixes another bug, not this one.

Thanks
Dhaval

[wilderjds (jacopods+launchpad)]

The bug is still there even after patching the kernel.
in my case I noticed that the bug shows up more frequently when the clock of the cpu changes (cpufreq) around the same time as a keydown or keyup event. Somehow X misses one of them. Moreover, sometimes pressing a key does not give any output, meaning that this time X is not receiving the keydown event.
This would give an explanation at why the problem is related to CPU-intensive processes such as compiz, firefox et cetera.
Can you confirm this? Does anybody else miss keydown events? I am now going to check if fixing the frequency helps.

JdS

[Helge Willum Thingvad (helgesdk)]

Exactly as Tom Jaeger describes it, when I run "sudo aptitude search geany" for example, the Enter key repeats about 50 times (counting the number of newlines) before the system registers that it has been released.

I put an alias my ~/.bashrc
alias aptitude='sleep 0.2 && sudo aptitude --without-recommends'

[Helge Willum Thingvad (helgesdk)]

There's not too much time until release, and this bug is still present.
I am now running on a completely different system (my main laptop got a faulty LCD monitor), and behavior is exactly the same.

Main system (broken):
Ubuntu Server with xserver-xorg and OpenBox
IBM Thinkpad Z60m, Intel Pentium M 2.0Ghz, 2GB RAM
ATI Mobility Radeon X600 running binary fglrx driver

Backup system (current):
Same Ubuntu setup with xserver-xorg and OpenBox.
AOpen 1557-G, Intel Pentium M 1.8Ghz, 1GB RAM
ATI Mobility Radeon 9700 running OpenSource radeon driver

I'd gladly help with debugging, just give me the instructions.
Although I'm not an experienced programmer, I'm quite confident with terminals and scripting.

[Helge Willum Thingvad (helgesdk)]

Sorry, I forgot to mention I'm talking about Ubuntu Hardy Heron in both examples, running latest generic kernel (2.6.24-16-generic).

[Harvey Muller (hlmuller)]

Cruncher and wilderjds,

Cruncher:

The bug (#213669) I experience is not as described here, the repeating does not stop by itself. It is also not similar to #194214, in that I cannot reproduce those problems. When I experience the bug, simply hitting any other key after the repeats begins, stops the repeats.

I am running 2.6.24-16-generic and still experience the repeat bug. I do not believe my specific bug is this one, but Timo Aaltonen has deemed it a duplicate.

wilderjds:

I only get stuck repeat keys when using the Caps Lock key, holding it down then pressing another key. The second key pressed will stick frequently but not all the time.

The bug isn't triggered by cpufreq changes in my case. It happily causes repeats when both processors are stable at the low freq. And

I am able to reproduce the stuck repeats in a minimal X environment (i.e. no compiz, window manager, etc.)

[wilderjds (jacopods+launchpad)]

Harvey:

 I confirm: keys get stuck also with fixed freq. Now I unhappily disabled key repetition on X and at least I can type without having everything deleted by a backspace got stuck.
Still some keydowns are lost as well, do you notice that as well?

J

[Mark Schreiber (mark7)]

Not certain whether this is the same problem. It sounds awfully similar, except for the fact that I haven't seen my behavior "clear up" in a few seconds, as some have mentioned. With Gutsy on an Inspiron 1420 laptop, I sporadically see keys "stick" when using the built-in keyboard (I haven't tried external keyboards). Hitting another key clears up the situation immediately (which makes sense -- the internal keyboard is USB, and USB interface keyboards send the whole keyboard state on any keypress). Happens most frequently with "s" at at the end of a line in emacs, presumably since I pause in typing and allow enough time for the key repeat to kick in. I have not tried working on the Linux console to see whether it is affected as well -- it does happen in xorg. I type heavily, since I'm coding much of the day, and get this probably at least five or six times a day.

One interesting bit of information that I can add is that I ran "sudo od -x /dev/input/event1" (to dump out all events coming in from the keyboard -- your keyboard device may be different). I left this running, and managed to capture a log of a stuck "s" key occurring happening. Normally, when holding a key down, I get many of the following events generated:

0432620 6bd6 4806 a3c4 000e 0004 0004 001f 0000
0432640 6bd6 4806 a3cc 000e 0001 001f 0002 0000
0432660 6bd6 4806 a3cf 000e 0000 0000 0000 0000

Where "001f 0002" seems to indicate that the key is being held down -- these events are generated in rapid succession when the key is down. When the key is released, I get "001f 0000", and when initially pressed, I get "001f 0001". In this case, even though the "s" key was stuck down and repeating, I had *no* "001f 0002" events in the output from the event device -- just a "001f 0001" and "001f 0000" event.

I haven't yet determined whether the "001f 0000" event came in only after a subsequent keystroke or whether it was immediately generated. I'll try to catch this and provide a follow-up.

No unusual dmesg output. They internal keyboard in question has (from "sudo lsusb -v" output) an idVendor of 0x0a5c (Broadcom Corp.) and an idProduct of 0x4502.

[Mark Schreiber (mark7)]

Managed to reproduce without tapping any keys. Switched using mouse to xterm, and snatched this snippit from the terminal. Indeed, no keyup event is showing up until after I hit the next key sequence (a ^C) to terminate the stream of "s"es :

3742240 affb 4806 0b19 0003 0004 0004 001f 0000
3742260 affb 4806 0b22 0003 0001 001f 0001 0000
3742300 affb 4806 0b25 0003 0000 0000 0000 0000
3742320 affb 4806 08d6 0004 0004 0004 002d 0000
3742340 affb 4806 08de 0004 0001 002d 0000 0000
3742360 affb 4806 08e1 0004 0000 0000 0000 0000
3742400 affb 4806 d98c 0004 0004 0004 003a 0000
3742420 affb 4806 d997 0004 0001 003a 0000 0000
3742440 affb 4806 d99c 0004 0000 0000 0000 0000
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss3742460 b015 4806 8412 000d 0004 0004 003a 0000
3742500 b015 4806 841f 000d 0001 003a 0001 0000
3742520 b015 4806 8424 000d 0000 0000 0000 0000
3742540 b015 4806 8ae1 000d 0004 0004 001f 0000
3742560 b015 4806 8aed 000d 0001 001f 0000 0000
3742600 b015 4806 8af2 000d 0000 0000 0000 0000
3742620 b016 4806 8f14 0000 0004 0004 002e 0000
3742640 b016 4806 8f1f 0000 0001 002e 0001 0000
3742660 b016 4806 8f25 0000 0000 0000 0000 0000

Since I believe the kernel is responsible for generating /dev/input/event* output, I would say that this is a kernel and not an xorg bug. Since there are no key repeat events being generated here the kernel must be getting enough information from the hardware to know that the key is not down, but is still not passing on the key up event.

Produced on Gutsy, linux-image-2.6.22-14-generic, Ubuntu package version 2.6.22-14.52. Just for good measure, xserver-xorg was 1:7.2-5ubuntu13.

[Mark Schreiber (mark7)]

Just to make things a bit more clear, the log immediately before the key events included in my previous log message was:

3742100 affb 4806 454d 0000 0004 0004 003a 0000
3742120 affb 4806 4557 0000 0001 003a 0001 0000
3742140 affb 4806 455a 0000 0000 0000 0000 0000
3742160 affb 4806 8e76 0001 0004 0004 002d 0000
3742200 affb 4806 8e80 0001 0001 002d 0001 0000
3742220 affb 4806 8e83 0001 0000 0000 0000 0000

(i.e. I was saving a file in emacs with C-x C-s). I tend to hit the keystroke fairly quickly. Some other users have suggested that their laptop coming under load tends to aggravate this -- the file saving event would have occurred as soon as I hit the "C-s", so there would have been a small burst of work, though the system was largely unloaded. This might explain why I've never seen streams of "a"s or "e"s when hitting C-a or C-e to go to the beginning or end of a line.

laptop_mode was disabled on the laptop, and frequency scaling active, since I've seen some mention of maybe frequency scaling being relevant.

[Cruncher (ubuntu-wkresse)]

On Wed, 16 Apr 2008 22:00:15 +0200, wilderjds <email address hidden> wrote:
> Still some keydowns are lost as well, do you notice that as well?

Hm, I think I can confirm that. I seem to loose the occasional keypress. However, until now I attributed this to my clumsy typing ;-)
It may well be part of the bug, though.
(For the record, note that I am using Gutsy with Hardy Kernel 2.6.24-2-386 with key repeat enabled and I do NOT experience the key repeat problem since the kernel upgrade)

[Mark Schreiber (mark7)]

How to reproduce reliably:

I can get about a 25% reproduction rate when hitting C-x C-s in emacs. However, the key sequence must be very rapid -- I basically have my fingers in the right position and just roll my hand over the keys. It seems to depend on the Control key being released very shortly after the "s" key is released -- if I wait a bit before releasing Control, the problem does not show up

One other note -- problem definitely still shows up with frequency scaling disabled.

[Tom Jaeger (thjaeger)]

I've opened Bug #218516 to track the scheduler issue in 2.6.24 for which we have an upstream fix.

[Harvey Muller (hlmuller)]

Mark,

I am curious, because we both have the same hardware, and initially experienced the bug in the same application, emacs. Have you mapped the Ctrl key to the Caps Lock key? I have observed that the Caps Lock key is part of the trigger of the repeats. Without remapping, the normal Ctrl key does not contribute to repeats. The Caps Lock key however will.

Additionally, I am unable to reproduce repeats in Recovery Mode (without X) using a console. Can you reproduce the problem in a console without X?

Thanks,

Harvey

[Mark Schreiber (mark7)]

>Have you mapped the Ctrl key to the Caps Lock key?

Good catch.

Yes, I'm using swapcaps in xorg.

I used dumpkeys, swapped keycode 29 and 58, and ran the result through loadkeys.

When I ran emacs in a console, I did not get duplicated keypresses but I did get the missing key up event (based on the od -x output from the event1 device) -- the same thing I see when emacs is running in X. It looks like the "non-duplication" is because xorg is responsible for generating repeats in X and the kernel is responsible for generating repeats in the terminal. So the events from event1 are still wrong and the key is never being "released" -- it just isn't user-visible in the form of a repeating keypress. From a user standpoint, of course, this may not matter, since the key doesn't appear to be down to the user.

Interestingly enough, as you've noticed, I could not reproduce the problem when using the standard Control/Caps Lock mappings in the console -- only when the two are swapped. This may be because I simply can't release the lower-left control key quickly enough, but I did spend a while trying to get it to happen without luck.

Unless someone can produce this with the standard Control/Caps Lock mappings, I think that, as a user-visible bug, this can be narrowed to people who are using swapped caps in xorg.

[arbeck (andrewrbeck)]

I seem to be having this problem and I can reproduce it in any application in ubuntu if I type long enough. Something that I've noticed tonight, since I'm in a dark room is that my mouse comes alive at any time the bug occurs. I have an LED optical mouse. When not in use, the mouse is dark, but when you move it, it lights up. When ever the bug occurs, the mouse lights up like it was just moved.

[Harvey Muller (hlmuller)]

I am attaching a capture of the events for both "good" key press / releases and "bad" ones.

There is no discernable difference between the events between "good" and "bad" except in timing. There are no missing or extra events recorded when comparing the "bad" to the "good".

The capture was obtained by running the following and pressing [Caps Lock][X][Caps Lock][S]:

    $ sudo xev | tee repeat.key

I have to record more repeats to confirm that timing may be a triggering factor.

[Harvey Muller (hlmuller)]

Mark's comments got me thinking laterally. Perhaps there's an issue between X's software key repeat and the kernels. I turned the kernel repeat off by appending:

    atkbd.softrepeat=1

to the kernel boot parameters in grub.

It seems to help, as I have not had a repeat yet, but I'll keep testing and report the results back here later.

[Harvey Muller (hlmuller)]

atkbd.softrepeat=1 is not the solution. It reduces the occurrences of the repeats perceptibly, but does not prevent them.

[arbeck (andrewrbeck)]

I also added the atkbd.softrepeat=1 to my boot parameters and would say that it reduces the occurrences by about 90%. I still occasionally shows up though.

[Harvey Muller (hlmuller)]

I can reliably reproduce the key repeat problem 100% of the time. So it would seem the issue is not isolated to the Caps Lock key.

When depressing the blue [Fn] key and then [F10] to eject the cdrom drawer, it creates a repeat. The repeat can be stopped by hitting any key. But the drawer will continue to eject by the number of times the repeat occurred before it is halted by hitting another key. After the eject cycles have been exhausted, the [Fn][F10] key will no longer eject the cdrom drawer during the current session.

This is on an Inspiron 1420. Mark, are you able to reproduce this?

[Mark Schreiber (mark7)]

Unfortunately, I don't use GNOME, and don't have any software packages running that listen for a fn-F10, so I can't check ATM whether X believes that the key is down.

Assuming that my guessing as to the meaning of the hex dump from /dev/input/eventX is correct (2 is generated auto-repeat, 1 is down, 0 is up), that key generates events that are a little unusual too -- there's no key down or key up events generated -- just key repeat, one per key press. But I could also be misunderstanding them -- I should really dig up something that can understand the input from /dev/input/event devices to be sure. Also on an Inspiron 1420. This is not the case for fn-print screen, which generates the normal 1 and 0 events, with repeat events if held down.

Doesn't have the same kernel-level behavior that causes the other repeat problem, though it might be a bug in-and-of-itself if this is inadvertent.

[pauls (paulatgm)]

also a problem here with hardy, but not gutsy.

[pauls (paulatgm)]

I also have tried booting with this line:

kernel /vmlinuz-2.6.24-16-generic root=/dev/mapper/vgsda9-lvsda9root ro atkbd.softrepeat=1 quiet splash

and it makes no differencee. I have to say this may turn out to be a show stopper bug for me, since I'm afraid to do any on-line banking or business where a slip of the key might mean a major problem.

Also, it's a security risk when aptitude full-upgrade skips the Y/N prompt due to repeat carriage returns.

How can wee get some priority on this?

[Danny Wood (danwood76)]

Has anyone tried creating a custom kernel with a faster interrupt timer?

The 1000 Hz option is perfect for desktop users and will mean the kernel probes for hardware updates more, which may mean your keyboard will register key releases better. (The default is 250Hz)
Obviously you only want to try this if you have compiled a kernel before :)

Its a hard problem to debug as I have never experienced anything like this.

[Mark Schreiber (mark7)]

>Has anyone tried creating a custom kernel with a faster interrupt timer?

Even if that reduced the frequency of the problem, the underlying kernel bug would still be present. The kernel must have enough state to know that the key is up (else it would generate repeat events), but is not passing the key-up event along through the /dev/input/event* devices.

There are a number of different issues here.

I saw this problem in both gutsy and hardy -- rare incidents of control+key resulting in the key being stuck down until the next keypress. pauls saw it only in hardy. Harvey gets the same behavior on identical hardware as me (inspiron 1420). Harvey also mentioned what I would guess would be an unrelated type of behavior (behavior of fn+f10, which is not timing-dependent and reproducible 100% of the time). Finally, there are the "locked keys until X server reboot" and the "scheduler bug that clears up after a few seconds" people.

(Harvey, can you please log od -x output from /dev/input/event(the event device for the keyboard), as I did, and try to repro the problem? Your "repeat.key" log shows xev output, which I would expect to not be able to differentiate between things -- the input system is what feeds xorg, and the problem is already present at that point.)

I should really split what Harvey and I are seeing off into a new bug, just to reduce the number of similar issues being thrown into this one...

[Harvey Muller (hlmuller)]

Mark,

On splitting off, the most recent duplicate bug is one that I created. I think it's Timo's intent to lump our issues in with the rest.

I've attached od.log as you requested. I did not generate it earlier, because I cannot read the output. I was able to generate the bug and attempted to insert markers into the log to help you see where the repeat bug 'should' be starting and ending. There are no markers, because I forgot to add 'sudo' to the echo commands.

Oddly enough, I was unable to trigger the [Fn][F10] repeat bug, which was previously 100% reproducible. So that statement is now incorrect.

Harvey

[Pete Setchell (pete-asparagine)]

I can replicate this by holding the mouse over a maximised VMWare window (on one of two monitors), holding down control and then moving the cursor back out of the VMWare window. After releasing the control key outside the VMWare window I find that the shift and control keys no longer work at all until I either run setxkbmap or restart my X session somehow.

I've attached output of od -x /dev/input/event1 taken while this was happening. The trace is pretty opaque to me, but there's several lines of futzing around after it happens, as I had to type setxkbmap before I could terminate the od -x logging with Ctl-C.

Needless to say, this is a killer when copying/pasting out of the VMWare window, as one slovenly Ctl-c screws the system up. I used to get this happening very occasionally under Gutsy, but it seems to happen more often following my upgrade to Hardy.

[Oli (oli)]

Pete, you're a complete legend! That "setxkbmap" is exactly what I need to allow me to get on with things without having to fear the ungodly wrath of VMWare and its constant need to steal my modifier keys!

You've actually improved my quality of life by typing that comment. Thank you!

[gabr10 (gabriobarbieri)]

Same problem here, but when I type the setxkbmap it gives me an error: 'Error loading new keyboard description'
I'm not sure if it does work though, but vmware IS giving me that problem and on a very nasty way

[Mark Schreiber (mark7)]

Harvey,

>I've attached od.log as you requested. I did not generate it earlier, because I cannot read the output.

[chuckle] Well, neither can I other than that bit that I've decoded. Okay, I'm not sure exactly where you ran into the stuck key problem, but assuming that it was your 's' key (am I right?), this confirms that it's the same problem as mine. There are key down and key up events for the 's' key, but no repeat events -- "001f 0000" and "001f 0001" but no "001f 0002". Thanks.

[Forest (foresto)]

I have the stuck keys problem as well. Every time it happens, I get a syslog message like this:

  usb 2-1: reset low speed USB device using uhci_hcd and address 3

The usb device in question is my Logitech MouseMan Wheel, model number B-BD53. I have never seen this happen when I plug it in using its usb to ps2 adapter, only when I plug directly into one of my computer's usb ports.

I first noticed the problem while typing in a terminal window and running a virtual machine in the background. However, it definitely happens even while my computer is idle. (The log entries below were written during idle time.)

"carlosbrolotobar" on ubuntuforums.org has the same problem, also correlated with usb device reset messages:
http://ubuntuforums.org/showpost.php?p=4610774&postcount=22

Some general hardware info:
ps/2 keyboard
intel penryn core 2 duo cpu
Intel P35/ICH9 chipset

Some software info:
Ubuntu 8.04 (Hardy Heron)
Linux heron 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
X.Org X Server 1.4.0.90
nVidia proprietary driver 169.12
xfce 4.4.2

A longer syslog excerpt, starting when I plugged in my mouse:
May 15 20:49:08 heron kernel: [ 2628.533383] usb 2-1: new low speed USB device using uhci_hcd and address 3
May 15 20:49:08 heron kernel: [ 2628.706961] usb 2-1: configuration #1 chosen from 1 choice
May 15 20:49:08 heron kernel: [ 2628.725028] input: Logitech USB Mouse as /devices/pci0000:00/0000:00:1a.1/usb2/2-1/2-1:1.0/input/input7
May 15 20:49:08 heron kernel: [ 2628.785569] input,hidraw0: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:1a.1-1
May 15 20:55:56 heron kernel: [ 3036.521260] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 20:56:31 heron kernel: [ 3070.725849] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 20:57:25 heron kernel: [ 3124.876792] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 20:57:45 heron kernel: [ 3145.234291] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:01:03 heron kernel: [ 3342.411627] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:01:48 heron kernel: [ 3387.133258] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:02:08 heron kernel: [ 3407.103576] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:03:39 heron kernel: [ 3498.057674] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:06:10 heron kernel: [ 3648.539500] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:06:18 heron kernel: [ 3657.025783] usb 2-1: reset low speed USB device using uhci_hcd and address 3
May 15 21:07:11 heron kernel: [ 3709.851493] usb 2-1: reset low speed USB device using uhci_hcd and address 3

[Forest (foresto)]

This seems related to bug 91230.

[Oren Held (oren-held)]

I don't know if it helps, but I can reproduce this bug on *Debian* as Pete previously described here. (the vmware trick)
I'm using an up-to-date Debian sid(unstable), KDE 3.5, kernel 2.6.24, VMWare server 1.0.5.

As a workaround, I re-load a new modmap using "xmodmap /usr/share/xmodmap/xmodmap.us-101" each time it happens.

I do NOT get the USB error messages in syslog as stated above, though.

[darksnow (darksnow1)]

I have the same problem, however mine continues until I press the off switch on my laptop. This is not an Ubuntu specific bug. I am using Fedora Core 9 within Gnome on a Lenovo (IBM) 3000 N100. I have read a trend of Thinkpads that are having this problem and maybe that is related. I recently started experiencing the problem after upgrading from Fedora Core 8 to Core 9. I did not have the problem under Core 8 *at all*. Recently I messed with the keyboard repeat settings, and the problem "seems" to have gone away, but I keep saying that until the next time it happens. It his hard to call the system "stable" when I can't depend on the keyboard not to go wild. Perhaps the commonality between Ubuntu and Fedora 9, and the diff between Fedora 8 and Fedora 9 might help locate what causes this problem.

[sawk (sawk-ita)]

I have Archlinux with 2.6.24.4-1 and I can reproduce this bug ALL THE TIME...
xorg-server 1.4.0.90-9 without Compiz and KDE 3.5.9.

General info:
Toshiba Satellite A110
Intel T5500
2GB RAM
NVIDIA - Driver 169.12

[Chris (bridgeriver)]

I just fixed a "stick and auto-repeating" keys problem on my Dell Core2 Duo laptop by adding some boot parameters that disable some kernel features:

highres=off nohz=off noapm

I had originally added these same parameters on two other laptops (Acer Aspire and HP Pavillion, both built around AMD64 CPUs with ATI shared-memory video) to cure their random hard freezes.

It seems likely that either the high-res timer or the tickless feature in the latest kernels is very bad medicine, on certain hardware at least.

[Arne Fahrenwalde (macgeneral)]

Ok first of all:
I used Debian testing (Lenny) and experienced the bug with the stuck keys and the bug with the Synaptics Touchpad being jumpy and unusable.

In the end I became so mad at Debian (while reading bug reports everywhere and no solution helped) that I decided to wipe it off my hard disk and give the new Fedora 9 a try.

Fedora 9 worked (except that its "totally different") fine - until today after I installed some packages:
when I set up my Gnome to be like it used to be in Debian, I installed the

> gnome-applet-sensors <

today in college... I noticed that when I added it to the menu-bar that the whole system locked up some seconds and behaved weird... some minutes later the Touchpad started jumping again and being unusable... and I was like "Great! -.-"

So since it wasn't the only package I installed today I first thought it might have been the xhotkeys package I installed earlier, but removing it didn't help and I even got the stuck keys bug again x.x

So I digged deeper into it and looked into yum into my update history (see at the end of this post) and uninstalled them all step by step. After uninstalling the gnome sensors applet I didn't experience the stuck keys bug anymore and my Touchpad is useable again.

So could it be that the gnome-sensors-applet (which was set to update its sensors every second in Debian (which made me have those 2 bugs all the time - and which was set to update every 5 sec in Fedora, which made the bug appear less often) requests the update from the Kernel but due to bad ACPI Tables (DSDT) it locks the kernel for some seconds which makes it "drop" key release signals and makes it lose the Touchpad sync???

Could it all be an ACPI problem??? (I thought it in Debian as well but didn't think of this solution!)

Can someone else test it and verify if he experiences the same after removing the gnome-applet-sensors??

I haven't experienced that bug since I removed it (!) - even though I know I removed some other packages as well the bug was still there until I removed this applet.

Uninstalled the following packages I assume which may lock the Kernel:
- gnome-applet-sensors
- lm_sensors

which also removed the following dependencies:
- net-snmp-libs
- hplip
- hpijs
- net-snmp

Note: removing lm_sensors is probably not necessary, because removing the sensors applet from the toolbar already had the effect for me that the touchpad was no more jumpy (which means that the Kernel didn't lose any sync of bytes => doesn't miss key release signals)

Version history (just in case the packages above are not involved - removing the ones (except for the ones marked with (s) which I still have installed) did work out for me!!:
packages installed and experienced the bug after (uninstalled them all again - all packages are i386, used amd64 on Debian):
gai-0.5.10-14.fc9 (*)
gai-temp-0.1.1-9 (*)
aircrack-ng-0.9.3.1.fc9 (s)
xhotkeys-0.9.8.3-5.fc9 (*)
python-xlib-0.13-3.fc7 (*)
ghex-2.22.0-1 (s)
avahi-tools-0.6.22-10.fc9 (*)
crystalsvg-icon-theme-4.0.3.fc9 (**)
OpenEXR-libs-1.6.1-3.fc9
wlassistant-0.5.7-7.fc9
kdelibs3-3.5.9-8.fc9
kde-filesystem-4.14.fc9
ilmbase-1.0.1-2.fc9
arts-8:1.5.9-2.fc9
oxygen-icon-theme-4.0.3-10...

[Arne Fahrenwalde (macgeneral)]

Oh and maybe its a general ACPI problem. I read somewhere that the ACPI Interface in the Kernel changed somewhere around 2.6.24 (I don't know when exactly but I'm sure I can find it out) and I might experience this ACPI bug due to the Sensors applet...

[Chris (bridgeriver)]

I have to retract my statement that turning off APM and the tickless timer in the kernel cured the problem. It just occurred again. On the other hand, it seems to be happening less often than before.

[Mark Schreiber (mark7)]

Setting atkbd.softraw=0 does not resolve the issue.

[Mark Schreiber (mark7)]

Also, a correction from above -- the problematic internal keyboard on my Inspiron 1420 is not being presented to the kernel as a USB keyboard, but as a BUS_I8042 AT keyboard (only realized this when I tried using usbmon to capture traffic from the keyboard).

[beberlei (kontakt-beberlei)]

I experience this sticky key problem to, using Hardy Heron Kubuntu KDE3.

I recently installed it as a fresh version from the image cd on a new computer so the bug should be in one of the basic packages.

@arne: i am running kde and do not have this gnome-applet-sensors module installed, so i doubt that this is the source. I do not have installed the snmp packages either, but hpijs and hplip.

[Arne Fahrenwalde (macgeneral)]

Removing the sensors-applet solved the problem for me! I still didn't experience either this bug nor the touchpad losing sync at all since I removed it!

I don't think its the fault of the applet itself but to bad ACPI requests and or bad ACPI handling!!!

I work alot with my notebook and I experienced this bug like once every 2 minutes especially when programming with Eclipse or browsing the web etc (in nearly every application).
And my Touchpad was unusable right after the notebook was booted!!

And as I said - when I reduced the sensors update interval from 1 sec to 5 sec the bug appeared less often but still appearend a couple of times per hour and the touchpad was partially useable. After removing the applet (and the sensors stuff) from the system I didn't experience any of those 2 bugs at all!!! And that for 2 weeks now and I use my notebook up to 10 hours a day (sometimes even more).

I think in my case at least I could track it down to ACPI! If someone wants me to install the applets again (to prove that my theory is correct and for further testing - I havent done that yet because I work on that notebook alot and I was scared of losing work and much time!) I will do so! But hurry, because I bought myself a PowerBook from Apple and I wont use Linux then anymore. I have only 1 - 2 weeks left for tracking it down (then I give my notebook to my sister)

[Franzmaximilian (davini)]

I add my experience to the (unfortunately) long list of users affected by this nasty "sticky key" problem.
I have exactly the same behaviour on two different machines, a laptop and a desktop of different ages, with different keyboards and mouses. I can't remember if the problem was already there on Kubuntu 7.06, but surely it was on 7.10 and is now on 8.04
On both a stuckkkkkkkkkkkkkkkkk (hey! it really happened just now) key remains stuck until I press another key. If I don't, the key entry is repeated around 15-20 times, then it stops. The mouses too have strange behaviours which I first thought was due to the table surface, but trying different pads or borrowing a different mouse din't change anything. I'm now using Compiz Fusion on my laptop, but it happened before too.
Both my computers have a nvidia video card. Also, i can't find any relation with system load: it happens even while using Kate as the only open program.
Please do something for I'm seriously tempted to move to some other distribution.......

[Matthew Fedderly (mdfedderly)]

For what it's worth, I have the same key repeat problem as Franzmaximilian. However, I just chalked it up to the usb bluetooth receiver losing sync with the keyboard.

I don't know what causes the key repeat, but I can reliably reproduce the 'lost' modifier keys by holding ctrl and moving the mouse out from a vmware guest's window (running the vmware tools).

As for a workaround: I just do system->prefrences-keyboard then go to the layouts tab and just go back and forth between 'generic 104 key' and 'generic 105 key' layouts whenever I trigger the bug. (using only the mouse)

Here is some information on the OS, vmware version, and lsusb output for the bluetooth receiver

OS: Ubuntu Hardy

$ uname -a
Linux constantine 2.6.24-17-generic #1 SMP Thu May 1 13:57:17 UTC 2008 x86_64 GNU/Linux

$ vmplayer --version
VMware Player 2.0.4 build-93057

$ sudo lsusb --v

.. snip ..

Bus 004 Device 013: ID 046d:c70a Logitech, Inc.
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x046d Logitech, Inc.
  idProduct 0xc70a
  bcdDevice 40.05
  iManufacturer 1 Logitech
  iProduct 2 Logitech BT Mini-Receiver
  iSerial 3 00076171E084
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 34
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 4 RR40.05_B0073
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 98mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Device
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 2 Mouse
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.11
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 226
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 5
Device Status: 0x0000
  (Bus Powered)

Bus 004 Device 012: ID 046d:c70e Logitech, Inc.
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 ...

[Franzmaximilian (davini)]

Please do something! I'm experiencing this problem on both my desktop and my laptop computers. While it is a minor problem on my desktop, where recently it shows up only seldom (twice a week), it is now happening with increased frequency on my laptop (twice an hour in average), making it sometimes nearly unusable.
Yesterday I had to shut it off and reboot in WinXP in order to complete an urgent and importan professional task. God knows how I hated doing it!!!!

[Doughy (doughywilson)]

I had a similar issue. When I would type things, sometimes the keys would get stuck so that certain letters were repeated: like thiiiiiiiiiiiiiiiiis. The issue would not go away until I reboot.

I believe I have found a workaround for this issue. When it started happening earlier today, I ran the command "dmesg" to see if anything suspicious was going on. I found multiple lines that looked like this:

[ 6632.422317] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6658.325791] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6692.222563] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6707.261239] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6712.747699] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6718.085649] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6724.837559] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6736.435365] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6762.038942] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6765.228902] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6829.364829] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6850.711037] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6887.346695] usb 1-4: reset low speed USB device using ohci_hcd and address 3
[ 6898.207438] usb 1-4: reset low speed USB device using ohci_hcd and address 3

I noticed that the USB port in question was my MOUSE port, not the keyboard. I unplugged the mouse and put it into a different USB port (on a different controller as well, sometimes multiple ports can go out at once if the controller is bad).

The issue is now fixed for me. It's like the mouse being constantly reset was causing a lag in the system, and if you happened to be typing while the lag occurred, a queue would fill up with your last keystroke. The queue would then "dump" everything after the lag.

It's possible that USB ports being used by other devices, not just the mouse, may be causing the resets to occur. Check your dmesg and see if anything is repeatedly being reset.

[remitaylor (remi-remitaylor)]

Whoa, I has an experience like Doughy's. I booted up without my mouse plugged in ... typed out abunchof lines ... no pauses/repeats. plugged the mouse in ... typed ... got repeats ... checked dmesg and saw new messages about a USB device. Unplugged mouse and it was okay again. Plugged the mouse into a different controller and I haven't had any issues (yet)

Sometime I find a new 'fix' for this bug and it comes right back after a few days, so who knows? The last version of Ubuntu that I was able to run on my laptop was Edgy ... it's been unusable in Feisty / Gutsy / Hardy because of this stupid bug. I've been dealing with it for over a year :(

[noelferreira (noel-oniduo)]

remitaylor :( wellcome to my clube of misery. I hope you resist like me and don't turn back to windows please :). Disable the ACPI in my boot is the only workaround that let's me use my computer: :) good luck

[Franzmaximilian (davini)]

Since a few days I had no more issues with stuck keys on my laptop computer, so I begun to think what I did change on it. I came to the conclusion that since approximately the same time I took the behaviour of disabling the wifi card, which i seldom make use of, after the boot.
I then made some tests and I can now confirm I do not have any stuck key problem when wifi is off, while the problem occurs again when it's on.

Now, wifi itself can not be not the real cause, for stuck keys happen on my desktop computer too, where there is no wifi card.

How things work at kernel level is far beyond my understanding, but i hope this little piece of information can be useful to someone.
Franz

[Necreia (necreia)]

I've bought two laptops, and get this issue in Hardy Heron (AMD64) on both of them. They both have the following spec's

4GB, DDR2, 667MHz 2 Dimm
256MB NVIDIA GeForce 8600M GT
250G 7200RPM SATA Hard Drive
Dell Wireless 5720 EV-DO Revision A Mobile Broadband Built-In Mini-Card
Dell Wirless 355 Bluetooth Module (2.0+EDR)
Dell Wireless 1395 802.11g Mini Card

The only difference between the two are the processors:
Intel Core 2 Duo Processor T8300 (2.4GHz/800MHzFSB, 3M L2 Cache)
Intel Core 2 Duo Processor T9300 (2.5GHz/800MHzFSB, 6M L2 Cache)

It's a nightmare...

[Andrew Williams (aw-siliconpeanut)]

I had an experience similar to Franzmaximilian's. On a new Hardy install, the keyboard would be fine until I enabled the wifi interface, and then it would immediately start repeating or have very long (30 sec) latency between keystrokes.

I resolved this by changing the wifi nic. I removed the Netgear WG311 (with the notorious ACX111 chipset) and replaced it with a Linksys WMP54G, did a fresh install, and everything worked right out of the box...no kb issues and the wifi works flawlessly with NetworkManager.

[sawk (sawk-ita)]

I've SOLVED this problem.

I'm using Archlinux, and when i had upgrade the kernel, the file /etc/mkinitcpio.conf didn't update.
mkinitcpio.conf is used by Archlinux to generate a kernel image with command mkinitcpio. In particular, one line on this file has been changed:

HOOKS="base udev autodetect pata scsi sata filesystems keyboard"

to

HOOKS="base udev autodetect pata scsi sata filesystems"

( The "keyboard" option now is deleted. )

I've update the file mkinitcpio.conf and now ALL IT WORK perfectly. So i think is a kernel building problem. Try to contact the ubuntu's develop.

Sawk

[Tom Jaeger (thjaeger)]

From which version of mkinitcpio.conf did you upgrade? I can't find a single version of the package that even has a keyboard hook.

[legolas558 (legolas558)]

This is most surely kernel bug 9147:

http://bugzilla.kernel.org/show_bug.cgi?id=9147

[sawk (sawk-ita)]

I'm very sad....

after 3 weeks the problem is still present.....ufff.
Sorry for my comment...

[Chris Jones (cmsj)]

sawk: if you are sorry then that means you know your comment isn't helpful.

Perhaps you could instead answer the question from Tom Jaeger about which versions you are talking about.

FWIW, i don't think your solution applies directly to Ubuntu anyway - I don't seem to have any trace of mkinitcpio on my system (Hardy).

[legolas558 (legolas558)]

The "keyboard" hook does not even exist (see http://wiki.archlinux.org/index.php/Mkinitcpio#Configuring_the_HOOKS), comment #173 is a false solution as sawk also says in comment #176.

The only known workarounds known to me (and people of kernel bug http://bugzilla.kernel.org/show_bug.cgi?id=9147) are:

1) using kernel parameter 'acpi=off'
2) OR unloading the battery, ac and thermal modules

Please confirm them or tell me about different workarounds if you know any. On the kernel bug tracker we have almost identified the cause and seems only fixable in the kernel.

[Doughy (doughywilson)]

This problem does exist on Ubuntu. Like I said before, the only workaround
I know of is to take the mouse out and plug it back in. This fixes the
keyboard for some reason. I only have this problem on an AMD processor.

On Mon, Aug 4, 2008 at 4:39 AM, legolas558 <email address hidden> wrote:

> The "keyboard" hook does not even exist (see
> http://wiki.archlinux.org/index.php/Mkinitcpio#Configuring_the_HOOKS),
> comment #173 is a false solution as sawk also says in comment #176.
>
> The only known workarounds known to me (and people of kernel bug
> http://bugzilla.kernel.org/show_bug.cgi?id=9147) are:
>
> 1) using kernel parameter 'acpi=off'
> 2) OR unloading the battery, ac and thermal modules
>
> Please confirm them or tell me about different workarounds if you know
> any. On the kernel bug tracker we have almost identified the cause and
> seems only fixable in the kernel.
>
> --
> Keyboard keys get stuck and repeat (Feisty, Gutsy)
> https://bugs.launchpad.net/bugs/124406
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[legolas558 (legolas558)]

> This problem does exist on Ubuntu. Like I said before, the only workaround
> I know of is to take the mouse out and plug it back in.
> This fixes the
> keyboard for some reason. I only have this problem on an AMD processor.
>

We have to make a diversification here. This kernel bug (http://bugzilla.kernel.org/show_bug.cgi?id=9147) is relative to ACPI and/or i8042 chipset and is being addressed by an Intel developer (although the i8042 chipset is not necessarily used only on computers using Intel CPUs). You can see that you have bug 9147 because when a key gets stuck you find on dmesg:

...
atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
...

This happens, as far as I know, *exclusively* with i8042 chipset, ACPI active, battery/ac/thermal module (or code if you have compiled it statically in the kernel) active and a PS/2 keyboard (even embedded, like those of many notebooks) of course.

Since you have an USB keyboard and since you are not getting the atkbd.c messages, I think your bug is a different one (you're lucky, kernel bug 9147 does not seem to be fixed very soon...)

@everybody: please post a comment if you have an i8042 chipset and can add informations (or confirm them)

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Harvey Muller (hlmuller)]

Results of testing on a Dell Inspiron 1420. Installed 20080829 daily-live amd64 desktop (Intrepid Alpha 5) with kernel 2.7.27.

I am unable to reproduce the problem. I performed the installation, switched the Caps Lock/Ctrl keys and spent 10 minutes trying to get an unwanted key repeat. Continual use will confirm it is resolved.

Thanks,

Harvey

[David Oftedal (rounin)]

I'm having this problem in Kubuntu on a Fujitsu Siemens Amilo laptop with an ATI chipset and without Compiz Fusion. I'm getting the atkbd.c error message, but not the USB error message.

[13300.027424] atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
[13300.027430] atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.

[David Oftedal (rounin)]

lspci:

00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:04.0 PCI bridge: ATI Technologies Inc Unknown device 7914
00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2)
00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 01)

uname -a:

Linux (hostname here) 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux

[Leann Ogasawara (leannogasawara)]

Hi David,

If you could please test the latest 2.6.27 kernel as Harvey did that would be great. If anyone else can test 2.6.27 as well that would be much appreciated. Please let us know your results. Per Harvey's comment I'm tagging this 'fixed-2.6.27' but will not officially update the bugs status until we get more feedback as there seem to be quite a few subscribers here. Thanks.

[David Oftedal (rounin)]

I've seen the reference to the 2.6.27 kernel, but as far as I can see, it's not in the APT repository, and unless it can be installed quickly from a package, it'll take too much time away from the tasks the machine is actually meant to be used for to test a new kernel. Not to mention that ascertaining whether the bug is still there is a process which has to last at least a day.

[dotancohen (dotancohen)]

I can confirm this bug on two machines:

1) Dell Inspiron E1505 / 6400, Kubuntu 8.04, Compiz, KDE 3.5.9 and KDE 3.5.10
On this machine the built in keyboard functions fine, however USB keyboards repeat keys with no output to dmesg.
$ uname -r
2.6.24-19-generic

2) Homebuilt AMD machine with Asus motherboard, Kubuntu 8.04, KDE 3.5.9, no Compiz
On this machine ps/2 keyboards function fine, however USB keyboards repeat keys. I have not checked dmesg output on this machine.

On both computers, USB kkkkkkkkkeyboards make text like yoooooou see here (thisssss line typed onnnnn a USB keyboard).

[Mark Brannan (markbrannan)]

I notice that one other person is using a KVM switch. The problem is intermittent for me but I realize now that it began just after adding a linksys KVM switch (connected through PS2) setup and have just found that I can usually stop the problem by removing the KVM and going direct. Of course this is very inconvenient but at least it's usable...

I am using 8.04 without any visual effects enabled.

2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 GNU/Linux

[128133.688108] atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
[128135.921880] atkbd.c: Unknown key released (translated set 2, code 0xe1 on isa0060/serio0).
[128135.921887] atkbd.c: Use 'setkeycodes e061 <keycode>' to make it known.
[128135.924275] atkbd.c: Unknown key released (translated set 2, code 0x65 on isa0060/serio0).
[128135.924280] atkbd.c: Use 'setkeycodes 65 <keycode>' to make it known.
[128135.925476] atkbd.c: Unknown key released (translated set 2, code 0x0 on isa0060/serio0).
[128135.925480] atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
[128147.523342] logips2pp: Detected unknown logitech mouse model 62
[132710.018429] usb 2-2: new low speed USB device using ohci_hcd and address 4
[132710.270068] usb 2-2: configuration #1 chosen from 1 choice
[132710.289124] input: Macally Peripherals Evoluent Optical USB/PS2 Vertical Mouse as /devices/pci0000:00/0000:00:12.1/usb2/2-2/2-2:1.0/input/input10
[132710.327090] input,hidraw0: USB HID v1.10 Mouse [Macally Peripherals Evoluent Optical USB/PS2 Vertical Mouse ] on usb-0000:00:12.1-2

[Tommaso Cucinotta (cucinotta)]

I don't know if this can help, but on my system (Dell Latitude D830 with Ubuntu 8.04 x86_64, details below) this happens apparently only when I launch Emacs (22.1.1) from X (using Gnome), and I try to Alt-Tab to some other applications.
I can Alt-Tab from any other applications without problems, but when I do that from Emacs (and I can edit and type whatever within Emacs without problems), keyboard hangs and does not respond anymore, but actually the entire windowing system hangs and does not even respond to mouse.
Switching to console mode, then to graphics mode again takes everything back to life again. Tried both with accelerated NVIDIA driver and with default "nv" one, behavior is the same.
Also, this behavior is *deterministic*: just one simple Alt+Tab from Emacs, and I'm lost.
I verified that it does not happen when trying to switch from a terminal running emacs22-nox.
This would seem to be a problem of the windowing system, but probably triggered by something that only Emacs does.
This was not happening before (I use a lot Emacs from X/Gnome), so it must have been caused by some recent upgrade.
For what it may concern, this happens both from the laptop keyboard and from an external one connected to the docking station (actually, it's a PS/2 keyboard routed through a PS/2->USB video/mouse/keyboard switch).

Finally, don't know if it may be relevant/useful, but it's already a few months that my Ubuntu/Gnome refuses to configure correctly the keyboard layout, no matter how many times I tell it I want an IT one by default, I always get a US one (it's only X/Gnome, because the text console gets correctly the configured default). No matter if I delete the US configuration, leaving only the IT one, it will always be US after boot.
--
Kernel (default Ubuntu): Linux laptop 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux
Attached a log of hopefully relevant installed applications along with their versions.

[Tommaso Cucinotta (cucinotta)]

Just verified that the same bad behavior exists with kernel 2.6.26.5 Vanilla (attached detail of configuration).

[Tommaso Cucinotta (cucinotta)]

It seems that, removing *accessibility packages*, fixes the situation (or at least it cannot occur so easily now).
I just removed these two packages:

< ii gnome-accessibility-themes 2.22.0-0ubuntu1 accessibility themes for the GNOME 2 desktop
< ii gnome-accessibility-themes-extras 2.22.0-0ubuntu1 accessibility themes for the GNOME 2 desktop

[Cruncher (ubuntu-wkresse)]

Tommaso, the problems that you describe do not match this bug description.
This bug is about:
- sometimes the system thinks that a key is still pressed although it has been released already, resulting in key repeat for that key
- no freezing, the system will recover from the "stuck key" by itself after about one second
This bug is NOT about:
- freezing of the whole X window system, recoverable or not
- problems with only very specific keys and/or applications (at least so far it couldn't be narrowed down to specific appllications)

Please search for another bug that better matches your symtoms/situation, and if there is none, please open this as a new bug.

[legolas558 (legolas558)]

@Cruncher: any official statement about this bug being the same as this kernel bug: http://bugzilla.kernel.org/show_bug.cgi?id=9147 ?

[Gene Caldwell (gene-caldwell)]

I am having this problem on every computer I have installed 8.10 on. I have some computers connected to a KVM, but others ARE NOT. my laptop IS NOT connected to a KVM and the same problem exist. This problem existed in 7.04 and was finally corrected in 7.10 and 8.04, but now its back. it does not matter if it was a fresh install or an upgrade.

[Gene Caldwell (gene-caldwell)]

I read something above about this being fixed......humm, nope its not fixed on kernel 2.6.27

[Rich (rmidwinter)]

This is still an issue for me, running 8.10 on a Dell 9400 laptop.

[Sardar (ja-doma)]

Same laptop (HP Pavilion dv5000, Centrino Duo), same kernel version 2.6.27.4, installed Arch Linux, bug disappeared. This is probably Ubuntu only bug, maybe some custom patch.

acpi=off as kernel parameter solves the problem too, but this removes support for synaptic touchpad, battery monitor and some keys -- thus not a solution.

[nutmac (peanutjelly)]

Setting "acpi=off" seems to delay the problem from occurring. But he problem inevitably resurfaces, particularly when using resource intensive applications such as Eclipse. I am using Dell Optiplex 755 desktop (4 GB RAM with Intel GMA X3100). The only surefire workaround is turning off "Repeat keys" option under Keyboard Preferences.

[ekerazha (ekerazha)]

I confirm this issue on Gutsy and Intrepid (I didn't test Feisty and Hardy).

I have this issue using a Logitech USB wireless keyboard. When the issue happens, I can temporary fix the issue by switching the USB port where the USB wireless receiver is connected... when it happens again, I switch the USB port again etc. etc.

This issue is veeeeeeery annoooooyingggg ;-)

Intrepid is still affected by this issue. This bug *doesn't* exist on Microsoft Windows and on Arch Linux, I think this could be yet another Ubuntu "mispatching" of vanilla sources (Linux kernel?).

[ekerazha (ekerazha)]

This bug seems similar to this - old - one: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/39315

[Ben (benny-and-the-bikes)]

Me too ...

[Sardar (ja-doma)]

After upgrade Arch has now the same problem, not that frequent as Ubuntu (once in 10 minutes), but happens once in a day. Definitely kernel problem.

As usual, unloading ac, thermal, battery solve the problem. But without battery the life is horrible on the laptop... =/

[legolas558 (legolas558)]

Is there a testcase for this bug? I was affected by kernel bug 9147 (which might be the same as this one) but problem seems disappeared with Intrepid Ibex...

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Don (donweber)]

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

[David Oftedal (rounin)]

Are you by any chance getting error messages like this in dmesg?

[4335062.871000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335063.546000] atkbd.c: Unknown key pressed (translated set 2, code 0xaa on isa0060/serio0).
[4335063.546000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335063.607000] atkbd.c: Unknown key released (translated set 2, code 0xaa on isa0060/serio0).
[4335063.607000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335073.996000] atkbd.c: Unknown key pressed (translated set 2, code 0xaa on isa0060/serio0).
[4335073.996000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335074.114000] atkbd.c: Unknown key released (translated set 2, code 0xaa on isa0060/serio0).
[4335074.114000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.

If you are, they might be caused by a service called "hotkeys-setup". I've been having a problem with a stuck ctrl key across several releases and configurations of Ubuntu, and removing hotkeys-setup now finally seems to have solved the problem.

[Sardar (ja-doma)]

2Don, I think the priority of interrupt handling is not the problem, the race conditions are. I've never had this problem on single-core CPU. Unloading most of ACPI stuff will solve the problem, however this is a nasty solution (I've laptop and use events of ac/battery for energy profile changes).

It might be also the problem of keyboard itself, the firmware that acts odd... In windows I get shift/ctrl/alt stuck every 2-3 hour, especially if Firefox + Zend studio are loaded. Wit the latest patches (auto-install 2-3 weeks ago) the problem is now appearing even more frequent. Anyway this proves that keyboard is handled differently in Windows and Linux, I've never seen repeating keys (missing ordinary key release) in Windows and stuck control keys (missing shift/ctrl/alt key release) in Linux.

I will try to compile non-preemptive kernel and report results later.''

2David Oftedal no, I dont' see these messages in dmesg.

[legolas558 (legolas558)]

As said previously, this seems to be exactly upstream kernel bug http://bugzilla.kernel.org/show_bug.cgi?id=9147

I have worked around the problem by unloading modules 'ac', 'battery' and 'thermal'.

Also, problem appears when there is intensive use of ACPI events (e.g. when on battery) and/or when using the wireless adapter.

I agree with Sardar that IT IS VERY WEIRD that problems does not arise in Windows but only in Linux.

On the kernel bugzilla I have suggested, upon G. Schmitt's hint, to use an approach similar to that in kernel bug http://bugzilla.kernel.org/show_bug.cgi?id=12021 with a modified version of this patch http://bugzilla.kernel.org/attachment.cgi?id=19301&action=view

Perhaps Windows already fixes the key-up event for this hardware? Or the problem relies in the EC tables? Who knows...

[David Oftedal (rounin)]

Unfortunately, disabling hotkey-setup didn't fix the problem after all. The bug just took a long time to return this time.

[David Oftedal (rounin)]

An old mailing list posting regarding the kernels 2.6.0-test1 and -test4 may hold the answer to the problem:

http://lkml.org/lkml/2003/9/15/210

On Mon, Sep 15, 2003 at 08:55:46PM +0000, xsdg wrote:
> What would happen if the kernel received two keypress events, and then one key-
> release event for a single key? I'd imagine that it'd disregard the duplicate
> keypress

The answers differ for 2.4 and 2.6. For 2.4 each keypress is a keypress,
and key releases are rather unimportant as long as the key is not a
modifier key. For 2.6 we have synthetic repeat, so a second keypress from
the keyboard is ignored, the key repeats with kernel-defined frequency,
and the repeat is ended by the key release.

> any idea what might cause the key sticking problem?

If a key release is not seen, 2.4 doesnt mind, but 2.6 keeps repeating.

> Also, I'm not sure how the final issue I described

Do not recall all items of all letters I answer - sorry.

Andries

If this is the source of the problem, then the only permanent solution would probably be to downgrade to a 2.4 kernel or use another operating system.

[David Oftedal (rounin)]

Also, the person making the complaint is using the i8042 keyboard controller and getting the same error messages:

Sep 14 20:42:27 cpp kernel: atkbd.c: Unknown key (set 2, scancode 0xb6, on isa0060/serio0) pressed.
Sep 14 20:42:27 cpp kernel: i8042 history: 19 a2 99 0f 8f 0f 8f 1c 9c 04 84 36 09 b6 89 b6
Sep 14 22:13:00 cpp kernel: atkbd.c: Unknown key (set 2, scancode 0xa5, on isa0060/serio0) pressed.
Sep 14 22:13:00 cpp kernel: i8042 history: a7 20 9e 21 9f 24 25 26 27 a0 a4 a5 a6 a7 a1 a5
Sep 14 22:13:00 cpp kernel: atkbd.c: Unknown key (set 2, scancode 0xa6, on isa0060/serio0) pressed.
Sep 14 22:13:00 cpp kernel: i8042 history: 20 9e 21 9f 24 25 26 27 a0 a4 a5 a6 a7 a1 a5 a6
Sep 14 22:13:00 cpp kernel: atkbd.c: Unknown key (set 2, scancode 0xa7, on isa0060/serio0) pressed.
Sep 14 22:13:00 cpp kernel: i8042 history: 9e 21 9f 24 25 26 27 a0 a4 a5 a6 a7 a1 a5 a6 a7

[Brian (brian-palmergb)]

I raised an issue under the hardware section for the same problem.
I'm running Ubuntu 8.04 and it's been ok since late last year when I loaded it into my PC.
On or about 6th February, the keyboard started to hesitate and the keys repeat. There is a long delay between typing the characters and their appearance on the screen. There is also a problem with random repeating characters. I've stopped the repeats by un-checking the repeat box in the keyboard set up.
This problem doesn't happen in Window or when running Mandriva One from a CD.
I have tried four different keyboards and they all exhibit the same problem

If anybody can suggest any tests I can run to assist with resolution of this issue, I'll gladly help.

[legolas558 (legolas558)]

 @David Oftedal: would it (theorically) be possible to use the 2.4 keyboard handler for a specific notebook model? We have tried this patch http://bugzilla.kernel.org/attachment.cgi?id=20049 without any luck...

Perhaps a more radical approach is necessary?

[Cruncher (ubuntu-wkresse)]

This can't be a bug in Emacs, since I never used Emacs on my machine, and never will. To my knowledge it has been established that this bug affects *many* applications, and also seems to be more frequent in certain hardware setups. All this points to it being a deeply embedded problem, most likely of the kernel, and not a bug of any application sitting several layers above the keyboard handling.

[Brian (brian-palmergb)]

This bug is apparent in every application that I use. Spreadsheet, Word Processor, Email and even when writing on this page. So it's certainly not application specific; or keyboard specific as I've tried two PS/2 type keyboards and two USB keyboards.

[legolas558 (legolas558)]

@Cruncher: I still think that this is kernelbug 9147: http://bugzilla.kernel.org/show_bug.cgi?id=9147

[David Oftedal (rounin)]

That's very difficult for me to guess, legolas... But the mailing list thread quoted on http://bugzilla.kernel.org/show_bug.cgi?id=9147 seems to indicate that modifier keys such as Ctrl and Alt were handled the same way in 2.4 as all keypresses are in 2.6; that is, they weren't released until a keyup event was registered. For me at least, it's primarily the Ctrl key that's creating a problem in the first place, although there are a few glitches involving the mouse or other keys from time to time.

As mentioned in the other thread, though, if the bug you're experiencing is bug #9147, you should be able to temporarily clear it up by hitting Ctrl-Alt-F1, which somehow resets the keyboard driver, perhaps by attempting to switch from X to the console. It's just a way of working around the bug, of course, but it's much, much quicker than exiting all one's applications and restarting X.

If, on the other hand, this trick doesn't work for you, there's a chance that we're dealing with more than one bug.

[legolas558 (legolas558)]

I can witness that kernel bug 9147 happens with any key, not only modifier keys.

I will try that trick as soon as I trigger again the bug, as I am currently not loading the ac, thermal and battery modules at boot time.

Can people here say if bug happens also when ac, thermal and battery module are NOT loaded?

This would definitively say if it's the same bug or not.

[legolas558 (legolas558)]

when the bug is happening, it stops when pressing Ctrl + Alt, I don't need to press also F1. However the Ctrl+Alt+F1 trick works. In my case pressing any key stops the behaviour.

[raphenry (raphenry)]

I am having the same problem with Hardy Heron 8.0.4.2, kernel 2.6.24-23-generic. i have had ubuntu on since 7.04 and this is the first instance i have had.

[legolas558 (legolas558)]

@raphenry: can you please say if problem goes away when unloading ac,thermal,battery modules (rmmod ac thermal battery)?

[Brian (brian-palmergb)]

unloading ac, thermal , battery doesn't make any difference. I still get the hesitation and the repeats.

[raphenry (raphenry)]

i am not suuuure abuot the ac thermal battery modules,,,,,,,,,,,,,,i have never seen those before, i will check,,,,,but i hit the ctrl-alt-F1 and i was stuck in terminal, cause mmmmmy keyboard malctions, also when i starteddddddddddddddd my laptop, the mouse diiiiiiiiid not work, after the ctrl-alt-F1 the mouse works, but now my USB doeeeeeeeeeeeesnt work anymore. This is annoying.

[raphenry (raphenry)]

i dont know how to unload ac, thermal or battery modules, but i did shut of the key repeat, so now i only have key misses.
Also my fan for my laptop is constantly cycling, is this the thermal module that is mentioned, it did not cycle like this before.

[legolas558 (legolas558)]

@raphenry: sudo rmmod ac thermal battery fan container acpi_cpufreq

@Brian: yours is not kernelbug 9147, good...

[Tim Gardner (timg-tpi)]

Can you folks try the Jaunty LiveCD? I think all of the suspect modules are now built into the kernel.

[Harvey Muller (hlmuller)]

Tested an amd64 Jaunty installation for this issue (Beta plus updates), and the results are GOOD. My original bug report is a duplicate of this bug:

    https://bugs.launchpad.net/bugs/213669

Not only can I NOT generate a key repeat now, but when the Caps and Ctrl key are swapped, the Ctrl key triggers the Caps Lock led which is nice.

Thanks,

Harvey

[Tim Gardner (timg-tpi)]

Given the positive feedback from Harvey Muller, I'm closing this bug.

[Anders Kaseorg (andersk)]

I never had the particular symptoms described in bug 213669 (Caps Lock causes keys to repeat), but I still see this bug (Keyboard keys get stuck and repeat) on my fully-updated Jaunty system. It happens very occasionally, once an hour or so, with no particular pattern that I can observe, but it is definitely there.

I also see the atkbd messages that others have been reporting, although I’m not certain if this is related.
[ 1985.034169] atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
[ 1985.034175] atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.

I think this bug should be reopened, but I will wait for some feedback before doing so myself.

[David Oftedal (rounin)]

Yes, there's no indication on kernel.org that the bug has been fixed either: On http://bugzilla.kernel.org/show_bug.cgi?id=9147 , the status is listed as ASSIGNED.

Unless we're actually dealing with several different bugs here, the bug is therefore probably still there.

[David Oftedal (rounin)]

And by the way, if your computer is affected by kernel.org bug #9147, try pressing Ctrl-Alt-F1 in X. At least on my system, when the bug occurs, this resets the keyboard driver somehow and refreshes the screen, instead of bringing up the console, as one would expect.

[Anders Kaseorg (andersk)]

Yeah, Ctrl+Alt+F1 switching you immediately back to X is bug 271962 (unrelated, but actually kinda helpful when working around this bug :-)).

[Bryce Harrington (bryce)]

On Tue, Apr 14, 2009 at 07:12:17PM -0000, David Oftedal wrote:
> And by the way, if your computer is affected by kernel.org bug #9147,
> try pressing Ctrl-Alt-F1 in X. At least on my system, when the bug
> occurs, this resets the keyboard driver somehow and refreshes the
> screen, instead of bringing up the console, as one would expect.

Sounds like a known bug in console-kit, where the first ctrl-alt-f1
doesn't "take" (still causes a graphics refresh), but hitting it a
second time in succession makes it switch.

[Leann Ogasawara (leannogasawara)]

Just want to add a few things here:

First, @Anders Kaseorg please do no assign developers to bugs without their consent first. A developer will assign himself/herself a bug when they are actively devoting time to working on the bug. There's a reason they may have unassigned theirself if they do. Reassigning without their consent gives a false sense to subscribers that a bug is actively being worked on by someone when that might not be the case. It's best to leave it to the discrection of the developer for when they'll take ownership of a bug. I've spoken with Tim and am unassigning him.

Second, this bug is becoming wildly long and hard to follow especially with feedback that this issue is resolved for some but may still remain for others. Indeed I feel there may be several bugs at play here. @Guy Gur-Ari, since you are the original bug reporter, can you comment if this issue still exists for you with the latest pre-relase of Jaunty 9.04? For anyone still experiencing issues with the latest Jaunty pre-release, it may be best to open a new bug that strictly focuses on your specific hardware. Thanks.

[Xavier Aragon (xarax-lp)]

I upgraded two machines from Intrepid to Jaunty and started having this problem of stuck keys. It never occurred before the upgrade, and as the two machines have very different hardware, I would imagine the problem is not hardware dependent.

I have two ways of reproducing the problem:

1) In a gnome terminal say 'xset r off' to turn off autorepeat (assuming it was on initially), and I have the enter key stuck (repeating as if it was being pressed). Hitting enter again does not stop the repeating.

2) When running a VMWare virtual machine in a vmware remote console window, hit the title bar of the window to give it focus, then press Ctrl-G to enter the virtual machine. The key 'g' starts repeating like if it was being pressed down constantly. I don't know exactly what the vmware console does when activated, at least it grabs the keyboard and mouse, perhaps it does something to autorepeat settings as well.

The way I can recover from the "stuck key" condition is to somehow issue the command "xset r rate 500 3" or something similar with a very slow repeat rate (3 times a second in this example), and then hit any key. Turning autorepeat off with 'xset r off' does not help, but a slow repeat rate does. In my case 1 I can issue the command from a virtual console by first ntering it with Ctrl-Alt-F1, but in case 2 the vmware remote console has grabbed the keyboard and the only way to recover is to log in with ssh from another machine to issue the command.

To me the problem seems very closely related to the Xserver's key autorepeat functionality. It used to work before upgrading to Jaunty, but now it is seems broken. It key getting stuck is the one that was last pressed when some autorepeat related operation is made (in the first example turning autorepeat off, in the second example perhaps grabbing the keyboard or doing something with autorepeat settings).

[Anders Kaseorg (andersk)]

> 1) In a gnome terminal say 'xset r off' to turn off autorepeat (assuming
> it was on initially), and I have the enter key stuck (repeating as if it
> was being pressed). Hitting enter again does not stop the repeating.

Oh wow, I can reproduce this on Jaunty too. I don’t know if it’s the same bug that I see randomly during normal usage, since that tends to stop when I hit the key again, but it is likely related.

[Harvey Muller (hlmuller)]

The 'xset r off' behavior is interesting. If I run, as previously identified:

    $ xset r off

I get a hard 'Enter' key repeat that I do not know how to recover from other than rebooting.

If I run instead:

    $ sleep 2 && xset r off

Then I do not get the 'Enter' key repeat. But I do get key repeats again as described in the dup bug I reported #213669. But this is resolvable by running:

    $ xset r on

I am currently not having problem with key repeats unless I run 'xset r off'. And I do not normally have a reason to do so.

[Martin Olsson (mnemo)]

If you have solid repro steps, please go to http://bugs.freedesktop.org/ and open an upstream bug report. Thank you.

[Xavier Aragon (xarax-lp)]

I have reported my observations with Jaunty and 'xset r off' to the upstream bug tracker as http://bugs.freedesktop.org/show_bug.cgi?id=21454 .

[Jason Straight (jason-jeetkunedomaster)]

After reading the comments here I'm not sure if I've got the same bug(s). But this just started for me with Jaunty.

I not only get repeating keys, but also many missed keys that don't register a keypress when typing quickly. Booting to windows - no problem.

I can reproduce the sticky keys fairly regularly by depressing 2 keys at once every few seconds, within a few presses I'll end up with a runaway key.

I don't see the problem in console VT1 , even if I have an X session logged in on VT7and running my usual stuff.

I've started xinit with nothing but an xterm to rule out any applications such as compiz, kde, etc. I've switched between radeonhd and FGLRX as well. The only constant seems to be X itself.

[K Runge (ubuntuforums)]

The 'xset r off' bug is being reported here as well:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/367136

It seems like a new bug not related to the one originally reported in this one.

[Rolf Leggewie (r0lf)]

I've reported something similar in bug 376485 which I have experienced after updating from hardy to jaunty since January. Whatever this ticket is about, I'll keep mine separate at least for now.

1) not related to high load for me
2) mouse continues to work fine here
3) never happened before (I used edgy, feisty, gutsy, hardy without problems)
4) the only keys stuck are Ctrl+1 to Ctrl+4 when switching Workspaces in Gnome

[BobRoss (bobrossw)]

I'm getting a similar bug in Jaunty only. I just installed Jaunty for the first time (new linux user) a few weeks ago...had this problem. Reinstalled Hardy, the problem went away. Upgraded tooooooooooo Ibex, and the problem stayed away. Now I've upgraded ttttttttttto (see?) Jaunty again and the problem is back. This has been consistent regardless of what program I am typing in (including terminal and login screen).

I'm using a compal IFL90 notebook (Sager NP2090, which is the same thing) with a USB mouse plugged in (athough I can replicate the problem without the mouse plugged in). It has an Intel Core 2 Duo processor and an GeForce 8600 M GT video card.

Turning off key repeat fixes some of the problem, but I still get dropped keypresses.

I think I can replicate it by touching the touchpad while typing fast, and I can't seem to replicate it when I make a conscious effort not to touch the touchpad.

Disabling the touchpad through system>preferences>mouse does not seem to fix the problem and it still seems to happen while touchiiiiiiiiiing the touchpad (even though, it doesn't actually move the mouse).

I also have not been able to replicate while avoiding the touchpad and moving the mouse while typing.

Any help would be greatly appreciated.

[François Rey (fmjrey)]

I also have it on Kubuntu 9.04 amd64 with kernel 2.6.29. My most interesting facts are:
- I had this bounce key pb when installing from kubuntu 9.04 live CD! I had to restart with my mouse connected to the laptop to continue
- it only happens on my 7 ports D-link usb hub (DUB-H7), not on my hama 4 port hub
- does not happen on windows xp with same setup
- see outpuf of dmesg, lspci, lsusb, and uname in attached tgz

I really would like to see this bug getting a high priority:
- it's a widespread issue for several linux distributions and somehow Jaunty seems particularly affected
- it's a long standing issue (duplicate bug https://bugs.launchpad.net/bugs/91230 is 2 years old, reported on 6.10)
- the loss of keyboard and mouse is a serious showstopper for anyone trying linux especially when it happens during install

Please help!

I'm no kernel developer but I've been browsing a bit and here is the most interesting discussion I found:
http://<email address hidden>/msg18199.html

It basically says: --quote-- If I start with FC4's kernel configuration, and a
vanilla kernel, the mouse works correctly. If I then turn on kernel
preemption, and set HZ=1000, the problem comes up. Neither of those
settings, by themselves, seem to trigger the problem. -- unquote--

Duplicate bug https://bugs.launchpad.net/bugs/91230 may yield interesting information too. I any case, I'm pretty sure it's a tough longstanding kernel bug, so whoever gets to fix it will get kudos from many people and will help linux getting further (that bug already kept me away from migrating to Kubuntu a couple years ago).

[Mark Schreiber (mark7)]

This is still present for me in Jaunty.

Unless the problem that Harvey and I are seeing is different (which seems very unlikely; both of us have Inspiron 1420s, both of us see the problem only with swapcaps, and both of us see the same symptoms: a key-up event for some regular key does not make it up out of evdev, making xorg think that the key is still down -- but the kernel knows that the key is up, as it does not generate auto-repeat events, and the problem does not thus "show up" on the console, where key repeats come from kernel-generated autorepeat events rather than the key behing held down), I expect that the problem is actually still present for Harvey too.

[François Rey (fmjrey)]

I have experienced the problem again even though the mouse was connected directly to the laptop. The root of the problem is very elusive. I really don't want to buy another hardware, that's not the solution at all. As far as I am concerned, the only option I have left is to try another linux distribution and hope for the best. But this issue is found on other distro too... so maybe I should just give up with Linux.

Possible duplicates on the web that may yield interesting information:
https://bugs.launchpad.net/linux/+bug/88746
http://taint.org/2006/12/13/191554a.html
http://bugs.gentoo.org/177266
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419

This bug is a real linux killer...

[BobRoss (bobrossw)]

After trying out a few other distros (the newest Linux Mint, and the latest Mandriva) I've still had the same problem. I finally did a fresh install of Mint 6 (almost the same as Intrepid) and I'm no longer having the bug problem. I know some people here reported this bug on Gutsy and Hardy, so I'm guessing they're really separate bugs, as Hardy and Intrepid both work fine for me.

Before giving up on Linux, I'd recommend trying different versions out (rather than the newest versions of different distros, that all use the same or similar kernels/versions of X). Note, I did not need to install the distros to get the bug, I got it while running them from CDs...so worst case scenario you waste a few hours and a couple CDs before switching to back Windows.

Again, I'm a total linux newb, so if I'm saying anything blatantly wrong, feel free to correct me.

[Sardar (ja-doma)]

This problem is really hardware dependent. It shows up on HP Pavilion dv5000 independent of the distro (Ubuntu, Arch, Gentoo, latest).
But on my new Acer Aspire 7730G and Acer TravelMate 5310 of my friend everything works fine.

So I think there is a bug in the hardware, that windows apparently knows how to fix/deal with it at runtime, while linux kernel don't.

[François Rey (fmjrey)]

Following BobRoss suggestion I tried another live CD. Because I saw less reports of this problem on the Arch distro, I went ahead and tried Chakra Linux alpha2 live CD, a distro derived from Arch. I was able to reproduce the bug right from start, but I only noticed it when looking at the kernel log (dmesg). That's because in spite of all the usb resets, the keyboard remained steady and I could type without difficulty. The mouse pointer was at times unsteady but still usable and much less jerky than on Kubuntu. So I could imagine this bug being less noticeable on arch.

Running the chakra alpha2 live CD and playing around, I have seen some instances of the keyboard alone being reset after the mouse was disconnected, but mostly it's the mouse that triggers the problem and gets reset. Doing a tail-f on /var/log/kernel.log, I could notice there was no reset when not using the computer. As soon as I move the mouse (doesn't matter if it's with the touchpad or the external mouse), I see resets returning. Keyboard activity also triggers resets but it's a lot less obvious. I tried several mice from several brands, but they're all the same.

I'm not sure which piece of hardware is involved in creating this bug, definitely a combination of various factors. If as Sardar suggests it's possible to systematically reproduce the bug on one piece of hardware, then tracking this bug down may get easier. Included in a tgz file are output from uname -a, dmesg, lspci -vv and lsusb -vv.

[Rudd-O (rudd-o)]

Same problem here. NVIDIA driver, compiz, Fedora 11 RC, . It's not a problem with compiz, it's a problem with the X server or the input layer (evdev) in the kernel.

[Marc Jauvin (marc-r4l)]

The common thing between all those reports seems to be NVIDIA graphic
card... is there ANYONE experiencing this but that does not have an
NVIDIA card?

Rudd-O <email address hidden> wrote:

> Same problem here. NVIDIA driver, compiz, Fedora 11 RC, . It's not a
> problem with compiz, it's a problem with the X server or the input layer
> (evdev) in the kernel.
>
> --
> Keyboard keys get stuck and repeat (Feisty, Gutsy)
> https://bugs.launchpad.net/bugs/124406
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in GNU Emacs: Invalid
> Status in The Linux Kernel: Confirmed
> Status in “linux” source package in Ubuntu: Incomplete
> Status in “xorg-server” source package in Ubuntu: Invalid
> Status in linux in Ubuntu Jaunty: Incomplete
> Status in xorg-server in Ubuntu Jaunty: Invalid
>
> Bug description:
> Keyboard keys such as the arrows, Alt-F4, PageUp/PageDown, etc.
> often get 'stuck' and continue being 'clicked' even after they are
> physically released. For example when clicking Alt-F4, sometimes it
> gets stuck so all the windows are closed instead of just one.
>
> My configuration is Feisty + Xgl + Compiz Fusion. My previous
> configuration was Edgy + Xgl + Beryl, where this didn't happen.
> Others have reported the same problem without using either Xgl or
> Compiz.
>
> The keyboard itself isn't the problem. When dual-booting to Windows,
> everything works fine. Also, the problem happens with two different
> keyboards (internal laptop, external USB).
>
> My best guess is that the problem occurs at time of high system
> load. Somehow during these times the key-release signal gets lost
> and the key-press is repeated indefinitely. This happens more often
> with Compiz configurations because Compiz tends to increase system
> load. It also happens more often with power-hungry apps like Firefox
> and Acrobat Reader for similar reasons.
>
> PS: When the keys would repeat all input devices would be locked up.
> ie. mouse won't move, clicks don't do anything, keyboard presses
> don't register. Then when it becomes unstuck, the mouse moves around
> and everything. Hope this helps.
>
> See also this forum thread for other people with the same problem:
> http://ubuntuforums.org/showthread.php?t=432057
>
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Marc Jauvin (marc-r4l)]

OK, seems I was wrong as I found many reports with ATI and even INTEL graphic cards having the problem.

[François Rey (fmjrey)]

Actually I have another theory: the bug happens when a low speed usb device is connected on the same hub as a high speed device. That's just a theory, but so far I have connected my mouse and keyboard on the same hub, with no other device on it, and I have not had the problem yet. Crossing my fingers though...

[Rolf Leggewie (r0lf)]

François Rey wrote:
> Actually I have another theory: the bug happens when a low speed usb
> device is connected on the same hub as a high speed device.

I doubt that can be the issue. As far as I know, my Thinkpad X24 only
supports USB1.1. And I experience this problem.

[Rolf Leggewie (r0lf)]

I recompiled kernel git HEAD yesterday and the problem is present there, too. If this is a kernel bug, it is not specific to Ubuntu patches and still unresolved upstream.

[François Rey (fmjrey)]

Rolf,

We all know it's not specific to ubuntu, there's plenty of comments and links in this long thread pointing to the same issue on other distro. However this thread is probably the most active in discussing this issue. I guess that's the price for success ;) and the fact that there are a lot of people having this issue.

Regarding usb speed theory, maybe it's an issue between low and full speed usb (both handled by usb 1.1 while high speed is usb 2.0). So perhaps it would be interesting to test on your x24 various combination of low and full speed usb devices. Bear in mind however that once this bug happens, it seems to be "sticky" meaning there are times it happens even after the mouse/keyboard have been disconnected. So it's best to try each config after a cold boot.

See http://www.mjmwired.net/kernel/Documentation/usb/ehci.txt for info on usb in linux kernel. Interesting part:
Note that USB 2.0 support involves more than just EHCI. It requires other changes to the Linux-USB core APIs, including the hub driver, but those changes haven't needed to really change the basic "usbcore" APIs exposed to USB device drivers.

So it could be that this bug has been introduced since the addition of ehci, and is affecting usb1.1 as a result of the changes made to accomodate ehci.

[François Pernoud (francois-pernoud)]

I'm using a Compaq Presario V6000. I had this problem only with Ubuntu 8.10. I never saw it with previous versions, and it disappeared when I upgraded to 9.04.

[Jason Straight (jason-jeetkunedomaster)]

I added a bug report of my own a while ago, I didn't think with some of the explanations here that my issue was the exact same bug, but its hard to tell with so many people reporting.

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/371066

Anyway if it is related, concerning USB this is what I found.

My laptop keyboard is on the USB bus, and has the problem. However if I plug in an external USB keyboard it works fine.

I've found that depressing 2 keys at the same time doesn't report both most of the time, and will often result in a runaway 'stuck' key. Also if I run xev and do the same xev reports a continuous keypress event with no release when the 'stuck' keys happen.

[Rolf Leggewie (r0lf)]

François,

thank you for your comment.

I guess you have never reported a kernel bug upstream. They will close your report faster than you can blink if you run a distro kernel and not verified that the problem also exists in vanilla. They are very quick to dismiss an issue as possibly being introduced by distro patches. So it is vital to test on vanilla because Ubuntu heavily relies on upstream to fix most of the kernel issues not related to packaging.

As far as USB is concerned, I believe (!) I also see this problem when there are no USB devices plugged in at all. I will need to test. As far as I can see from lsusb, my internal keyboard is not on the USB bus as it seems to be the case for Jason Straight. All devices listed by lsusb are either the internal USB controller or external devices.

[Leann Ogasawara (leannogasawara)]

Having not heard back from the original bug reporter Guy Gur-Ari, I'm going to close this bug as it's growing wildly out of control and hard to follow from a developers point of view. There are comments all over the place indicating this is fixed with Jaunty, while others mention it's a regression with Jaunty, or some say this is an issue on some hardware and not others . . . I really do feel it would be more productive and helpful to the developers to open a new bug report if you are still experiencing an issue. That way the new bug will have specific information to the issue you are experiencing. I do understand that many users are still be experiencing the symptoms reported here and I appreciate everyone's feedback but I think the best way to try to get it resolved it to have a clear concise bug for a developer to look at. It is also difficult to determine if this is a bug in xorg for some or the kernel for others so please use your best judgement about which package to file your new bug against. Thanks in advance.

[François Rey (fmjrey)]

I can understand the messiness of this thread, but this is a messy bug, and that's no reason close it. A developer who wants to work on this bug can find many entry points to start with. For example Rolf Leggewie has show lately an interesting case of this bug on a usb 1.1 machine, and he's experienced in dealing with kernel bugs (unlike me).

Anyway, I've been encouraging kernel developers to look at this bug there:
http://bugzilla.kernel.org/show_bug.cgi?id=11159

I hope this will get the attention it deserves.

[Rolf Leggewie (r0lf)]

François,

again, thank you for your comment.

Please be aware that Leann closed this bug because I suggested to him doing so in IRC. He is absolutely right, the bug has come into such a state that is really impossible to fix. There are several similar, yet different issues that have been lumped together here by now.

This does not mean the underlying issue(s) (one should assume there are many among the ones reported here) will not get fixed, to the contrary. Divide and conquer. Let people report their problems individually until we find the root cause(s). The alternative is a tangled mess and 0 progress. The problems that have the same root cause can then be consolidated as duplicates. But let's keep them separate until then.

If you want help in triaging your particular problem, let me know your LP bug number and I'll take a look. But let's do a proper analysis first without jumping to conclusions. I extend this offer to anyone stricken with this problem. Please file your bugs against ubuntu and not any particular package, then subscribe me.

[Rolf Leggewie (r0lf)]

JFTR

However similar, I don't think that the problem originally seen by Guy Gur-Ari is indeed what we are struggling with these days.

[François Rey (fmjrey)]

Rolf, Leann,

I see your point and understand the need for precision, and I do appreciate the time you're spending on this. Bug 124406 started with something that is probably related to xorg, and quickly got mingled with the usb reset issue, which is what I struggled with until I rearranged my usb connections. I originally posted my report against bug 91230, but when I saw 124406 so active I jumped on the wagon here, not having read in detail its whole history.

I'll have to rearrange a few things in my cabling in order to reproduce the bug on my side. Not to mention the fact that I removed Kubuntu 9.04 and launched myself in installing Arch instead (also because it gives me an opportunity to learn more). So reverting to Kubuntu will hold me back again and I'd like to get going with other things. In other words, I'm not sure I'm the best person to file a new bug, unless you don't mind my arch kernel.

However, instead of another bug report, how about continuing on the one I initially reported against:
https://bugs.launchpad.net/bugs/91230
It's where I initially posted my dmesg, lsusb, lspci, and uname output, other people have done so. That bug specifically talks about resets in the title so there's little chance for confusion. It's not too big either, while still showing the historical aspect across different kernel. So to keep the action going I would continue with 91230 and not wait for a new one.

Whatever happens make a posting here to let us know where to go.

[Rolf Leggewie (r0lf)]

François,

bug 91230 is a report from somebody else again. It's not a good idea to "jump on the most active bug", you need to stay with *the* bug that fits. If you are the slightest bit unsure as to which one that is, open your own bug. You can always mark it as a dupe once everybody fully understands what is going on.

I don't particularly mind you reporting your issue with an arch kernel. I think Launchpad even does support that distribution. But trying out Ubuntu does not necessarily entail reinstallation. Try booting a live CD or live USB. https://wiki.ubuntu.com/LiveCD

Assign me to your bug once you've opened it.

[David Oftedal (rounin)]

I always thought what the original poster was experiencing was the kernel bug over at http://bugzilla.kernel.org/show_bug.cgi?id=9147 , which is now being handled over there.

Then again, the keys that are getting stuck seem to vary between different systems, so who knows.

At any rate, good luck sorting it out to everybody who's still having problems – Perhaps what we really need in the end is one big, dirty hack to just release all the stuck keys.

[François Rey (fmjrey)]

For information, I've just created a new report (bug 383722) regarding usb reset messages and keyboard/mouse unusable.

[legolas558 (legolas558)]

I will say it once again for everybody.
** Procedure to see if you are affected by kernel bug 9147

1) you get stuck keys
2) restart with 'acpi=off' kernel parameter (radical approach) or unload the 'ac,thermal,processor,battery' modules (much better)
3) bug is gone?
4) Yes -> subscribe to bug http://bugzilla.kernel.org/show_bug.cgi?id=9147, No -> you have a different bug

End

[Bernhard Rosenkraenzer (berolinux)]

This has happened twice so far (in about a day of working with xorg 1.6.99.901), both times on the same machine (while 2 other machines running the same software are ok), and both times under fairly heavy load (compiling stuff and playing a video at the same time):

While typing, a key appears to get stuck, just repeating the character over and over, even long after the key has been released; at the same time, new key presses (such as Ctrl+Alt+Backspace) are ignored.

ssh-ing in and restarting the X server fixes it; I doubt it's a hardware problem because this never happens while in text mode.

Xorg-server 1.6.99.901
libXi 1.2.99.4
xf86-input-keyboard 1.3.99.1
linux 2.6.31

The keyboard is a USB Logitech Classic New Touch Keyboard (46d:c315).

[Peter Hutterer (peter-hutterer)]

Pressing the same key that is stuck doesn't help?

[Bernhard Rosenkraenzer (berolinux)]

No, any input from the keyboard (including the same key) is ignored at the point. The mouse keeps working.

Neither Xorg.0.log nor dmesg show anything unusual.

[Bernhard Rosenkraenzer (berolinux)]

The problem appears to be specific to the kbd driver -- I've switched the box showing the problem to the evdev driver this morning and at least so far it hasn't caused any problems.

(My other machines that don't have the problem use the kbd driver as well, so it's probably not a general kbd bug)

[Peter Hutterer (peter-hutterer)]

(In reply to comment #3)
> The problem appears to be specific to the kbd driver -- I've switched the box
> showing the problem to the evdev driver this morning and at least so far it
> hasn't caused any problems.

have you seen the bug in the last 3 days?

[Bernhard Rosenkraenzer (berolinux)]

No, it went away after I switched xorg.conf over to using evdev.

I'll switch back to kbd now to see if it keeps happening there

[Peter Hutterer (peter-hutterer)]

I can sort-of reproduce the issue, the key (very occasionally only) gets stuck, but hitting the stuck key stops it again. I suspect this is a race in the xkb autorepeat code triggered only by the kbd driver.

Either way, since it's not reproducible with evdev and it's hard enough to reproduce with kbd I'm punting it to 1.7.1 instead. This won't hold up the release.

[Chi-Thanh Christopher Nguyen (chithanh)]

From user report, it seems that this happens especially when the system is under load. (The permanent issue from comment 2 not the one from comment 6)

[Cruncher (ubuntu-wkresse)]

http://ajaxxx.livejournal.com/62378.html presents a possible explanation that seems quite relevant, and sounds as if it could be the true source of these keyboard glitches.
It would also explain why nobody experiences the bug in the console tty, only in X.

[legolas558 (legolas558)]

@cruncher: how does that relate to the fact that battery/thermal modules unload seem to "fix" the bug?

[Rolf Leggewie (r0lf)]

@legolas558, you should just acknowledge the fact that although this is a single ticket, it's almost certain that not everybody here is actually suffering from the same bug. So, please stop acting like that was the case.

@cruncher, great find. Thank you.

[legolas558 (legolas558)]

@rolf: indeed I acknowledge that fact, but I am talking to those who have kernel bug 9147, which was also recently suggested to be tied to that SIGIO issue (same URL commented in the relative issue tracker)

[Bugs-freedesktop-org (bugs-freedesktop-org)]

I think this is the same issue that has been lengthily discussed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/269 credibly suggested that http://ajaxxx.livejournal.com/62378.html may have some information as to the root cause of this issue. Please have a look.

[Cruncher (ubuntu-wkresse)]

Timing critical problem and race condition inducing inconsistencies often show many symptoms not directly related to the actual problem. Fighting these symptoms (kernel bug #9147 *might* be one of them) will probably solve the issue for some, for some time, under certain conditions, since you change the timing critical events at some point in the pipeline. But will not fix the true cause of the actual problem.

The aforementioned blog entry explicitly mentions "here is a problem in the event handling of X keyboard events, something got changeed there, since then a certain problem that keys are repeating shows up quite often", which strongly suggests that this might be the actual cause of all these keyboard problems with all these different sideeffects.

[Anders Kaseorg (andersk)]

Adam Jackson has a related kernel commit in 2.6.33-rc5:
http://git.kernel.org/linus/30a589fde0162aa4dac7c69803aeee8fbe8d1b82

commit 30a589fde0162aa4dac7c69803aeee8fbe8d1b82
Author: Adam Jackson <email address hidden>
Date: Tue Jan 5 17:56:04 2010 -0800

    Input: evdev - be less aggressive about sending SIGIO notifies

    When using realtime signals, we'll enqueue one signal for every event.
    This is unfortunate, because (for example) keyboard presses are three
    events: key, msc scancode, and syn. They'll be enqueued fast enough in
    kernel space that all three events will be ready to read by the time
    userspace runs, so the first invocation of the signal handler will read
    all three events, but then the second two invocations still have to run
    to do no work.

    Instead, only send the SIGIO notification on syn events. This is a
    slight abuse of SIGIO semantics, in principle it ought to fire as soon
    as any events are readable. But it matches evdev semantics, which is
    more important since SIGIO is rather vaguely defined to begin with.

    Signed-off-by: Adam Jackson <email address hidden>
    Signed-off-by: Dmitry Torokhov <email address hidden>

[MacRules (macrules)]

I have a similar problem.
It seems this problem has been around for YEARS!
Can somebody please pick this up?
My problem:
On a netbook Mivvy G310 (Viooo Corporation PT17) I have key repeats for at least volume up, volume down, mute and the camera button.
They are all used together with the Fn key.

It seems there is no key-release event, so I tried this solution:
http://ubuntuforums.org/showthread.php?t=974723
which dit not work, see my post:
http://ubuntuforums.org/showpost.php?p=9233246&postcount=66

The web is crawling with these kind of bugs and I can't find a proper solution anywhere!
The netbooks are meant to but Ubuntu on the map as an OS, but because of this bug, they are not production ready!

Please devs, help us fix this, I am willing to put a max of effort in solving this.
I attached a smolt file from Suse with all my sysinfo.
Hope this helps, please let me know if I can do anything to help.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Guy,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 124406

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 124406 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/124406

[Steve Davison (wrongo-cox)]

This problem I encountered when I upgraded from Karmic to Lucid.

As the upgrade was hosed, I tried installing from fresh, rather than using the upgrade, but it too had the same problem, so I had to reinstall Karmic from scratch.

This weekend I tried with the latest stable Lucid (using LiveCD "try before install") and saw the same behavior. I then tried the alpha version of Meerkat (again using the LiveCD), and it too showed the same behavior.

[Cinquero (cinquero)]

Yeah, bug exists over here, too. VERY annoying.

There guys have that problem, too:

http://code.google.com/p/synergy-plus/issues/detail?id=9&colspec=ID%20Stars%20Type%20Status%20Priority%20Milestone%20Owner%20Summary

[Paul Crawford (psc-sat)]

It has become a problem for my computer on changing the hardware from an older P4 based PC to a new i5 quad core CPU with Ubuntu 10.04 32-bit kernel. I am using a PS/2 keyboard & mouse and also getting the random freeze problem (see over 1000 posts here http://ubuntuforums.org/showthread.php?t=1478787) as well as the "key stuck down" problem.

Was using 2.6.32-25 'proposed' kernel, but now trying back to 2.6.32-23 kernel to see if it helps at all.

It is also affecting a colleague with the same hardware and 64-bit 2.6.32-24 kernel.

Why, oh why, is this only "medium" importance? Having a machine go unusable roughly once a day and necessitate a reboot to fix it is simply intolerable!

[The Gavitron (me-gavitron)]

Am seeing this on two distinct (and up-to-date) Lucid LTS installs.

Key 'release' events are getting dropped; at random, a released key will repeat until that exact key is pressed & released again, regardless of other keypresses. only happens under moderate CPU load, (like when playing minecraft or other java games.) machine A is a dual-core AMD X2 1.8Ghz, machine B is an 8-core i7 @2.6Ghz w/ 8GB ram.

can't speak for others, but mine is most certainly related to the SIGIO race: http://ajaxxx.livejournal.com/62378.html/

While the ubuntu maintainers wait for the kernel devs to push a fix, maybe there's a temp fix to be had by disabling the soft key repeats somewhere?

[M Harris (runlevelten)]

I'm seeing this on lucid on one desktop machine and one Dell Inspiron - particularly frustrating as my job entails staying connected at work during office hours. I do not, ever, use or touch the windows key.

Some or all of the following behaviour might be coincidence, but it might contain useful information, or be worth a try for other users. Probably not a good idea for me to try and investigate it now, as it's already stopped me working once today.

Quite often I will be typing quickly and will lock the desktop before I realise it's happened. Restarting X precipitously is hugely undesirable for my work.

My current workaround is to ctrl-alt F$whatever and try to login, but unfortunately that breaks sporadically too and I end up typing ^[l^[o^[g^[i^[n and presumably ^[p^[a^[s^[s^[w^[o^[r^[d.

If I'm able to log in before I run out of ttys, the problem tends to go away for a while.

Plugging in a USB keyboard has no effect on the problem.

[Thiago Teixeira (tvst)]

I am also seeing this bug, using the latest kernel from the latest Ubuntu (Kernel: 2.6.35-24-generic, Ubuntu: 10.10).

Does anyone know a fix for this, even if it's just a temporary hack?

[Grant Bowman (grantbow)]

This bug effects some people more than others leading to difficulty replicating the problem. For those it does effect it's quite frustrating.

The http://bugs.freedesktop.org/show_bug.cgi?id=23938 bug linked from above has a comment at the end that links to this description of the core problem that might be relevant. http://ajaxxx.livejournal.com/62378.html

I hope the right people can act on this.

[Navet Cph (ewan-2210)]

I am having the same key - repeated - stucked problem with Ubuntu 10.10, Kernel 2.6.35-24-generic.
Dell Inspiron 6400 and Microsoft Multimedia Keyboard 1.0A.
Very frustrating problem that seems to happen under moderate CPU load, Matlab - Acroread - Firefox
Hoping for a fix soon.

[Bryce Harrington (bryce)]

I'm dropping the 'natty' tag added by Marius since to accept this bug against the development release we need the info I asked for in a previous comment.

The bug has been forwarded upstream and upstream developers are aware of it, and since it's a minor annoyance (rather than an X lockup or crash), it's not top priority for us for the release. I think there is not anything particular we would do about this issue for natty.

Also, from re-reading the comments on this and the upstream bug, it sounds like there may be a couple or more different variants on the "keyboard gets stuck" issue, which unfortunately are all gathered on this bug report due to it having kind of a general purpose topic. So, if people do want to see progress on this bug it might be better to file *new* bugs and be very specific about the issue (with exact steps to reproduce, up to date logs, etc.)

[xrayA4T (xraya4t)]

Bryce, this is more than a minor annoyance. If I need to switch to a terminal (Ctrl-Alt-F2) because my X has locked up, it is almost impossible to login because when you enter your password there is no way to tell if a key has been repeated and so I keep entering invalid passwords.

Should I be raising my issue as a different bug as this is too general?

Thanks
Raymond

[Marius B. Kotsbak (mariusko)]

xrayA4T: japp I have also experienced that. And since it happens more frequently when the CPU load is high, in that case of X lock up it is more likely to happen. Have you seen my latests comments on the kernel bug. Do you use the same module for keyboard and do you have an Atom CPU (I have only seen it on my Atom based CPUs).

[Marius B. Kotsbak (mariusko)]

Opened bug #769103 for my Gigabyte laptop for Natty.

[Marius B. Kotsbak (mariusko)]

xrayA4T: the bug in X and in a pure console is a bit different, inside X it tyically makes you write:
"thiiiiiiis issssssssss a teeeeeeeeeeeeeeeeest" stopping only when hitting a new key, but in console more like:

"thiiss iss aa teessst" stopping at releasing of the key, possibly just because of too short delay before the repeating starts.

[xrayA4T (xraya4t)]

Hi Marius, I'm definitely getting the missed key up, as in your first example, the last typed key will sporadically repeat indefinitely until another key is pressed. So it is a lower level error that is giving the same behaviour a the x error but in terminals too.if this its the case should I be raising a different big and how many people who are reporting the x error have this error?

[Marius B. Kotsbak (mariusko)]

xrayA4T: the question is if the key stops repeating when releasing the stuck key, that I claim is the case in pure terminal, and it seems you have the same Gigabyte laptop as me, so you probably see the same.

Because of this different behavior inside and outside X, I suggest that you can open a separate bug for the console issue (like my bug #769103). I also think there are several related kernel bugs since some claim it worked in an earlier kernel version, but I have verified that this is not the case for my laptop.

[james_mcl (james-d-mclaughlin-googlemail)]

This is a two-part reply to Bryce Harrington's comment #294.

1.) I really have to take issue with your statement that "it's a minor annoyance (rather than an X lockup or crash)". When the key that gets stuck is "Delete", for instance, this has the potential to wipe out entire directories, and the consequences when the key in question is Enter are utterly unpredictable. Furthermore, for instances of the bug when subsequent key presses/releases are ignored and the key remains stuck, the result - a reboot and loss of unsaved data - is preceisely what would occur if X locked up or crashed.

2.) You ask people "to file *new* bugs and be very specific about the issue (with exact steps to reproduce, up to date logs, etc.)". Would it be sufficient to run

ubuntu-bug xorg

referencing bug 124406, and then

apport-collect (number of new bug)

or is there any more information you would need that would not be supplied by this? (if so, please specify what this would be.)

Thanks,

James McLaughlin.

[Daniel Jost (dnl-jst)]

I agree with your #1. My delete-key got stuck when deleting an e-mail in thunderbird and it deleted me over 400 e-mails. thank god that there is a trash folder, but at first i was really shocked.

Daniel

[Marius B. Kotsbak (mariusko)]

I guess the problem is that there are more than one symptoms contained in this bug and probably more than one bug in possibly xorg and the kernel. The best would probably be to have one bug open for each, but getting users to respect that is problably hard and maybe we don't even know.

Anyway I want to get this solved. First I want to know if it is a kernel or xorg bug for me and then try to ask the right people/mailinglists for advices. Digging at the kernel code, I suspect it might be caused by the interrupt handler for the keyboard to take too long to finish and while it works no new key releases can be handled.

[Daniel Jost (dnl-jst)]

Yes, you're right, my bug maybe a bit different due to my mouse and keyboard keeps responding. I can press any key and the key that got stuck is released.

[Marius B. Kotsbak (mariusko)]

Japp, that is the same I see, but the freedesktop describe it as you need to restart X server to stop it. And some see the bug using USB keyboard too, but for me only with the integrated keyboard. And for some the problem is a regression. Which makes me beleve our problem is caused by the AT keyboard driver in the kernel.

[Daniel Jost (dnl-jst)]

I've never tried with a external keyboard. I will try it and post the results in my open bug. Otherwise it could get a bit crowded here with comments.

[james_mcl (james-d-mclaughlin-googlemail)]

Daniel - where you say that you can press any key to release the stuck one - over the years the bug's behaviour has varied, in some versions of Ubuntu I've been able to stop the repeting keypress by pressing another key, in others not. At the moment I usually seem to be able to stop it by pressing another key several times until it's recognised - so I THINK that the bug has at least become less severe at some point between Intrepid and Maverick.

Like Marius says, it is true that nobody knows how many underlying bugs are causing this and where they lie - I should have asked Bryce what to file this as a bug in; however going by his comment #285 I assumed xorg.

Daniel, could you specify whether your external keyboard is PS/2, USB, or something else? Somebody on Ubuntu Forums directed me to a discussion thread where users of high-end Windows machines were experiencing it on PS/2 keyboards - one person blaming this on their having hardware running faster than PS/2 was designed for. Probably not an accurate description of most people's situation, but it does suggest that knowing the type of any external keyboard tried might be relevant.

I'll be installing Natty today, so either today or tomorrow I should be able to say whether that fixed it for me or not.

[Vasil Kolev (vasil-ludost)]

I can vouch that this isn't hardware related. I have two machines, one laptop that has an AT keyboard and another which uses USB, and I see the problem on both. Sometimes I see the same issue on the laptop with the mouse - the cursor sleeps for a second and then moves where it should've gone.

[Daniel Jost (dnl-jst)]

As I said i never tested the behaviour with a external keyboard. I normally use the integrated keyboard of my thinkpad t400. A few hours ago I upgraded to natty and attached a external keyboard and up to now the error didn't happen again. I will now work again with the integrated keyboard and post my results here.

[Bryce Harrington (bryce)]

Heh, I see my comment about this being a minor annoyance got people in a huff. ;-)

Anyway, as to whether it's a kernel or X problem, it's sort of a bit of both. (The best bugs live in the cracks between two codebases.) X and the kernel communicate key events as signals rather than via threading. And it only handles one signal at a time, so if for some reason the key up signal was fired while another signal was being handled (e.g. from another device in your system) then it can get lost. That's why hitting a key a second time (to fire a new up-key signal) makes things work. The way signals behave is a kernel thing, so this is why it's partly kernel, partly X. Essentially it's a race condition. For deeper information see http://ajaxxx.livejournal.com/62378.html

Really, it sounds like it's an upstream design flaw in X. Ajax appears to be thinking that the whole system should be ripped out and replaced with a threading system. My own experience with threading is that sometimes the cure can be worse than the disease... threading can be quite hard to get right and sometimes has nasty side effects. Needless to say, such a change is not trivial and not something we'd do at the Ubuntu distro level - definitely work that needs done upstream. Maybe Wayland will gain a better system for handling keyboard events, and that's where efforts today should be directed? Don't know.

As an aside, you guys are right that there could conceivably be some rare scenarios where this bug could cause some severe issue like a stuck delete key deleting files or whatnot. Maybe some of you have even experienced something like that. But for the vast majority of cases, the issue will exhibit itself as extraneous characters when you're typing documents and some such - definitely a lot less severe than random GPU lockups or sudden X crashes back to the login screen or your monitor suddenly turning tie died. These latter issues are unfortunately not as uncommon as I'd like, and until they are I tend to judge anything less severe as a "minor annoyance". ;-)

But annoyances are bad. While I don't think this issue is one we're likely to work on in Ubuntu at the distro level, I can give some advice about how to go forward with it, if you're wanting to pursue it yourself. (And FSM bless you!)

Due to the nature of the issue, it's frequency and severity are going to vary from hardware to hardware. Due to timings in hardware interrupts and signal generation, and even interactions with software, you might see it only with a particular combination of keyboard, motherboard, and mouse. Or it might go away after turning off your wireless. Or might go away for 3 Ubuntu releases and then suddenly and quite mysteriously reappear. Most of our typical keyboard debugging tools such as xev are going to be of limited value in investigating it; it may tell you that the release signal didn't show up, but that doesn't explain why. There are kernel debugging interfaces that will show what's going on there, but that gives limited insights as well.

The first thing I would look at is obtaining a reliable repetitive test case. Get together hardware and a set of steps ...

[Bryce Harrington (bryce)]

I'm setting the X task to wishlist, since it looks to me like a true fix to this general problem will require architectural reworking in X, as per my previous post.

[Bryce Harrington (bryce)]

While I may think this is a "minor annoyance", the solution is anything but, and as such it's not really a paper-cut scale problem.

[Bryce Harrington (bryce)]

Regarding splitting the bug reports up rather than having this one gargantuan 300+-post bug...

I do typically prefer having separate bug reports per person/machine, as having to read through hundreds of comments is akin to having to read a car manual just to change a flat tire... :-) These long thread bugs also tend to accumulate people with similar-but-not-the-same bug, so that adds confusion and also makes it less likely that we can get *all* the problems solved (and makes it hard to verify fixes).

However, in this case, the general underlying issue is the X.org input handling design implementation, and I'm not sure having it broken up into separate bug reports will necessarily help. Ultimately, the work to solve the general issue needs done upstream, and I think this bug report and its upstream linkages is sufficient. So, I'll leave it open so people can share workarounds and commiserate over it being relegated to wishlist status and so on. (However, note that we're going to have a session at the upcoming UDS to discuss xserver wishlist bugs, so ironically setting it to wishlist should give it a bit more visibility this time around).

The one situation where I *would* like to see separate bug reports on this issue is where you are encountering severe, repetitive problems. I.e., the keyboard goes crazy daily, or you have a set of steps that reproduces the problem more than half of the time. I'd like to handle these individually because they are almost certainly HW-specific oddities and there may be things we can do to work around the issue or paper it over. But be very clear in your description, and make sure to include full debugging info and detail all the work you've done to diagnose it. We may end up duping the bug reports back here, but I think this will make it easier for us to handle the severe exceptional cases.

[Marius B. Kotsbak (mariusko)]

Bryce, thanks for your insight into this. While starting to investigate this problem, I made a very interesting discovery and possibly solved the issue (at least drastically reduced the severity of it) for my laptop:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/769103/comments/26

Nice if other people struggeling with this can test this too.

[Marius B. Kotsbak (mariusko)]

Regarding the bug severity, I can only agree on that given that we have the workaround of disabling keyboard repeat in the X server settings. Without that, depending on the frequency it happens, it can make the PC almost unusable or at least too unpredictable to trust, i.e. you always risk, like when I am writing in this text field to loose all when I am correcting one typo if I don't react in time, close all tabs in the browser when typing ctrl-w (since this shortcut starts CPU load, the bug occurence actually increase at exactly that time, as with tab completion in terminal).

[Mircea Deaconu (mirceade)]

What I don't really understand in the whole threading vs. signals
discussion is why the kernel cannot buffer in a queue of some sort
those signals before processing them. They wouldn't be lost anymore
and the kernel could process them at its own pace.

2011/4/29 Marius Kotsbak <email address hidden>:
> Regarding the bug severity, I can only agree on that given that we have
> the workaround of disabling keyboard repeat in the X server settings.
> Without that, depending on the frequency it happens, it can make the PC
> almost unusable or at least too unpredictable to trust, i.e. you always
> risk, like when I am writing in this text field to loose all when I am
> correcting one typo if I don't react in time, close all tabs in the
> browser when typing ctrl-w (since this shortcut starts CPU load, the bug
> occurence actually increase at exactly that time, as with tab completion
> in terminal).
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/124406
>
> Title:
>  Keyboard keys get stuck and repeat
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/emacs/+bug/124406/+subscribe
>

[james_mcl (james-d-mclaughlin-googlemail)]

In answer to post 310, Bryce, I'm sorry but there's a serious misunderstanding of the issue in your post.

You state "hitting a key a second time (to fire a new up-key signal) makes things work."

This is not the case for everyone affected, or for every instance of the bug. The original poster, and post 121, refer to subsequent keypresses and their keydown events being ignored completely by the system. Post 40 mentions the need to "furiously" press another key several times to get the system to recognise it and stop the repeats.

In my case, the behaviour of the bug has varied as I've gone through different distros; possibly not behaving consistently even in identical distros (since my workaround for the past two-and-a-half years has been to go back to Hardy Heron, this hasn't really been put to the test.)

[Marius B. Kotsbak (mariusko)]

james_mcl: find/open a separate bug for your particular hardware then.

[james_mcl (james-d-mclaughlin-googlemail)]

Okay... that last point needed a comment of its own - now to look at the other issues raised.

1.) "Touch base about this with Ajax to find if he has any experimental branches, or if he knows if anyone else is working on the problem, and how you can help." - It never occurred to me that any experimental threaded branches might exist! I'll be in touch with him, thanks for that.
(Though, given the bug's intermittency, I don't think anyone's going to have a reliable, repetitive test case as described - it'll be a matter of seeing if intervals of x days pass without the symptom recurring.)

2.) "Maybe Wayland will gain a better system for handling keyboard events" - Bryce, can you possibly supply the name of any particular dev who would be in a position to know whether keyboard events in Wayland are being handled in a similar way to X? The possibility that this bug might survive all the way into X's successor is quite a horrific one!

3.) For other people who, like me, are trying Marius's workaround - you should know that he had to file another bug, in that changing the keyboard delay setting in /etc/kbd/config had no effect (meaning, presumably, that he had to change it in the terminal every time he booted up.)

(Actually, I'm noticing it seems to have created a new bug in my case - pressing Enter once seems to be interpreted as pressing Enter several times on some occasions - although the key repeat stops by itself in less than a second.)

4.) Regarding post 313 - well, my keyboard certainly goes crazy daily, although I think this is probably true for most of us here. So I guess I might have a "HW-specific oddity", though not one affecting my Hardy partition.

So, to repeat my question in post 301, to file a new bug:

"Would it be sufficient to run

ubuntu-bug xorg

referencing bug 124406, and then

apport-collect (number of new bug)

or is there any more information you would need that would not be supplied by this? (if so, please specify what this would be.)"

5.) In response to Post 310's assertions regarding the severity of the bug:

"there could conceivably be some rare scenarios where this bug could cause some severe issue like a stuck delete key deleting files or whatnot"

When the issue happens at least once daily, the question is not so much whether this could be rare as how many days/weeks/months the user has before it happens - which eventually it must.

And, for versions of the bug in which pressing another key doesn't stop the repeating, it is *at least* as significant as the X crash/tie-dyed monitor, as the only way to resolve the issue is to hold down the Power button.

6.) Thanks for your help Bryce!

[james_mcl (james-d-mclaughlin-googlemail)]

Well, I've just been in touch with Ajax.

I asked if he knew about any experimental thread-based branches:

"There's http://cgit.freedesktop.org/~ajax/xserver/log/?h=input-thread-v3 , which I haven't touched
in months. It's assuredly broken if you poke it hard enough."

I also asked if Wayland would also be using the same signals-based architecture that had caused all this:

"Wayland doesn't have any SIGIO code."

[Marius B. Kotsbak (mariusko)]

Bug #770680 has an interesting patch. Not sure if that solves more than problems with volume keys.

[Bryce Harrington (bryce)]

@James, aha, as I suspected. Thanks for checking that. Those interested in seeing development towards a fix for this issue can focus on that branch.

[Bryce Harrington (bryce)]

As I mentioned earlier, this was on the agenda for the xserver wishlist bugs session at UDS, and was discussed yesterday. From reviewing the current status of the bug here and upstream, there seems to be a legitimate issue in general, however the general fix for this (e.g. Ajax's branch) are not things we would want to risk pulling in as a backport, nor something of high enough importance for the ubuntu x team to invest time into, so for these reasons we're closing the issue as a wontfix at this time.

However, we are concerned about the cases where specific hardware is significantly broken (as several have described in recent comments). But these issues are difficult to analyze and work on within the context of this particular bug report. For users with issues that need deeper investigation, please file a NEW bug using this command:

  $ ubuntu-bug xorg

It would be helpful if you can reference bug 124406, and include the word 'keyboard' in the title so it gets autofiled predictably.

[james_mcl (james-d-mclaughlin-googlemail)]

Thanks Bryce,

I did end up replacing the laptop, and it will be a little while before I have access to the affected machine again (it now resides in the attic at my parents' house!); however I'll be sure to file a bug report as soon as I get there.

[Dan Quade (danquade)]

IIIIIIIIIII've found a way to reproduce this bug on my laptop.

***** Do a LEFT MOUSE CLICK and a PRESS A KEY at the same time. *****

Works almost every time.

Result: tttttttttteeeeeeeeeesssssssssssssttttttttttt

[Dan Quade (danquade)]

PS: It only works on the integrated touchpad mouse though. Does not happen with a USB mouse.

[Bryce Harrington (bryce)]

On Mon, May 23, 2011 at 02:02:21PM -0000, unimatrix wrote:
> PS: It only works on the integrated touchpad mouse though. Does not
> happen with a USB mouse.

File a new bug report.

[ticket (tickettothemoon2004)]

Had this problem with Ubuntu 10.04 and 10.1.
Suspend can get you out of the key repeat, rather than reboot.

Very intermittent. A week can go by without seeing it, sometimes.
Makes internet mail order a bit scary.

Today, I was deleting some files and the del key started to repeat.
luckily the files were on a USB device ....

ASUS P7P55D EVO m/b
Dell 105 keyboard (not USB)

[PabloRQ (pablo-romeroquinteros)]

Same problem on 10.10. Then updated to 11.04 and the bug still happens.

Affect randomly and keys starts to repeat. No chance to go to terminal (ctrl+alt+fx). The system became inusable and almost freeze. Mouse works most of the times, and then allows to do a software reset. If the mouse doesn't work then the only way is a hardware reset.

Affects users with and without compiz (in 10.10) and with Unity and gnome (in 11.04).

Hardware details: PS2 keyword, and usb mouse.

[Marius B. Kotsbak (mariusko)]

Parq:please open a separate bug report for your particular laptop/motherboard.

[Marius B. Kotsbak (mariusko)]

I guess Canonical should exclude their own bugmails from their vacation message service....

[new4u (new4u)]

To me, this happens as well, using Lucid Lynx 64 bit. Even if the PS/2-keyboard is unplugged, the key which decided to get stuck keeps repeating.

What I would like to point out:

It only happens when tpying in forms displayed of Firefox (so NOT during any other application of Ubuntu), and then there on certain forms: when trying to write an email in Outlook 2010 webmail, or when writing a comment on the launchpad page, the key repeating error almost reroducably happens.(This is why I needed to write this mail in Gedit and copy it conscutively into launchpad).

On the contrary, it does e.g. not happen in GMail - so maybe there is an interference between some applications and firefox and Ubuntu.

Despite I turned off the repetition in the preferences -> Keyboard settings -> General -> Repeat keystrokes when being pressed, the keyboard keeps stuck in the Firefox forms as mentioned above.

My Hardware:

Asus P7P55D
Intel i5 750
8GB RAM
ATI HD 4600
SATA-HDDs
USB-Logitech Mouse
PS/2 Fujitsu Siemens Keyboard
Xonard D2X Soundcard
Pinnacle PCI TV Card

[PabloRQ (pablo-romeroquinteros)]

@Marius,
I'm gueesing about a motherboard issue. I'm going to change it an try.

[Moritz Winter (winter-moritz)]

Im still experiencing this in 11.10 and removing gnome-applet-sensors or the unity counterpart (see comment #151) works for me.

[Moritz Winter (winter-moritz)]

^^ Sorry, its comment #157

[Wojciech Musial (wmusial)]

I also experienced the exact symptoms of the bug, combined with a bunch of other problems (sound crackling, system freezes).

This workaround fixed it all together for me (ubuntu 10.04, 2.6.32-36-generic):
http://jannepikkarainen.fi/clocksourcejiffies-ja-ubuntu-910-hidastumiset-pois

Quote:
---
 in /etc/default/grub change line

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to be

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash clocksource=jiffies"

Then enter sudo update-grub and reboot. See if your problems are gone.
---

Unfortunately that triggered another bug: hd-audio0 eats up 20% of my cpu, but that's another story.

[Cinquero (cinquero)]

Ubuntu Precise yesterday showed similar symptoms: numlock LED was insanely blinking, at times no keyboard input was possible on two of three connected keyboards, and additionally, the mouse cursor was being dragged down.

Maybe this is related to:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/935912
https://bugs.freedesktop.org/show_bug.cgi?id=46281

??

[new4u (new4u)]

It is still in 12.10. :(

[essl (essl-main)]

Hmmm... Just noticed that I don't have it anymore...

Dell XPS 17
openSuSE 12.2
Linux xps 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux
KDE Platform Version 4.8.5 (4.8.5) "release 2"
X.Org X Server 1.12.3

[Daniel J Blueman (watchmaker)]

I've been observing this happen once a week across a wide range of x86 systems with USB keyboards in the last (5?) years.

Since I've observed it in the virtual terminal and have never observed this with PS/2 keyboards, I suspect there is an event race condition in the USB input stack, eg a missing write barrier.

When I increase system latency, it looks like there's more chance of it happening, so this feels like MMIO write ordering causing a lost key up event.

[new4u (new4u)]

In 13.04 (beta) 64bit it occurs more frequently again than I noticed it in 12.10. This last time it even occured in a Win7-guest in Virtualbox.

Almost same hardware as before, just graphics & soundcard changed.

My Hardware:
Asus P7P55D
Intel i5 750
8GB RAM
ATI HD 7850
SATA-HDDs
USB-Logitech Mouse
PS/2 Fujitsu Siemens Keyboard
Xonard STX Soundcard
Pinnacle PCI TV Card

[Mahdi Dibaiee (mahdidibaie)]

I feel the same as new4u, I have the problem in 13.04 beta more than ever, even after I disabled key press repeat in Prefrences -> Keyboard, I have this problem.

I used `xset r off` right now, gonna see if key repeat occurs or not.

P.S: Sorry for my bad English.

[new4u (new4u)]

Dear developers, I really would like to stress this issue. Only tonight I had to reboot my machine 3 times due to this issue. It is a MAJOR impediment in working. The key-stucks happened in gedit, and Gummi tonight. So it seems not attached to a specific application.

Despite I am not able to develop or program, I see myself as a kind of evangelist, who converted a lot of people to Ubuntu. But, honestly, it is a problem for continue recommending it of having basics such as a keyboard causing problems. I have never seen this on any other distribution.

So, please, please have a look at this issue, as I guess that many people might use Asus and Ubuntu 64bit (as it combination seems to correlate somehow).

Thank you for your time making Ubuntu that great - that also needs to be said.

[Rizwan (rizwanenstien)]

I feel the same as new4u, I have been having this keyboard problem and its really irritating. I use ubuntu as my main development machine. I left the mac cause I loved working on this, but with this problem, I guess I will go back. I have an i5 Asus machine running Ubuntu 13.04. I have upgraded my Kernel to run 3.9.0 but the problem persists.

[Peter M (pmoss)]

Just chiming in to say that this bug affects me too. Asus K55n laptop with Ubuntu 13.04. It randomly acts like sticky keys are enabled. A minute ago I hit ctrl and it acted as if I was holding ctrl until I logged out. Extremely annoying!

[Artyom Kazak (artyom-kazak)]

I’ve never experienced this problem on 13.04, but strangely enough, it happens very often to me with 13.10. Laptop’s keyboard works fine, but Bluetooth one stutters every now and then.

[Hồng Quân (ng-hong-quan)]

Yes, me too, Ubuntu 13.10 :'(

[Hồng Quân (ng-hong-quan)]

Another workaround for me is to login to text console (not graphical UI) and remove all settings in home folder.

[new4u (new4u)]

Update for 14.04 beta 64 bit: The same error still also in this version... I think this error, which really impedes productivity, will be turning me away from Ubuntu. :(

[new4u (new4u)]

Dear all, just wanted to add: Also in 14.04 64bit the error is present, multiple times a day.

[new4u (new4u)]

Dear developers, maybe a information that helps localize the error: It is intermittent, and obviously related to a very few packages. The last days, it did not occur, and now since I updated (from 13th to 14th of May 2014) from the sources trusty-security, -updates, -proposed and -backports, the error appears twice an hour. Maybe you could have a look at these packages, as they seem to influence the behaviour.

[Vyacheslav (sl-s)]

also found this bug (keyboard imitates of pressing '1', '2', '3' and Enter) after installing of fresh copy of ubuntu 14.04 stable x64 server and when installing xorg and kubuntu-desktop meta package
also found this bug after installing of fresh copy of ubuntu 12.04.4 stable x64 server and when installing xorg and kubuntu-desktop meta package, but more rarely when in 14.04
my keyboard is physically well (dual-booting into Windows on this machine shows no problems), this bug exists if I change the keyboard to another.
If I reboot the computer and never click a button on keyboard (but work with it through RealVNC server and viewer - press any buttons on keyboard at other computer and VNC viewer sends it to server) - the bug appears again
The bug also appears sometimes after some hoгs of user inactivity (VNC viewers also disconnected for some hours)

[Vyacheslav (slavoon2)]

also found this bug after installing (at the middle of June 2014) fresh copy of ubuntu-14.04-beta2-server-amd64.iso AND NOTHING ELSE! (no KDE, Gnome etc.) predominantly arbitrarily keys presses digit '1', digit '2', digit '3', left and right arrows and Enter. My Ubuntu is installed at sda7 of hard disk, sda1 is partition for Win XP (then I boot in Windows, no any bugs with keyboard!), grub installed into sda Master Block Record), I selected Russian language before installin server, and updates are downloading during install, software sources enabled: main, universe, restricted, multiverse, download server is Main server (not local for Russian Federation), other software sources: Canonical partners, Canonical partners (source code), Independent, Independent (source code), Important security updates, Recommended updates, Pre-released updates, Unsupported updates, Release upgrade: long term support releases only.
my configuration is Asus P5G41T-M LX motherboard (northbridge Intel G41, southbridge Intel ICH7) with Pentium Dual-core CPU E5700 @ 3.00 GHz, 4 Gb dual-channel memory. Removing the keyboard physically from PS/2 socket does not solve the problem.
Also I installed fresh copy of ubuntu-14.04-beta2-server-amd64.iso and selected English and also found this bug (after KDE (kubuntu-desktop package) installed or before I install KDE, I don't remember), also found this bug after installing fresh copy of ubuntu-12.04.4-server-amd64.iso (with Russian selected) and kubuntu-desktop package (I am not sure if this bug will not appear after installing fresh copy of ubuntu-12.04.4-server-amd64.iso without KDE), but in 12.04.4 this bug appears more rarely then in 14.04. This bug appears more often when I use RealVNC or TeamViewer and remotely control my computer (in KDE enviromnent).

[Vyacheslav (slavoon2)]

in my situation - keyboard imitated of clicking '1', '2', '3' etc. even if I didn't work on keyboard and mouse for 30 min to several hours. The symbols that were stucked (imitated) didn't repet the symbols I manually typed before. The bug appeared more often when RealVNC server or TeamViewer server worked (and I typed symbols and moved mouse remotely - and VNC server or TeamViewer server received this symbols and mouse movements). Every time then bug began - it repeated from 1 to some hundreds of same symbols - and I every time can stop the bug by pressing any key phisically in keyboard or remotely via VNC server or TeamViewer server (but after such a stopping the bug - it could be begin again after period from 0.5 seconds to some hours).
THE PROBLEM SOLVED in my situation by phisically removing the USB device called 'SkypeMate' (USB-B2K model) (this device connects Skype software on desktop via USB with wire connected to standard office phone device to make calls via it).

[Vyacheslav (slavoon2)]

thank you all for help! as I already understood - in this topic users reports about DIFFERENT bugs (but the same sympthoms) - if you are lazy to read this topic above:
1) if your dmesg log contains USB errors ('reset low speed USB device' or other) - try to physically unplug USB devices (mayby onboard keyboards in notebooks seen as like USB devices in some situations?) or re-plug to ANOTHER USB controller; try to use USB keyboard (another keyboard); try to disable legacy USB support in BIOS. This is kernel problem.
2) if your dmesg log contains non-USB errors ('Unknown key released' or something else) -
try to change the BIOS setting 'Plug and play OS' to it's default state ('No');
try to disable WiFi adapter;
try to disable OpenGl in KDE, Gnome, ... ;
try to set atkbd.softrepeat=1 parameter to the kernel boot parameters in Grub;
try to unload the battery, AC and thermal modules of kernel after booting;
try to set acpi=off parameter to the kernel boot parameters in Grub;
try to disable legacy USB support in BIOS;
try to execute xset r rate 1000 50 command;
try to set in BIOS do not check if PCI-express videocard not installed search for PCI video card, if not - try to initialize internal video card - instead of it set BIOS to initialize your existing video card first;
try to disable auto-repeat keys in keyboard in KDE or Gnome settings;
try to switch to another kernel;
try to execute xmodmap /usr/share/xmodmap/xmodmap.us-101 each time the bug occurs;
try to set highres=off nohz=off noapm parameters to the kernel boot parameters in Grub;
try to remove gnome-sensors-applet , lm_sensors , net-snmp-libs , hplip , hpijs , net-snmp packages or packages with same functionality;
try to edit /etc/mkinitcpio.conf and remove the word 'keyboard' from line HOOKS="... ;
try to remove gnome-accessibility-themes , gnome-accessibility-themes-extras accessibility packages or packages with same functionality;
try to remove hotkeys-setup package or package with same functionality;
try to report at bugs.launchpad.net and ubuntuforums.org about this bug (include your list of hardware (lspci command) and Linux version (uname -a command) and dmesg log)
This is a kernel problem also.
useful links (are already listed above in this thread):
http://bugzilla.kernel.org/show_bug.cgi?id=9147
http://bugzilla.kernel.org/show_bug.cgi?id=9448
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/39315
http://bugzilla.kernel.org/show_bug.cgi?id=12021

[Abhirav Kumar (akabhirav)]

I have a lead may be
Given scenario I have my keyboard stuck (i.e. I can't do andything with my keyboard)
I suspend my laptop using mouse and voilà my keyboard is working again
Hope this helps!!!

[Mehmet Soyturk (mehmet-yavuz-selim)]

(Note: I intentionally don't fix repeated characters cccaaaaauuuusssssseeeeeedddd by that issue in my message below)

I'm affected by ttthhheeeeee sssssssame issue.

Initially I have installed Ubuntu 16.04.4 LTS. While installing it, I had to add ttttthe boot parameter "acpi=off" in grub settings (both for the installer andd for booting of the installed OS). Otherwise, I got a freeze on boot.

AAAAaafter installation, I got this probleeemmmm. But next to issues with repeated keys, I got temporary freezes in firefox. I see that sometimes the caret is applicaatioooooonsssss flickers too fast (and that is when I get repeated characters). And other strange issues.

I opened a clock application in https://www.online-stopwatch.com/online-clock/ and I saw that the speed offf the "seconds" needle is not regular, and it sometimes moves backwardssss bbbyyyy 10 to 15 seconds. There is really something wrong with system time.

Then I have upgraded to Ubuntu 17.10, but it was the same (but I got additional issues because of the upgrade :( ).

And the solution was the one from comment #356 from this thread ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/356 ), which adds a "clocksource=jiffies" boot option.

I'm not done yet. Now I have a hang on Ubuntu shutdown ( https://askubuntu.com/questions/764568/ubuntu-16-04-hangs-on-shutdown-restart ), and the suggested solution there is ... forcing acpi in boot options :(

I have no idea whether this issue is related my acpi issues.

[Mehmet Soyturk (mehmet-yavuz-selim)]

I'm not sure whether it gives any information, but here is some output from journalctl, where the bug happens (no "clocksource=jiffies" boot option is used):

$ journalctl -k | grep clocksource

clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
clocksource: Switched to clocksource refined-jiffies
clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2879c5f06f2, max_idle_ns: 440795220049 ns
clocksource: Switched to clocksource tsc
clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
clocksource: 'refined-jiffies' wd_now: fffedcd0 wd_last: fffedc58 mask: ffffffff
clocksource: 'tsc' cs_now: 13ccf176fe cs_last: 13299ba17d mask: ffffffffffffffff
kernel: tsc: Marking TSC unstable due to clocksource watchdog
kernel: clocksource: Switched to clocksource refined-jiffies

[Mehmet Soyturk (mehmet-yavuz-selim)]

WWWWWWwwwwweeeeeeelllllllllllll, IIIii bbbbbooooooooooottteeeeeeedddddddddd aaaaaaaggggggaaaaaaiiinnnnn wwwwiiiiitttthhhhh clocksource=jiffies,,, aaaaaaannnnnndddddd ttthhheeeeee iiiiisssssssssssssuuuueeeee ggggggottttt mmmmuuuuuuuccchhhh wwwwwooooorrsssssseeee tttttthhhhiiiiiiis tttttiimmmmeeeeee....

SSSSssooo clocksource=jiffies ddddddooeeeees nnnnoooooottttt ssssseeeeeeeeeeeemmmmmmm tttttooooo bbbbbeeee aaaaa ddddddeeeeeffffffiiiiiinnnniiitttttttiiiivvveeeee sssssoolllluuuuutttiiooooooonnnn....

[Mehmet Soyturk (mehmet-yavuz-selim)]

I'm sorry for flooding this thread, but I have more experience to share.

After another reboot in "clocksource=jiffies" mode, I saw that 1 OS second passes in real 0.5 seconds. But the rest of the system was pretty stable. Keyboard auto-repeat was twice as fast, but did not get triggered inadvertently.

I did another reboot in "clocksource=jiffies" mode and opened the online clock application. Initially the clock speed seemed normal. After 20-30 seconds it became twice as fast.
Then from the console, I started an application with an infinite loop therein. That made the clock seconds turn very very fast. Probably CPU speed has influence here.

Good news is that when I changed the boot option to "clocksource=tsc", I got stable results even after a few reboots. Seconds seem to pass as fast as they should be.

[Felipe Butcher (felipebutcher)]

wow! see this was opened in 2007. just googled this from the future (i am in 2018) and found this.

using ubuntu 18. found that what was causing it in my case was a clipboard manager i use here. closing the clipboard manager stopped the bleeding.

[vak (khamenya)]

The bug is still here in Ubuntu 18.04.1 on Lenovo IdeaPad Yoga 13
(last available BIOS for my model is installed)

[Serge Stroobandt (serge-stroobandt)]

It is notable to see so much Fujitsu Siemens hardware affected.
I have the same issue with the onboard USB 2.0 of a Fujitsu Siemens P710 E90+ Intel i5 3470 desktop computer.

The problem occurs with any of my Varmilo VA88M keyboards, but not with a Cherry Cymotion G-224. The Varmilo keyboards work perfectly fine on any other desktop computer I tested but which happened to be not of the Fujitsu brand.

However, only on the Fujitsu Siemens P710, both Varmilo keyboards would very often, but not always, stuck and repeat key combinations like Ctrl+C. This never happened in combination with the Cherry keyboard. So it seems, reproducibility of this issue depends on both the computer and the keyboard hardware.

Fed up with this behaviour, I recently installed a NEC USB 2.0 card in its single conventional PCI slot. The problem never reoccurred over the span of two weeks now.

[Andrew Yakovlev (adrug)]

I have a keyboard a4tech KV-300h and the bug reproduce on windows too. I have already tried to replace to another a new keyboard. The problem isn't gone.
I found out if I use embedded USB port of keyboard to connect a mouse then the problem reproduce very often.
Also I tested my keyboard on macbook pro. There is everything works fine.

System:
  Host: adrug-X470-AORUS-ULTRA-GAMING Kernel: 5.13.0-23-generic x86_64
  bits: 64 compiler: N/A Desktop: Cinnamon 5.0.7 Distro: Linux Mint 20.2 Uma
  base: Ubuntu 20.04 focal
Machine:
  Type: Desktop System: Gigabyte product: X470 AORUS ULTRA GAMING v: N/A
  serial: N/A
  Mobo: Gigabyte model: X470 AORUS ULTRA GAMING-CF v: x.x serial: N/A
  UEFI: American Megatrends LLC. v: F61 date: 07/13/2021
CPU:
  Topology: 6-Core model: AMD Ryzen 5 3600 bits: 64 type: MT MCP arch: Zen
  L2 cache: 3072 KiB
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  bogomips: 86394
  Speed: 2200 MHz min/max: 2200/3600 MHz Core speeds (MHz): 1: 2200 2: 2189
  3: 2199 4: 2200 5: 2199 6: 2199 7: 2199 8: 2200 9: 2249 10: 2198 11: 2200
  12: 2199
Graphics:
  Device-1: AMD vendor: Gigabyte driver: amdgpu v: kernel bus ID: 0c:00.0
  Display: server: X.Org 1.20.13 driver: amdgpu,ati
  unloaded: fbdev,modesetting,radeon,vesa resolution: 2560x1080~60Hz
  OpenGL: renderer: AMD Radeon RX 6600 XT (DIMGREY_CAVEFISH DRM 3.41.0
  5.13.0-23-generic LLVM 12.0.1)
  v: 4.6 Mesa 21.3.0-devel direct render: Yes

[Timo Denissen (timodenissen)]

Still happens on Ubuntu 20.04 with a Lenovo ThinkPad L14 Gen 2 (and the proposed OEM kernel). Workaround/fix for the issue is plugging in a USB keyboard. After that the issue is gone and the external keyboard can be unplugged again,