Created attachment 315224 [details] /var/log/dmesg When I boot to level 3, and log in, everything works, I'm using 11 virtual ttys. After some time, the keys between the main keyboard and the numeric keypad (arrows, Ins, Home, ..., PgDn) stop working. Not all of them, only some subset. The sometimes start working after a few minutes or hours... The problem does not appear with 2.6.25 (namely 2.6.25-0.218.rc8.git7.fc9.i686 have run for many weeks without any problem) but it seems to appear with various 2.6.26 kernels (e.g. 2.6.26-0.81.rc7.fc10). I'm using "startx" and I suspect that the problem does not happen before I call startx and switch to X and back to console several times; but perhaps it is only that have not abstained from X was long enough. I would like to receive any hints how could I help with this.
Created attachment 315225 [details] /var/log/Xorg.0.log
Created attachment 315227 [details] /var/log/messages
Created attachment 315228 [details] /etc/X11/xorg.conf
A few questions for clarification: (In reply to comment #0) > When I boot to level 3, and log in, everything works, I'm using 11 virtual > ttys. do you actually boot into gdm, or just console? When the keys stop working - is that in X or on the console? > After some time, the keys between the main keyboard and the numeric keypad > (arrows, Ins, Home, ..., PgDn) stop working. Not all of them, only some > subset. This is usually a keymap issue. If you are in X when that happens, please run xkbcomp :0 - and attach the output here. Then also attach the same output when it is working. Likewise, the info of setxkbmap -print is helpful in both cases. > I'm using "startx" and I suspect that the problem does not happen before I call > startx and switch to X and back to console several times; but perhaps it is > only that have not abstained from X was long enough. so do I get this right: you start X, switch from tty to X and back a few times and at one point it stops working? In X, presumably? Or at the tty?
I apologize that my bug report was so unclear. (In reply to comment #4) > do you actually boot into gdm, or just console? I boot to console only. > When the keys stop working - is that in X or on the console? It stops working in console. (In most cases, out of the 10 keys between There is no problem in X. I do use a nonstandard keymap on console. I do have an ancient keayboard (the hardware). But I have used both for ages without any problem. And if I boot to kernel 2.6.25, it works correctly, for several weeks.
reproduced with 2.6.27-0.284.rc4.git6.fc10.i686
I've the same problem on Fedora 8 (32 Bit) after updating from kernel 2.6.25 to 2.6.26. The system boots into console mode (run level 3, no X started yet). Users cannot use cursor keys and other application keys in the shell. Happens on four totally different machines, so it's unlikely a hardware failure. Interestingly, hitting the "Insert" key once cures the problem temporarily but it doesn't last for long. Don't know what's so special with the "Insert" key. I hope it's not the first step to the newly introduced plan to completely remove text consoles from Fedora. ;-)
*** Bug 458400 has been marked as a duplicate of this bug. ***
My reproduction scenario - boot into runlevel 5 - switch into vty X, cursor keys are working - press Insert, cursor keys doesn't work - press Insert again, cursor keys start working
My reproduction scenario - use rawhide in vmware - boot into runlevel 3 - try edit in vim -> some buttons aren't working - Insert for example - boot into runlevel 5 -> vim is working, but some keys in konsole or other application are printed more than once.
Well, it seems the upstream's bug 11242: http://bugzilla.kernel.org/show_bug.cgi?id=11242 Since 2.6.26, the console's "Insert" key behaves like a strange Lock. After the pressing of "Insert", some keys (including narrow, PgUp/PgDown etc.) no more work. AFter the pressing of "Insert" again, those keys continue to work. "Insert" itself does not work at all under Linux console since 2.6.26. It seems that kernel developers have chosen the "Insert" key for the start of some accessibility mode under Linux console. Forgive them, guys. They just cannot consider how it is possible to work with computer in the current modern world without GUI. They assume that all the people who used TUI have already died, or (if still not died) need an accessibility, which they have implemented </sarcasm>. Please, fix this disgusting issue in the next kernel update for all the current releases: Fedora 8, Fedora 9, upcoming Fedora 10 and Rawhide (IOW for all releases which have kernel-2.6.26 now).
The upstream's patch is here: http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=review-2.6.26/braille_console-only-register-notifiers-when-the-braille-console-is-used.patch;hb=HEAD Perhaps it would be better to compile an accessibility support as a module?
The temporary work-around. The idea is to change the keycode, generated by the Insert key. 1. Run "dumpkeys" and chose an unused keycode. I've chosen 126 for my case. 2. Cause this keycode to generate "Insert" event (as an ordinary 110 keycode already do): echo 'keycode 126 = Insert' | loadkeys (You can test results by "dumpkeys | grep Insert") 3. Run "getkeycodes" and determine, what raw keycodes generated "110". In my case it is "e0 52" 4. Map "e0 52" to 126 instead of 110: setkeycodes e052 126 As a result, the pressing of "Insert" key now generates "126" instead of "110", thus no more grabbing by the accessibility (which still expects "110"). And the "126" produces the same "Insert" event for the Linux console. In short: add to /etc/rc.d/rc.local: setkeycodes eo52 126 echo 'keycode 126 = Insert' | loadkeys
Thanks, Dmitry, your workaround is great! Text consoles are now usable again. However, this seems to affect the X Window System, the Insert key no longer works (for example, toggle Insert/Replace in Vim or Shift-Insert to paste text from the clipboard in xterm). When I run "xmodmap -e 'keycode 116 = Insert'", X seems to feel much better.
Yep. X keycodes do not match Console keycodes, therefore "xev" command should be used to obtain the keycode of the "changed" (by setkeycodes above) Insert key. Then add to /etc/X11/xinit/xinitrc.d/ some script with: xmodmap -e 'keycode NNN = Insert' Finally, I've chosen console code 124 (because 126 is actually in use). The soluiton is: cat <<EOF >>/etc/rc.d/rc.local setkeycodes eo52 124 echo 'keycode 124 = Insert' | loadkeys EOF cat <<EOF >/etc/X11/xinit/xinitrc.d/insert-key.sh #!/bin/sh xmodmap -e 'keycode 133 = Insert' EOF chmod +x /etc/X11/xinit/xinitrc.d/insert-key.sh Note though, that setkeycodes does not affect USB keyboards at all :( Use non-usb keyboard instead for a while.
So this should be fixed in 2.6.26.6 then. It should also be fixed in 2.6.27 since that patch was merged.
kernel-2.6.26.6-46.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/kernel-2.6.26.6-46.fc8
kernel-2.6.26.6-71.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kernel-2.6.26.6-71.fc9
kernel-2.6.26.6-79.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8929
for commet #17 : > kernel-2.6.26.6-46.fc8 has been submitted as an update for Fedora 8. and even was announced in fedora-devel list. But actually kernel-2.6.26.6-46.fc8 did not appear neither in updates nor in updates-testings. What plans for F8 update?..
kernel-2.6.26.6-79.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
The bug continued to appear in various kernel versions, for example 2.6.27rcX (where X was 4, 5, or 6). But it seems to be fixed in 2.6.27.5-101.fc10, so I'm happy the bug is fixed.