keyboard randomly goes dead; takes a logout to restore functionality.

[Matt `da Wolf]

Binary package hint: hal

I've had this bug in debian. Apparently it followed over me to Ubuntu and was not fixed. So I'll be typing away on my USB keyboard. Then it just dies. All input fails. No toggle keys, nothing. Mouse still works. I can logout, keyboard functionality will restore at the password prompt.

I get this in dmesg:
[ 332.124841] hald[5640]: segfault at 00002b8c7b7ea000 rip 000000000040e8e0 rsp 00007fff2f364900 error 4

Far more information than debian ever spat out to me. I can not tell anyone how to reproduce this. With debian, it would just happen. I thought it didn't exist until it occured last night. No real logic behind its timing.

[Matt `da Wolf (mattdawolf)]

great. Of all the things I forget the sysinfo.

kubuntu 7.10
kernel: 2.6.22-14-generic
amd64 processor

[Àlex Magaz (rivaldi8)]

I think I'm having the same problem. The only thing I don't get is the hald segfault. I've searched through my dmesg logs since August 3 and I can't find this message. Are you sure this hald segfault is related to the keyboard problem?

Some more things I've tried:
- Unplugging and plugging again the keyboard doesn't work.
- If I open a new user session, when the GDM login appears, then the keyboard works. But if I switch back to the already open session with Alt-F7, the keyboard stops working again.

It happens to me since Debian Sid from one year ago (more or less) then with Kubuntu Feisty Fawn and now with Gutsy. It has happened both with Logitech Cordless Desktop MX and with Cordless Desktop MX 3200 Laser. Never with a wired Logitech keyboard from Fedora 4 to Fedora 8.

What display manager do you use? And what keyboard?

Can someone give some hint on how to debug this?

[Sense Egbert Hofstede (sense)]

Thank you for your bug report. However, we need some more information before we can pass this on to the developers.
Could you please attach the results of the following commands:
cat /proc/version_signature > ~/version_signature
uname -a > ~/uname-a
sudo lspci -vvnn > ~/lspci-vvnn
lsusb -v > ~/lsusb-v

Please create the following files immediately after you've logged in:
dmesg > ~/dmesg_boot
cp /var/log/Xorg.0.log ~/Xorg.0.log
Try to replug the keyboard or access a terminal at your computer using VPN, SSH or similar.
Now create the following files:
dmesg > ~/dmesg
diff -ns ~/dmesg_boot ~/dmesg > ~/dmesg_diff
cp /var/log/Xorg.0.log ~/Xorg.0.log_tmp
diff -ns ~/Xorg.0.log ~/Xorg.0.log_tmp > ~/Xorg.0.log_diff

Please add all files you've got this way(you can use an archive). They are all located in your home directory(that's what the ~ is for).

[Matt `da Wolf (mattdawolf)]

Please create the following files immediately after you've logged in:
dmesg > ~/dmesg_boot
cp /var/log/Xorg.0.log ~/Xorg.0.log
Try to replug the keyboard or access a terminal at your computer using VPN, SSH or similar.
Now create the following files:
dmesg > ~/dmesg
diff -ns ~/dmesg_boot ~/dmesg > ~/dmesg_diff
cp /var/log/Xorg.0.log ~/Xorg.0.log_tmp
diff -ns ~/Xorg.0.log ~/Xorg.0.log_tmp > ~/Xorg.0.log_diff

I'm assuming you want this to be done right after it fails and I logout and back in? If that is the case, it may be some time as I do not know how to reproduce the error, just throw my keyboard in the trash when it happens in the middle of something I'm typing.

[Sense Egbert Hofstede (sense)]

I meant to do the first part before the keyboard stops working and when you have to replug the keyboard(which should be a way to get the keyboard back to work) that part is done after you're keyboard stopped working..

[Matt `da Wolf (mattdawolf)]

ok good. I just wanted to make sure.

[Àlex Magaz (rivaldi8)]

Yesterday the keyboard stopped working on my Fedora 8, but this time, there was a window giving me a hint. It was a window from Gnome telling me slow keys had been activated. (yes, although I use KDE, sometimes Gnome settings seems to get loaded and messes up with KDE.) Slow keys get activated after holding down Shift for 8 seconds, then you have to hold each key for 500ms (default) to it take effect. For some reason on my Kubuntu setting I didn't have any notification enabled (neither a message nor a speaker beep), so then it appeared like keyboard not responding. Well, I'm really only guessing, because after doing a lot of tests with Gnome and KDE accessibility settings in both installations, I think I'm getting a bit confused :-)

Matt, could you check if in your accessibility settings "Activation gestures" (translation) are enabled and notifications disabled? Also, if your keyboard fails again, could you try whether disabling accessibility resolves the problem or not?

[Sense Egbert Hofstede (sense)]

The bug report contains enough information for the developers to decide what needs to be done to this. I can't find the cause, but maybe they can. If not they'll probably know what to ask for next.

[Paulus (donmatteo)]

I get the same symptoms, also in Kubuntu (hardy). I think this has nothing to do with hal, but is rather a KDE thing. Alex, yes on my box the settings is checked. Can someone re-assign this bug to whatever sets KDE accessibility settings?

As a further point of reference:

http://kubuntuforums.net/forums/index.php?topic=3091551.0

[Àlex Magaz (rivaldi8)]

I've added a new user to ensure a default configuration. Then, after holding down the Shift key for 8 seconds, the PC speaker beeped and a dialog appeared to confirm I wanted to enable slow keys. So, maybe our problem comes from a previous default configuration.

Paulus, is your KDE configuration from a previous Ubuntu or Debian version?

[Pileofrogs (dmartin-sccd)]

Hi, I'm a Fedora user and I'm having this same problem. Hoping you'll fix it for upstream and I'll get it trickling back down.

I've seen this with Fedora 9 with Xorg packages from both Fedora 8 and Fedora 9. I've had this problem with both a ps2 and usb keyboard. I've also recently upgraded my mobo and video card. The video card was an ATI in both cases, using drivers from livna. (livna packages the drivers from ATI into handy yum repo). So, there might be a common thread there. I use Xfce,

Importantly, unplugging and replacing the keyboard does nothing (both ps2 and usb). I've seen zero log entries that correlate with this problem.

So!
 - It's not distro specific (Ubuntu, Debian and Fedora so far)
 - It's not hardware (ps2/usb/keyboard itself/motherboard)
 - It's not limited to KDE or Gnome or Xfce
 - It's not Nvidia or ATI related (I have ATI, Matt has Nvidia)
 - restarting X fixes it (logout and login restarts X)

I'm thinking this is an Xorg bug.

Here's what I get when I run "X -version"

  X Window System Version 1.3.0
  Release Date: 19 April 2007
  X Protocol Version 11, Revision 0, Release 1.3
  Build Operating System: Fedora 8 Red Hat, Inc.
  Current Operating System: Linux Woot 2.6.25.11-97.fc9.i686 #1 SMP Mon Jul 21 01:31:09 EDT 2008 i686
  Build Date: 24 July 2008
  Build ID: xorg-x11-server 1.3.0.0-47.fc8
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
  Module Loader present

If anyone wants more info from me, I'm monitoring this bug report.

[Sense Egbert Hofstede (sense)]

At some systems the keyboard goes randomly dead.
This bug has initially been reported by Matt `da Wolf, but is confirmed by other people.
It has been detected on:
Ubuntu 7.10, 8.04 and 8.04.1
Fedora 8 and 9
Debian
It's not related to the ATi or nVidia drivers, since it happens with both graphics cards.
It has been reported on KDE and GNOME.
It happens to both Ps/2 and USB keyboards, replugging them doesn't matter.

The only way to solve it is too restart the X server.

The bug report at Launchpad:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/186264

It's obvious you need more information, since e.g. I don't have the problem, but others that have got an nVidia card and a PS/2 keyboard, just like me, do have the problem. There are already some log files at the LP bug report, but I'm not sure if that's enough.

Something that could be useful:
http://launchpadlibrarian.net/13097472/dmesg_diff
http://launchpadlibrarian.net/13097468/Xorg.0.log

I've requested the Xorg.conf file, but that's not attached yet.

[Daniel Stone (daniels)]

HAL shouldn't be segfaulting.

[Sense Egbert Hofstede (sense)]

You think it's HAL's fault?

[Sense Egbert Hofstede (sense)]

I'm going to forward this upstream to freedesktop's bugzilla. Thanks for your information.

[Sense Egbert Hofstede (sense)]

Can you please add the file /etc/X11/Xorg.conf ?
Thanks in advance.

[Pileofrogs (dmartin-sccd)]

This is not a HAL problem. Only the initial reporter saw the HAL segfault. I have this problem and my HAL is not segfaulting.

[Pileofrogs (dmartin-sccd)]

Here's the xorg.conf as requested.

[Sense Egbert Hofstede (sense)]

The Fedora user posted his Xorg.conf file:
http://launchpadlibrarian.net/16855341/xorg.conf

[Andreas Mohr (andi)]

Dito here, same issue as Alex Magaz,
I fumbled with mouse keys (emulation of pointer movements via keypad),
then wanted to switch it off (it had been on for some time) but didn't remember the hotkey, pressed ctrl for 8 seconds (which launched KDE 3.5's accessibility keys dialog); shortly after that everything was dead.
Switching user (launching new X session) works, switching back to old session --> dead keyboard.

Highly annoyed.

Just found out that I simply had slowed keys ("Verlangsamte Tasten") accessibility feature enabled, had my keyboard working again when disabling it in kcontrol accessibility.

I consider this to be nothing other than an INaccessibility feature. Grrrr.
Describing this handling as "suboptimal" would be an understatement, there's no indication or reminder that keys are slowed (read: "dead" for all usual intents and purposes) by such a large amount (500ms).
Next thing I would have done was killed my _entire_ X session remotely - thankfully I managed to figure out this roadblock
just before doing so.

Almost ranks same scale as persistent "pointer grab" on my list of X server annoyances.

[Bryce Harrington (bryce)]

I disagree with comment #3. On the referenced bug report, some people's issue indeed is exactly because hal crashed.

It's possible there are additional, unrelated bugs that don't involve hal being dead, but those need to be properly reported (and not simply mentioned as "me too"). But remember to doublecheck whether you're running evdev (look in Xorg.0.log), and if so whether hal is running.

If the issue is that hal is crashed or exited unexpectedly, please report the issue against hal. If the issue is that hal is not installed, report that to your distro.

[Bryce Harrington (bryce)]

The -evdev driver is dependent on hal running in order for the mouse and keyboard to work. If hal segfaults, as indicated in the original report, yes Xorg will fail. With input not working, restarting hal requires ssh'ing into the system or something, to do it remotely. (Ick... but it *should* work as a workaround).

A number of people are me-too'ing to this bug, however you probably have unrelated bugs. If you are *not* using -evdev, or you are and hal *isn't* crashed, then you have some other bug. Please report separately.

And even if you are having a hal crash, it may be worthwhile to report it separately against hal, since it could be crashing for unrelated reasons.

This bug will focus only on the hal segfault Matt reported. I'll reassign to hal for further troubleshooting.

[sanix (bormotunchik)]

I have the same problem in Kubuntu Hardy Heron. *Sometime* when I pressing SHIFT for a couple secs keyboard dies.

[Thibault Dupuis (dthibault)]

Have you tested another keyboard?

[Vish (vish)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future.
To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".