Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
==Configuration== When I switched from 2.6.21 to 2.6.22 I started having troubles with the mouse and keyboard; sorry I cannot be more precise about the change, but I am sure it started happening with the 2.6.22 kernel. dmesg|grep -i keyboard returns: input: AT Translated Set 2 keyboard as /class/input/input3 I have the following configuration in xorg.conf regarding the keyboard: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "it" EndSection Tweaking this section of xorg.conf did not lead to any change, so I suspect that it is a kernel-level problem. Please tell me which files/logs you need in order to better understand the problem ==Mouse bug== If I do not use the kernel parameter 'i8042.nomux=1' I have a skipping mouse which stops moving very frequently and then moves again. During those pauses the following messages are generated in dmesg: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. This bug is worked around using the 'i8042.nomux=1' kernel parameter, but it started appearing together with the below keyboard bug, hence I think they might be both relating to the i8042 handling. Seems that 2.6.21 did not have multiplexing active by default and that kernel parameter disables it. ==Keyboard bug== Some keyboard keys do not get released; looks like the release keycode is never caught. I get infinite keypresses even after having released the key; if I push again the key, the infinite keypresses are interrupted. I am experiencing the issue when using XFCE4, seems that it does not happen from the shell. I can find in dmesg the following lines when the keys get stuck: atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. I do have special keys on this notebook, but I am not pressing them of course - and if I press them no atkbd.c message is triggered.
*** This bug has been marked as a duplicate of bug 194703 ***
Sorry, this bug is not related to 194703. I had reported the same issue there but it has not been fixed by that patch. I no more have the hangup described in that bug (which was caused by xfwm4) but now I have a problem of stuck keys (see the bug description)
Seems that using 'i8042.direct=1' works around the bug - disallowing keyboard codes translation. Kernel command line: root=/dev/hda3 console=tty1 vga=0x318 i8042.nomux=1 i8042.direct=1 A kernel issue?
I confirm - the bug no more happens using i8042.direct=1 There must be something wrong in the translation from this keyboard
Nope: the bug happens hardly but still happens. I have tried most combinations of the i8042.* kernel parameters without any luck The i8042.nokbd=1 and i8042.noaux=1 does not seem to affect the problem. I am now using these kernel parameters: i8042.nomux=1 i8042.direct=1 i8042.nopnp=1 i8042.dumbkbd=1 And the keyboard problem is gone, BUT - strangely enough - the psmouse.c lost sync problem appearead again while moving the mouse over a xterm. I haven't yet studied the i8042.c source code - can somebody help me at hacking out this problem? I have several years of C programming experience (sockets, ICE, etc.) and maybe I can chew this bug
With the (i8042.nomux=1 i8042.direct=1 i8042.nopnp=1 i8042.dumbkbd=1) kernel parameters I still get the atkbd.c messages and once also the psmouse.c messages. I am pretty sure that i8042.direct=1 is the parameter which reduces the stuck keys occurencies, while i8042.nomux=1 solves (99%?) the psmouse.c problem.
So the keyboard thing (keys not getting released) happens only when you're in X (Xfce) and not when you're in a virtual console (ie. not in X)? That would indicate that it's not a kernel issue, but an X / Xfce issue. Also, looking at the git logs, almost nothing has happened to the two files mentioned here, atkbd.c and psmouse.c, between 2.6.21 and 2.6.22. (Only 2 commits touch atkbd.c, none psmouse.c). Anyway, can you reproduce this on the latest development kernel, currently 2.6.23-rc9? Please post your kernel .config and dmesg output.
I also saw that no relevant modifications were done to those files, so I suppose it's due to a default kernel parameters change (i8042.nomux=1 was set by default on kernel 2.6.22, I think) Or, more probably, it might be as you said an X / Xfce issue; is it possible that the unstable gtk v2.12 is causing the problem? A previous bug related to hangups was caused by it. I will now attach the current .config and dmesg and then use the most recent stable gkt+ and report my findings.
Created an attachment (id=132982) [details] .config of current compilation with kernel 2.6.22-r8
Created an attachment (id=132983) [details] dmesg of today
As you can see from today's dmesg, when keys do stuck I no more get atkbd.c messages but: Hangcheck: hangcheck value past margin! I will remove gtk+ v2.12 within a few hours
I am 100% sure that my problem is the same of this one: https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html So, both my assertions about "not happening on console" and "not happening with 2.6.21" might be false. I am looking through other messages on LKML but I am getting convinced that the issue has never been solved. As soon as my full rsync will be completed I will use the most recent gentoo-sources and not use any unstable package.
I have tried both the new "kbd" and the old "keyboard" Xorg drivers - problem happens equally I am still waiting to test with gtk+ v2.10 The 2.6.23 kernel is not on portage, I guess I will have to get it otherwise
The problem is still here even with the stable gtk+ (v2.10) I am always using the same kernel parameters: root=/dev/hda3 console=tty1 vga=0x318 i8042.nomux=1 i8042.direct=1 i8042.debug=0 i8042.nopnp=1 i8042.dumbkbd=1 When keys get stuck I get on messages: Hangcheck: hangcheck value past margin! I no more get the atkbd.c messages because of the modified i8042.* overrides, I guess. Can somebody please tell me what to do now?
Sorry for too many posts, I am new to these kernel-inside things (although I do have some years of c programming with sockets, low-level hardware etc.) I am now recompiling without the hangcheck timer. Disabling it I will probably no more get any message of any type when the keyboard keys get stuck. So I will have to disable some of the additional kernel parameter in order to get the atkbd.c messages. I guess that once the atkbd.c messages show again I could enable i8042.debug=1 and produce a dmesg for further analysis. My problem is the same as this one: https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html
These people have better described the problem but still did not reach a solution: http://dev.laptop.org/ticket/2401 NOTE: I do not insert or remove the battery when experiencing the problem, in my case I guess that ACPI events do the same trick anyway As far as I have read around the web, this is a problem which affects almost any distro and a lot of laptop users, and it has not yet been fixed (at least since 2005)
I have removed i8042.dumbkbd=1 from the kernel parameters, which now are: i8042.nomux=1 i8042.direct=1 i8042.nopnp=1 and I get again the atkbd.c messages: atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. NOTE 1: i8042.nopnp=1 is irrelevant to the issue verification NOTE 2: i8042.direct=1 seemed to give less stuck keys, but that was apparent as far as I have tested now I don't know how to see when IRQs get disabled (see link in comment #16), that might help me to debug the problem or maybe even produce a patch... I think that ACPI periodically pauses IRQs and so causes the kernel to "eat" some keypresses
> The 2.6.23 kernel is not on portage, I guess I will have to get it otherwise > It is, it's called vanilla-sources. The latest version as of this writing is: sys-kernel/vanilla-sources-2.6.23_rc9 (it is masked though). Thank you for all your testing.
Ok, thanks for the info - going to test it now (I will keep 2.6.22-r8 in the boot partition anyway) If I someway get this fixed, I hope we can publicize the fix because it really makes people crazy to have a non-working keyboard on a laptop!
Tested with sys-kernel/vanilla-sources-2.6.23_rc9 and no change: atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known. I will from now on switch back to 2.6.22-r8
I am now using the following kernel parameters with stable kernel 2.6.22-r8: i8042.nomux=1 acpi=off And the keyboard issues are gone! This is clearly an ACPI vs IRQs issue (in my opinion) I will play a bit with acpi and other acpi_* kernel parameters and post my findings; the ipothesis is that ACPI events discards some keyboard IRQs. I have noticed (without acpi=off) that when the battery is inserted the keyboard is almost unusable, so this should be coherent with the fact that many ACPI events are generated while the battery is loading. Finally, I could produce an ACPI debug log and try to isolate an atkbd.c message regarding lost keyboard data
When I use only the kernel parameter 'acpi_irq_nobalance' (and not i8042.nomux=1) I no more get the psmouse.c lost sync messages but still get the atkbd.c messages and issues.
The minimal kernel parameters needed to use the mouse and the keyboard seem to be: acpi_irq_nobalance acpi=noirq If I disable 'acpi_irq_nobalance' I get again the atkbd.c messages and the keyboard stuck keys
I am getting again: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. So the minimal needed kernel parameters set is: i8042.nomux=1 acpi_irq_nobalance acpi=noirq
I were wrong in previous comment #24, only acpi=off does the trick. I am now testing pnpacpi=off and it seems to work; e.g. the minimal needed parameters to work around the i8042 vs ACPI issues are: i8042.nomux=1 pnpacpi=off P.S. this bug entry looks like a blog, and I hate blogs. Can I create a new one with only the relevant informations?
Again, the minimal workaround kernel parameters are: i8042.nomux=1 i8042.nopnp=1 Also i8042.nomux=1 i8042.noacpi=1 worked, but noacpi is more invasive I guess.
Addressing of this bug has been moved upstream http://bugzilla.kernel.org/show_bug.cgi?id=9147
The bug can also be worked around emerging package acpid
(In reply to comment #28) > The bug can also be worked around emerging package acpid > I think it can't be worked around this way, because I am running acpid for a long time and the problem is still there. Or did you mean emerging acpid and then do some configuration around it?
Please ignore that comment; I am also running acpid and it does not affect the bug triggering. We are discussing upstream about disabling the ac/thermal/battery modules - which seems to better workaround the bug; please join the discussion if you wish.
