Kernel Bug Tracker – Bug 9448
Sometimes keys are not released
Last modified: 2015-10-31 14:51:26 UTC
Most recent kernel where this bug did not occur: 2.6.21
Distribution: Slackware 12
Hardware Environment: Laptop Pentium II 400MHz
Software Environment: X, blackbox, Terminal emulator
Problem Description: keyboard keys sometimes are not released, so you'll have repeating key until you press/release the same key.
Steps to reproduce: Maybe you can see the problem only on low-end PC. Try to open a terminal under X (it seems that in console the problem does not appear) and works normally: you'll get sometime repeat keys even if the key was released.
There was some changes in atkbd.c keyboard module in order to set a delay (atkbd_schedule_event_work): maybe the release key event is not seen or seen before the press event.
Are you experiencing this solely on PS/2 keyboards? Does this also happen on USB ones?
I don't have an USB keyboard to test... However, it seems that the problem appears only if I use tha laptop integrated keyboard: attaching an external (also PS/2) keyboard, I never see the problem. I also tried by replacing atkbd.c with the 22.214.171.124 one, but the problem persist, so I think the problem is not here...
Thanks for opening this bug.
This problem is entensively discussed by many users here: https://bugs.launchpad.net/ubuntu/+bug/124406
However, none of the Ubuntu people responded to it so far.
We all assumed it was an Ubuntu related bug, since it happened after a system upgrade, but now there seems to be a Gentoo user with the same problem.
All users that posted kernel version infos relate this bug to an upgrade to a 2.6.22 version, although some apparently experience it with 2.6.20-16-generic. I myself (Cruncher) never experienced it with 2.6.20-16-generic.
This bug happens for all kinds of keys - best example is a Ctrl-W in browsers like Firefox or Opera, which will suddenly close all or most of your open tabs.
I have a thinkpad T42p, and I'm experiencing this problem both with an external USB keyboard and with the internal laptop's keyboard.
The bug is easily reproducible when using a power-hungry desktop environment and application, e.g. firefox under compiz. On my machine, switching to a lightweight window manager completely solved the problem.
As Wolfram mentioned, the ubuntu launchpad thread contains many more details and relevant configurations.
I can confirm that this happens too with a USB keyboard. I'm using 2.6.22-14-386 on Ubuntu 7.10.
I installed the current kernel from the Hoary Alpha2 release, 2.6.24-2-386
So far (for several days), the bug did not surface. So it might be it has been fixed already... *crossing fingers*
Can anyone confirm that?
It could be the Dmitry's input locking fixes, or various different things that might have fixed that. Could anyone else who was able to reproduce the bug please test with latest kernel.org kernel?
I tried with the latest 2.4.24 stable kernel, but the problem is still present...
(In reply to comment #4)
> The bug is easily reproducible when using a power-hungry desktop environment
> and application, e.g. firefox under compiz. On my machine, switching to a
> lightweight window manager completely solved the problem.
Unfortunately, taking the load off the machine does not solve the problem - it merely obscures it. "Good enough" should not be acceptable in this case, because it deals with *correctness* of information processing (IMO).
It may be, however, that reducing the load on the machine by using a different window manager indicates that the timing (?) issues of this bug are exascerbated by high load. Additionally, this may point to a difference in the way (keyboard) input is handled by the two window managers. It does not, however, solve the bug.
I really believe this should be investigated to find the "why", rather than finding workarounds.
Some things indicate that this might actually be a bug in xorg instead of being a kernel issue:
However, some facts that seem to contradict that:
- The xorg bug describes an endless loop that usually can only be broken out of by an X server reset. Here, the system will recover by itself.
- The bug described here was introduced for many when upgrading from Ubuntu Feisty to Ubuntu Gutsy - the latter using xserver-xorg-core 126.96.36.199, which predates the problem discussed in the xorg bug.
- In my case the bug was fixed (or at least never occured again) after a kernel upgrade, leaving xserver-xorg-core untouched at 188.8.131.52.
Apparently, there are two different varieties of the "key repeat" bug:
In one case, the repeating key will not stop by itself but only after an X server reset. It seems this bug can be reproduced by holding down a key and inducing mouse activity such as clicking buttons or scrolling the wheel. It relates to xserver-xorg-core-1.4.1 and there is a patch available.
In the other case, keys will repeat only for a few seconds, probably related to CPU load. For several people (including myself), upgrading to 2.6.24-2-386 fixed this problem.
Please report back if you have determined which of these bugs you are experiencing and whether the proposed solution worked for you.
I got only the 2nd case (key will repeat until the same key is pressed/released another time). I will try kernel 184.108.40.206..
mouse clicks can also get sent multiple times as happens when scrolling a website while it is playing video, for example. still happens with 2.6.24 (ubuntu hardy)
the apparent relation to specific linux versions is strange because the exact same issue also happens on solaris (indiana)
I can confirm that the bug is present in Gentoo as well using gentoo-sources-2.6.24-r4 on amd64 (the latest marked stable on this platform); tonight the bug (key stuck until new press/release of the same key) showed up while working on a text console (X was up, but it does not matter I believe) so it is not so obviously an X-only issue. The bug shows up more frequently during high-load period but it is not always the case. Also, I feel that some keydown events are missing as well, but this might be due to my keyboard/typing.
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 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 during idle time.)
"carlosbrolotobar" on ubuntuforums.org has the same problem, also correlated with usb device reset messages:
Some general hardware info:
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 220.127.116.11
nVidia proprietary driver 169.12
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
* First of all, the key stops repeating not only if you press/release the same key, but any key (also CTRL, for example).
* Second: I tried to upgrade X to version 1.4 but the behavior is still the same, so it seems that the problem is in the kernel itself, not in X.
* Third: the problem does not appear if you set preemption to "Server". In my kernel configuration, I always set preemption to "Low latency Desktop" (I need it for audio applications). Now I'm checking what happens if I set the preemption to "Voluntary-Desktop".
So, in order to find the root cause, maybe we have to check what was changed between 2.6.21 and 2.6.22 about preemption or kernel locking.
I was wrong about preemption model: the problem does not depend on it.
Now I have 2 kernel configurations: the Slackware default does not have the problem, the one I configured manually has the "repeating keys". Now I'm trying to change something in my own configuration to reflect the Slackware default, and see when the problem disappear. I also trying to compile 2.6.21 with my configuration (before I used the Slackware default kernel), and see if the problem exist also in this release.
It could be useful if I attach the differences of the 2 .config files?
Luca, do you also see the USB reset messages in your kernel logs?
Keyboard is the one integrated in the laptop (PS/2). Sorry, I don't have USB one to test...
I tried to compile 2.6.21 with my own configuration and the problem exist also in 2.6.21, so the problem was not introduced in 2.6.22.
Now I'm trying to remove/include some options on both configurations and see if the problem disappear/appear.
There is no a "sequence" to reproduce the problem: sometimes it appear at the first key stroked on the terminal, sometimes it takes many minutes before having repeating keys. I'll try to work as much as possible with this laptop...
If this is related to the CTRL stuck bug, then there is indeed a sequence to reproduce the problem. You open VMWare (I'm using Workstation 6), open a VM with Windows (I'm using XP) in it and then, with VMWare tools installed, you press CTRL while inside the VM and holding that key you move the mouse out of the VM's screen.
That way, you should no longer be able to use the shift to CAPITALIZE the letters. The quick work around is running setxkbmap, just like that with no switches or anything, just run setxkbmap et voila. Maybe this workaround works for this issue as well and maybe it'll help you guys figuring the bug out.
(In reply to comment #19)
> Keyboard is the one integrated in the laptop (PS/2). Sorry, I don't have USB
> one to test...
> I tried to compile 2.6.21 with my own configuration and the problem exist also
> in 2.6.21, so the problem was not introduced in 2.6.22.
> Now I'm trying to remove/include some options on both configurations and see if
> the problem disappear/appear.
> There is no a "sequence" to reproduce the problem: sometimes it appear at the
> first key stroked on the terminal, sometimes it takes many minutes before
> having repeating keys. I'll try to work as much as possible with this laptop...
No, the problem is not related to CTRL/SHIFT keys. The problem occurs for normal keys, and disappear when you press any other key, and it seems a matter of kernel configuration, since I have the problem only with customized kernel and not with the one coming with the distribution (Slackware).
I am having the same problem with Hardy Heron 18.104.22.168, kernel 2.6.24-23-generic. i have had ubuntu on since 7.04 and this is the first instance i have had.
I am using a Sony VIAO pcg-fxa49 so this has the built in keyboard as wel
Finally, I think I discovered the root cause: the psmouse driver (this could be also the reason why the problem exists only under X). If compiled built-in, I got the repeating-keys problem. If compiled as module, it seems the problem never appears.
My distribution (Slackware) by default loads the psmouse module with "proto=imps". Since it is not so easy to reproduce the problem, I suppose that the problem occurs only when proto is set to "auto/any" (or no options, such as for the driver when compiled built-in).
The question: is it normal that psmouse auto protocol interferes with the keyboard?
Luka, could you please tell me what touchpad type psmouse module detects when it is built into the kernel (or loaded without proto=imps option)? Thanks!
Built-in kernel (or loaded with proto=any or proto=exps):
[ 4.300226] Synaptics Touchpad, model: 1, fw: 4.1, id: 0x848a1, caps: 0x0/0x0
[ 4.334294] input: SynPS/2 Synaptics TouchPad as /class/input/input2
[ 23.857559] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input3
My touchpad is very old, without synaptics functions.... Maybe the problem is only in protocol auto-detect?
Does it help if you load psmouse with "rate=40" option (make it psmouse.rate=40 if psmouse is built-in)?
I happily discover that my touchpad has synaptics functions... So, the psmouse driver detects correctly the protocol SynPS/2.
Setting "rate=40" does not help. The only workaround is to load psmouse with "proto=bare" or "proto=imps" (but I loose synaptics functions, just after discover and appreciate them....).
What can I do in order to understand where is the problem? There is a way to debug keyboard and synaptics driver?
I re-changed the kernel version. I tried from 2.6.21 to 2.6.29 and the problem exists in all. I suppose it is in all 2.6 (maybe also in 2.4).
Luca, do you ever see the repeating key problem if you use the text console? Or is it only happening in X?
I also see this problem or something closely related. It looks like the issue varies slightly for the people here.
Stuck keys for me are 1 to 4 when switching the GNOME workspace under a high-load scenario. The particular number is repeated usually until I hit escape. Subsequently, hitting any key will often, but not always, produce that number. IOW, hitting 'g' or any other key will produce '2'. Even hitting backspace results in a '2' if I switched to the second workspace. I never experienced this outside of X.
I recompiled git vanilla HEAD yesterday and was able to reproduce it for that kernel, too.
I first saw this after updating to jaunty from hardy around the end of January this year. Yes, this is a regression. Please mark as such.
(In reply to comment #29)
> Luca, do you ever see the repeating key problem if you use the text console? Or
> is it only happening in X?
It happens only in X, even when disabling mouse. I never got the problem in console, with or without gpm. It also seems that the problem does not appear with external PS/2 keyboard.
switched from Gnome to KDE in Ubuntu, no sticky key problem any more... It was very definite for me when and where it was happening, so I could reproduce the bug anytime I want, and it is not happening anymore in KDE...
I haven't seen any mention of this workaround, but on my laptop, manually configuring the keyboard and mouse in xorg.conf fixes the problem.
specs for compaq c304nr here:
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
Option "AutoAddDevices" "off"
Option "AlwaysCore" "true" # send events to CorePointer
# Option "Device" "/dev/input/mice"
Option "Device" "/dev/psaux"
Option "Protocol" "auto-dev"
Option "SHMConfig" "false" # configurable at runtime? security risk
# Option "LeftEdge" "1700" # x coord left
# Option "RightEdge" "5300" # x coord right
# Option "TopEdge" "1700" # y coord top
# Option "BottomEdge" "4200" # y coord bottom
# Option "FingerLow" "25" # pressure below this level triggers release
# Option "FingerHigh" "30" # pressure above this level triggers touch
Option "MaxTapTime" "180" # max time in ms for detecting tap
Option "VertEdgeScroll" "true" # enable vertical scroll zone
Option "HorizEdgeScroll" "true" # enable horizontal scroll zone
Option "CornerCoasting" "true" # enable continuous scroll with finger in corner
Option "CoastingSpeed" "0.30" # corner coasting speed
Option "VertScrollDelta" "100" # edge-to-edge scroll distance of the vertical scroll
Option "HorizScrollDelta" "100" # edge-to-edge scroll distance of the horizontal scroll
Option "MinSpeed" "0.30" # speed factor for low pointer movement
Option "MaxSpeed" "0.60" # maximum speed factor for fast pointer movement
Option "AccelFactor" "0.0020" # acceleration factor for normal pointer movements
Option "VertTwoFingerScroll" "true" # vertical scroll anywhere with two fingers
Option "HorizTwoFingerScroll" "true" # horizontal scroll anywhere with two fingers
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "ColorKey" # <i>
#Option "CacheLines" # <i>
#Option "Dac6Bit" # [<bool>]
#Option "DRI" # [<bool>]
#Option "NoDDC" # [<bool>]
#Option "ShowCache" # [<bool>]
#Option "XvMCSurfaces" # <i>
#Option "PageFlip" # [<bool>]
VendorName "Intel Corporation"
BoardName "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
Viewport 0 0
Viewport 0 0
Viewport 0 0
Viewport 0 0
Viewport 0 0
Viewport 0 0
(In reply to comment #33)
> I haven't seen any mention of this workaround, but on my laptop, manually
> configuring the keyboard and mouse in xorg.conf fixes the problem.
> Section "InputDevice"
> Identifier "Keyboard0"
> Driver "kbd"
This suggests that the problem is in X's new evdev driver that is I believe is used by default nowadays. "kbd" is the legacy keyboard driver.
(In reply to comment #34)
> (In reply to comment #33)
> > I haven't seen any mention of this workaround, but on my laptop, manually
> > configuring the keyboard and mouse in xorg.conf fixes the problem.
> > Section "InputDevice"
> > Identifier "Keyboard0"
> > Driver "kbd"
> > EndSection
> This suggests that the problem is in X's new evdev driver that is I believe is
> used by default nowadays. "kbd" is the legacy keyboard driver.
That may be the case. In fact, since upgrading to Ubuntu 9.10 beta my new xorg conf looks like this:
Identifier "X.org Configured"
InputDevice "Keyboard0" "CoreKeyboard"
However, this bug or something similar now pops up for the first 5 minutes or so after booting the system. It only appears to happen when firefox is running(I haven't fully confirmed this), which is really odd. Or maybe it isn't - what do I know?
I am running Gentoo, 2.6.31, recently updated xorg from 1.6.3 to 1.7.1. and it did not solved the issue. However changing the KBD driver to EVDEV for now seems to be the solution (inspiration taken from http://bbs.archlinux.org/viewtopic.php?pid=334978 )
My symptoms were: keyboard got stuck and repeated itself, only in X, not on console. The issue happened very likely under a high load (compiling, flash webpages). There was no escape procedure, I had to log in via ssh and kill X.
I have no idea, if the issue can be Xorg related, but it started only recently - as far as I can remember, it was when I changed my diskless, boot-from-network configuration to a disk based one (with the same rootfs).
As noted in the comments, this blog post from Andrew Jackson could be relevant:
can somebody please run the test in attachment 24530 [details] of bug 9147? it also happens in Xorg only
(In reply to comment #37)
> As noted in the comments, this blog post from Andrew Jackson could be relevant:
I confirm that it got much worse since I moved from F11 -> F12
I've got some hardware here that causes:
usb 3-1: reset low speed USB device using uhci_hcd and address 9
and that causes (or seems to be strongly related) to keyboard hiccups.
Whenever it happens, and a key is held down, that key is deemed to be held down for a second, and keyboard repeat kicks in. This is because /class/input/inputXX hiccups.
The device that triggers it for me is a misbehaving USB barcode scanner. It appears as a USB HID keyboard, but I believe the implementation is incomplete. It shows up with an invalid vendor/product:
Bus 003 Device 009: ID 0000:0001
On the outside, it's a Zebex 3051HS device.
When this scanner is reset, it's /class/input/inputXX hiccups, which causes *all* X devices to hiccup. In other words, even though the USB barcode scanner resets, all the keyboards hiccup. I've seen it hiccup PS/2 keyboards. X may be stuck trying to read the scanner's /class/input/inputXX. The actual bug is this device, but the symptom is that some other device malfunctions.
The device behaves correctly until a bus reset happens (could be weeks), but once a bus reset happens, the device is stuck, and gets reset continuously. The HID reset is obviously insufficient for this device.
Arbitrarily, I'd like to write a quirk for this device to remove hid-core's USB pre-reset and post-reset methods, and let it bind/unbind instead, but I don't know how to do that. For me, it's also definitely tied to this broken device.
(In reply to comment #10)
> Some things indicate that this might actually be a bug in xorg instead of being
> a kernel issue:
I have seen this problem in a terminal, even without xorg running (in addition to inside xorg), so at least for me this is not a bug in xorg.
The PC I see this on is a netbook with Atom CPU. I remember I had the same problem before in my last Atom based netbook (older Atom CPU type), but I think it disappeared at a point in newer kernels/distros.
Is there a chance of bisecting this since support for Atom CPUs was introduced (or do we know a version the bug was not present?)? Does anyone know in which version this was?
(In reply to comment #41)
> Is there a chance of bisecting this since support for Atom CPUs was introduced
> (or do we know a version the bug was not present?)? Does anyone know in which
> version this was?
I tried older kernel version, but couldn't find one that works for Atom and don't has this problem, so it might not be a regression.
I turned on debug with kernel option "i8042.debug=1" and could then see the interrupts for key press and release:
[ 1226.872457] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1226.947548] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1227.022286] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1227.097376] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1227.172118] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1227.246507] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1227.256772] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, 0, 1) 
[ 1227.461153] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1228.061194] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
[ 1228.136224] /build/buildd/linux-2.6.35/drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, 0, 1) 
where 32 is key down and b2 key release.
I seem to get multiple interrupts while holding down the key, and in the case that the key is stuck, I can't see the key release interrupt.
Could this problem be caused by lost interrups somehow? Is a higher priority interrupt causing this to be loosed?
I was not able to reproduce this bug on the same laptop using an external USB keyboard. That probably narrows it down a little.
Still there in 3.2 kernel and the last rc of 3.4 I tried.
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 repeat 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 physically 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 physically 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).
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 X, KDE, Gnome etc.), only at text screen console.
The bug appears more often in latest kernels, also more often when I use RealVNC server or TeamViewer server and remotely control my computer (in KDE enviromnent).
Also I suppose there 2 different bugs with same sympthoms (sometimes keys are not released or keyboard imitated of clicking '1', '2', '3' etc. even if I didn't work on keyboard and mouse) - the one bug is shown when users connects a not so popular USB devices (like 'SkypeMate USB-B2K' in my situation) - this bug is easy to reproduce (repeat) by finding and connecting such devices - this is a kernel problem - since such devices were not discovered and supported by kernel development team - it causes some vulnerabilities and shows some unusual and unpredictable behavior of kernel (in my situation - keyboard imitated of clicking '1', '2', '3', but it would be something else with another USB hardware).
The second different bug is also easy to reproduce - to buy some hardware like some models of motherboards or WiFi adapters connected to PCI or PCIe (models from user reports who detected this bug) - bug can be temporary solved by setting acpi=off parameter to the kernel boot parameters in Grub (or unload the battery, AC and thermal modules of kernel after booting). This is also vulnerability of kernel as like with USB devices.
My kernel is 3.13.0-30-generic and still experience problems with SkypeMate USB-B2K (maybe will not use it)