Re: Laptop keyboard unusable when ACPI is active

Re: Laptop keyboard unusable when ACPI is active

[legolas558]

I am posting this message just to say that this bug is being addressed
on the bug tracker:
http://bugzilla.kernel.org/show_bug.cgi?id=9147

Regards,
--
  Daniele C.


legolas558@users.sourceforge.net ha scritto:
> legolas558@users.sourceforge.net ha scritto:
>   
>> Kernel: 2.6.22-r5
>> Kernel option: i8042.nomux=1
>>     
> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options:
>
> i8042.nomux=1 acpi=off
>
> I have tried kernel 2.6.23-rc9 but the problem is still there.
>
>   
>> The problem which still remains, and I can't fix or work it around, is
>> witnessed by the below dmesg lines:
>> -----
>> 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.
>> -----
>> The release event for some keys is never caught, so all sorts of
>> troubles happen if for example I use the Del key and it stucks, or if
>> I use the Ctrl key and it never gets released...pushing again the
>> stuck key brings back the key in the proper status.
>>     
> With acpi=off the problem is totally worked around.
>
>   
>> Can somebody please give me some clues about this issue, and possible
>> solutions? I have been searching the web for a couple of weeks and
>> seems like it is a common trouble of notebook users, but nobody has
>> yet published a solution.
>>     
> I am trying to find a path myself in this issue - which dates back to at
> least 2005 and has never been resolved.
>
> I would now try some other kernel parameter in order to preserve ACPI
> functionality and possibly prevent ACPI from messing up the keyboard IRQs.
> Can somebody please give me istructions regarding the correct tests
> (regarding kernel parameters and/or anything else) to perform in order
> to better isolate the issue?
>
> Related Gentoo bug tracker item:
> http://bugs.gentoo.org/show_bug.cgi?id=194781
>
> Other messages about the same kernel bug (many more can be found
> googling around, and no solution yet):
> https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html
> http://dev.laptop.org/ticket/2401
>
> Regards,
> --
>   Daniele C.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>   

Re: Laptop keyboard unusable when ACPI is active

[legolas558]

Hi all,

some upates about this issue (see also bug 9147 
http://bugzilla.kernel.org/show_bug.cgi?id=9147 ).

The 'ac', 'battery' and 'thermal' modules (compiled as stand-alone) do 
cause the bug; it suffices that one of them (or any set of them) is 
loaded to trigger the bug either immediately or after some time.
If none of them is loaded into memory, the bug does not happen.
Also, the 'battery' module does not generate system messages although 
the problem is equally verified.

The 'thermal' module instead, when loaded with 'modprobe thermal', 
causes the enter key pressed to execute the command to be indefinitively 
repeated into any terminal. This is currently a perfectly reproducible 
testcase for bug 9147.

The bug has been confirmed by at least another user (with different 
hardware configuration); please reply for either bug addressing or 
confirmation.

The current known best workaround to this bug is to compile all the 
above mentioned ACPI modules as stand-alone and to not (auto)load them 
(loosing their vital functionalities, since we are talking about laptops 
here, see http://gentoo-wiki.com/HARDWARE_Maxdata_Pro_7000_DX for an 
example of affected hardware).

It is also important to note that this bug always comes with bug 8740 
http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also 
an ACPI issue).

Best regards,
--
  Daniele C.


legolas558@users.sourceforge.net ha scritto:
> I am posting this message just to say that this bug is being addressed
> on the bug tracker:
> http://bugzilla.kernel.org/show_bug.cgi?id=9147
>
> Regards,
> --
>   Daniele C.
>
>
> legolas558@users.sourceforge.net ha scritto:
>   
>> legolas558@users.sourceforge.net ha scritto:
>>   
>>     
>>> Kernel: 2.6.22-r5
>>> Kernel option: i8042.nomux=1
>>>     
>>>       
>> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options:
>>
>> i8042.nomux=1 acpi=off
>>
>> I have tried kernel 2.6.23-rc9 but the problem is still there.
>>
>>   
>>     
>>> The problem which still remains, and I can't fix or work it around, is
>>> witnessed by the below dmesg lines:
>>> -----
>>> 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.
>>> -----
>>> The release event for some keys is never caught, so all sorts of
>>> troubles happen if for example I use the Del key and it stucks, or if
>>> I use the Ctrl key and it never gets released...pushing again the
>>> stuck key brings back the key in the proper status.
>>>     
>>>       
>> With acpi=off the problem is totally worked around.
>>
>>   
>>     
>>> Can somebody please give me some clues about this issue, and possible
>>> solutions? I have been searching the web for a couple of weeks and
>>> seems like it is a common trouble of notebook users, but nobody has
>>> yet published a solution.
>>>     
>>>       
>> I am trying to find a path myself in this issue - which dates back to at
>> least 2005 and has never been resolved.
>>
>> I would now try some other kernel parameter in order to preserve ACPI
>> functionality and possibly prevent ACPI from messing up the keyboard IRQs.
>> Can somebody please give me istructions regarding the correct tests
>> (regarding kernel parameters and/or anything else) to perform in order
>> to better isolate the issue?
>>
>> Related Gentoo bug tracker item:
>> http://bugs.gentoo.org/show_bug.cgi?id=194781
>>
>> Other messages about the same kernel bug (many more can be found
>> googling around, and no solution yet):
>> https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html
>> http://dev.laptop.org/ticket/2401
>>
>> Regards,
>> --
>>   Daniele C.

Re: Laptop keyboard unusable when ACPI is active

[Mats Johannesson]

Many responsible CCs added.

On 2007-10-20 18:33:09 Pavel Machek responded to Daniele C.:
> > > Try disabling acpi embedded controller.
> > >
> > How can I accomplish this? Are you referring to the i8042?
>
> rmmod acpi_ec or how is it called. But I'm not sure how easy this is.

Designed to be 'hard' because it in effect breaks several functions.
See "config ACPI_EC" in drivers/acpi/Kconfig which one must edit
manually, as well as arch/*/configs/*_defconfig

Either way, the result is exactly as not loading modularized battery
and ac (thermal module still worked on my system).

But this whole issue is getting ridiculous. INPUT subsystem is addled
more and more by ACPI (in real laptop life) while the maintainers,
from a user view, seem stumped.

The bad interaction between ACPI controlled EC (embedded controller)
and the i8042 interrupt handler is theorized about in detail at OLPCs
http://dev.laptop.org/ticket/2401 - almost at the end of that page.
Thanks to Daniele C for the link.

And the bug scenario has been present for many _years_ now. From my own
experience it is only getting worse. Here's the current relations in
2.6.24-rc3-git1

_EC-reading ACPI modules unloaded_

Notebook keyboard and Synaptics touchpad operations all perfectly OK.
Nothing related show up in the logs.


_EC-reading ACPI modules loaded_

Keyboard keys get stuck when EC is accessed for battery, temperature
etc.

Touchpad (mouse pointer) gets stuck for up to ca 5 seconds if I eg move
a window while EC data is read.

The logs are spammed when EC screws over i8042:
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.
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
[etc]

Messages about an unknown key show up (possibly in relation to a stuck
key). I don't have this on disk, so I'll copy the message from the bug
http://bugzilla.kernel.org/show_bug.cgi?id=9147
atkbd.c: Unknown key released (translated set 2, code 0xe0 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.


_EC-reading ACPI modules loaded. Command line option i8042.nomux used_

Keyboard keys _can_ get stuck when EC is accessed for battery,
temperature etc. Much less frequent than without i8042.nomux though.

Synaptics touchpad operations OK. Nothing related show up in the logs.


I know that some kind of US holiday is in effect presently, but please
make an effort to take a coordinated look at this afterwards. The
issues are so old and widespread that even the angels cry (I'm told).

PS. No, Dmitry. Lowering the report rate, eg psmouse.rate=40 does not
fix anything, as I tried on your suggestion already in August 2006.

Re: Laptop keyboard unusable when ACPI is active

[Len Brown]

On Friday 23 November 2007 02:44, Mats Johannesson wrote:

> The bad interaction between ACPI controlled EC (embedded controller)
> and the i8042 interrupt handler is theorized about in detail at OLPCs
> http://dev.laptop.org/ticket/2401 - almost at the end of that page.
> Thanks to Daniele C for the link.

huh?

I believe that the OLPC XO1 does not run in ACPI mode
and thus does not use the ACPI EC driver to talk to
the EC on their board.

Presumably they use some native embedded controller driver to
talk to their platform specific embedded controller.

I don't know why they call their interrupt an SCI.
Per above, it can't be an ACPI SCI.  Presumably they
call it that b/c their chipset documentation calls it
that too, on the (invalid) assumption that an ACPI-enabled
OS and firmware would be running on the hardware.

Please let me know if I'm wrong.

-Len

Re: Laptop keyboard unusable when ACPI is active

[Len Brown]

On Thursday 22 November 2007 02:24, legolas558@users.sourceforge.net wrote:

> It is also important to note that this bug always comes with bug 8740 
> http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also 
> an ACPI issue).

No, 8740 is not an ACPI issue.
http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2

-Len

Re: Laptop keyboard unusable when ACPI is active

[legolas558]

Len Brown ha scritto:
> On Thursday 22 November 2007 02:24, legolas558@users.sourceforge.net wrote:
>> It is also important to note that this bug always comes with bug 8740 
>> http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also 
>> an ACPI issue).
>>     
> No, 8740 is not an ACPI issue.
> http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2
>   
Sorry for the misleading statement; I no more think that it is an ACPI 
issue.
Although I am still curious about the reason of these bugs happening 
together even on different hardware configurations; maybe a side effect 
of the same kernel bug? No idea.

Best regards,
--
  Daniele C.

> -Len
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>