Bug 11428

Summary: [regression] LID switch events are no longer reported using /dev/input/event* && AC event can't be reported
Product: ACPI Reporter: Márton Németh (nm127)
Component: ECAssignee: Alexey Starikovskiy (astarikovskiy)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: acpi-bugzilla, astarikovskiy, el, trenn
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.26-rc3 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 10492    
Attachments: acpidump of Clevo D410J
try the debug patch
try the debug patch
git bisect log
dmesg
kernel .config
try the debug patch
dmesg with patch from comment #12
dmesg of 2.6.27-rc4+patch from comment #12 + DEBUG
try the debug patch
don't disable interrupt
dmesg with patch from comment #20 + DEBUG
dmesg + patch from comment #12 and comment #17 + DEBUG
dmesg 2.6.25-rc5 + DEBUG
don't disable interrupt
dmesg 2.6.27-rc4 + patch from comment #25 + comment #95 of bug #10724 + DEBUG
Patch 1/2 : try the debug patch in which the query_pending bit is cleared after processing EC notification event
Patch 2/2: try the debug patch
dmesg: 2.6.27-rc5 and the patch from comment #28
dmesg 2.6.27-rc5 + patched from comment #28 + patch from comment #29 +DEBUG
dmesg 2.6.27-rc5 + patch from bug #9998 comment #76
Patch 2/2: Switch GPE mode to polling mode when there is no EC GPE confirmation
dmesg of 2.6.27-rc6 + patch from comment #28 and comment #34
dmesg 2.6.27 + DEBUG
dmesg 2.6.28-rc1 + DEBUG
dmesg output

Description Márton Németh 2008-08-25 22:24:02 UTC
Latest working kernel version: 2.6.25
Earliest failing kernel version: 2.6.26-rc3 (bisecting in progress)
Distribution: Debian
Hardware Environment: Clevo D410J
Software Environment:
Problem Description:

Zhao Yakui wrote:
> > On Sat, 2008-08-23 at 23:43 +0200, Márton Németh wrote:
>> >> Hi,
>> >>
>> >> I am using Linux 2.6.27-rc4 on Clevo D410J laptop and the I can
>> >> query the LID switch state like this:
>> >>
>> >> # cat /proc/acpi/button/lid/LID/state
>> >> state:      open
>> >> # cat /proc/acpi/button/lid/LID/state
>> >> state:      closed
>> >>
>> >> If I check the event4, I get no events when the LID switch is pushed:
>> >>
>> >> # evtest /dev/input/event4
>> >> Input driver version is 1.0.0
>> >> Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0
>> >> Input device name: "Lid Switch"
>> >> Supported events:
>> >>   Event type 0 (Sync)
>> >>   Event type 5 (?)
>> >>     Event code 0 (?)
>> >> Testing ... (interrupt to exit)
> > It seems that the status of LID device is correct, but there is no LID
> > input event. Right?
> > Will you please enable the CONFIG_ACPI_DEBUG in kernel configuration and
> > boot the system with the option of "acpi.debug_layer=0x00090004
> > acpi.debug_level=0x01f"? 
> > After pressing the LID switch several times, please attach the output of
> > dmesg.
> > 
> > It will be great if you can attach the output of acpidump.
> > 
> > Of course you can open a new bug in bugzilla and attach the output of
> > dmesg, acpidump.
> > 
> > http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
> > 
> > Thanks.
>> >> The events are only reported if I suspend to RAM with "s2ram -f -p -s".

Steps to reproduce:

1. Execute "s2ram -f -p -s". Now the system suspends to RAM.
2. Push the LID switch and hold it down.
3. Wake the system with the POWER button.
4. After the system is up, release the LID switch to see the screen.
5. "evtest" reports the following line:

Event: time 1219526119.163805, type 5 (?), code 0 (?), value 1

6. Execute "s2ram -f -p -s" again.
7. Wake the system with the POWER button.
8. "evtest" reports the following line:

Event: time 1219526913.208803, type 5 (?), code 0 (?), value 0
Comment 1 Márton Németh 2008-08-25 22:28:07 UTC
Created attachment 17452 [details]
acpidump of Clevo D410J
Comment 2 ykzhao 2008-08-25 23:41:23 UTC
Created attachment 17454 [details]
try the debug patch

Will you please try the attached debug patch on the latest kernel and see whether the LID event can be triggered when the LID switch is pressed?

After the system is booted, please do the following test.
  a. kill the process who is using the /proc/acpi/event ( use the command of "lsof /proc/acpi/event" to get who is using the /proc/acpi/event)
  b. cat /proc/acpi/event 
  c. press the LID switch several times and see whether the LID event is triggered.
  
  Thanks.
Comment 3 ykzhao 2008-08-26 00:00:00 UTC
Hi, Marton
    Will you please confirm whether the LID event can be reported correctly after suspend/resume cycle on the working kernel?
    Thanks.
Comment 4 ykzhao 2008-08-26 17:48:01 UTC
Created attachment 17469 [details]
try the debug patch

Sorry that I attach the incorrect patch in comment #2.
Please try the debug patch and see whether the problem still exists.
Thanks.
Comment 5 Márton Németh 2008-08-27 00:04:10 UTC
Created attachment 17475 [details]
git bisect log

I finished the "git bisecting", the result is:

845625cdcb17119d5f6c5c8dbe586f2f36e8008a is first bad commit
commit 845625cdcb17119d5f6c5c8dbe586f2f36e8008a
Author: Alexey Starikovskiy <astarikovskiy@suse.de>
Date:   Fri Mar 21 17:07:03 2008 +0300

    ACPI: EC: Add poll timer
    
    If we can not use interrupt mode of EC for some reason, start polling
    EC for events periodically.
    
    Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>

:040000 040000 d41b954995d329c1bf0124c6d6f1ff0737b79be3 9672fef42204f83c18b1fae5f12ce5450b041896 M      drivers

This Clevo D410J had already a problem that there was not all interrupts received. The dmesg contains the following messages about this problem, which was solved with a previous patch:

[    0.124869] ACPI: EC: non-query interrupt received, switching to interrupt mode
[    0.624930] ACPI: EC: missing confirmations, switch off interrupt mode.
[    0.624930] ACPI: EC: non-query interrupt received, switching to interrupt mode
[    1.124933] ACPI: EC: missing write data confirmation, don't expect it any longer.

I'll provide the other asked information later, I ask you for some patience.
Comment 6 Márton Németh 2008-08-27 00:09:47 UTC
(In reply to comment #3)
>     Will you please confirm whether the LID event can be reported correctly
> after suspend/resume cycle on the working kernel?

I tested kernel 2.6.25-rc6-00295-ge6e82a3 which was the last step of the git bisecting. After resume from s2ram I can still see the events of the LID switch with the command "evtest /dev/input/event4".
Comment 7 ykzhao 2008-08-27 01:37:13 UTC
Hi, Marton
    Do you have an opportunity to try the debug patch in comment #4?
    Thanks.
Comment 8 Márton Németh 2008-08-27 08:20:43 UTC
(In reply to comment #7)
>     Do you have an opportunity to try the debug patch in comment #4?

I applied the patch from comment #4 to Linux kernel 2.6.27-rc4. I am now waiting that the compile finishes.

In the meantime I found bug #8459 which describes the ACPI interrupt problem we had with the Clevo D410J previously.
Comment 9 Márton Németh 2008-08-27 10:21:42 UTC
Created attachment 17482 [details]
dmesg

(In reply to comment #2)
> Will you please try the attached debug patch on the latest kernel and see
> whether the LID event can be triggered when the LID switch is pressed?
> 
> After the system is booted, please do the following test.
>   a. kill the process who is using the /proc/acpi/event ( use the command of
> "lsof /proc/acpi/event" to get who is using the /proc/acpi/event)
>   b. cat /proc/acpi/event 
>   c. press the LID switch several times and see whether the LID event is
> triggered.

(In reply to comment #4)
> Sorry that I attach the incorrect patch in comment #2.
> Please try the debug patch and see whether the problem still exists.

I patched 2.6.27-rc4 with the patch from comment #4. I compiled the kernel with CONFIG_ACPI_DEBUG=y configuration option. I booted with parameters "acpi.debug_layer=0x00090004 acpi.debug_level=0x01f".

The result is that I get several "BUG: scheduling while atomic" messages and when I press the LID switch and hold it down at least for 5 seconds, the event is not reported using "cat /proc/acpi/event". However, when I press the power buotton shortly this event is reported through "cat /proc/acpi/event" (acpid was killed before).

The "cat /proc/acpi/button/lid/LID/state" still works correctly, I guess this use a different mechanism.
Comment 10 Márton Németh 2008-08-27 10:22:37 UTC
Created attachment 17483 [details]
kernel .config
Comment 11 ykzhao 2008-08-27 18:49:28 UTC
Hi, Marton 
    Thanks for the confirm.  It seems that the laptop still can't work as what we expected after applying the patch in comment #4.(The warning message won't affect anything). Of course it can be confirmed that the problem is not related with the following commit :(In the debug patch of comment #4 the wakeup ability   is enabled again for the run_wake device.)
    > commit 729b2bdbfa19dd9be98dbd49caf2773b3271cc24
    > Author: Zhao Yakui <yakui.zhao@intel.com>
    > Date:   Wed Mar 19 13:26:54 2008 +0800
    > ACPI : Disable the device's ability to wake the sleeping system in the boot phase

   Can you double check whether the issue is caused by the following commit?
   >commit 845625cdcb17119d5f6c5c8dbe586f2f36e8008a
   >Author: Alexey Starikovskiy <astarikovskiy@suse.de>
   >Date:   Fri Mar 21 17:07:03 2008 +0300
   
    Thanks.

    
Comment 12 ykzhao 2008-08-27 18:58:06 UTC
Created attachment 17492 [details]
try the debug patch

Will you please try the debug patch and see whether the LID event can be triggered?
In this debug patch OS will try to avoid the bogus EC mode switch from interrupt to polling mode.

Thanks.
Comment 13 ykzhao 2008-08-27 19:41:50 UTC
Hi, Marton
    Will you please confirm whether the AC event can be reported on the kernel of 2.6.27-rc4?
    From the acpidump info it seems that the event of LID & AC & BAT0 is related with the EC. If there is no LID event on 2.6.27-rc4, in theory no AC event can be reported correctly when AC adapter is plugged/unplugged.
    Please boot the system with the option of "acpi.debug_layer=0x00090004 acpi.debug_level=0x01f" and do the following test:
  a. kill the process who is using the /proc/acpi/event
  b. cat /proc/acpi/event 
  c. plug/unplug the AC adapter several times

   After the test, please attach the output of dmesg.
   thanks.
Comment 14 Márton Németh 2008-08-27 22:16:51 UTC
Created attachment 17493 [details]
dmesg with patch from comment #12

(In reply to comment #12)
> Will you please try the debug patch and see whether the LID event can be
> triggered?
> In this debug patch OS will try to avoid the bogus EC mode switch from
> interrupt to polling mode.

(In reply to comment #13)
>     Will you please confirm whether the AC event can be reported on the
>     kernel
> of 2.6.27-rc4?

I applied the patch from comment #12 to a clear 2.6.27-rc4. I booted with parameters "acpi.debug_layer=0x00090004 acpi.debug_level=0x01f". I stopped acpid.

After this while "cat /proc/acpi/event" was running, I did the following steps:
1. I pressed the LID switch several times: event NOT reported
2. I pressed the POWER button several times: the event IS reported
3. I unplugged and plugged the AC cable: the event NOT reported
Comment 15 ykzhao 2008-08-27 22:56:49 UTC
Hi, Marton
    thanks for the confirmation. It seems that the event of AC can't be reported correctly  on 2.6.27-rc4. And the debug patch in comment #12 can't fix the issue.
    Will you please confirm whether the event can be reported correctly on 2.6.27-rc4 if the following commit is reverted?
    >commit 845625cdcb17119d5f6c5c8dbe586f2f36e8008a
    >Author: Alexey Starikovskiy <astarikovskiy@suse.de>  
    > Date:   Fri Mar 21 17:07:03 2008 +0300
     > ACPI: EC: Add poll timer
     
    Thanks.
Comment 16 Márton Németh 2008-08-27 22:57:36 UTC
Created attachment 17496 [details]
dmesg of 2.6.27-rc4+patch from comment #12 + DEBUG

I enabled the DEBUG option in drivers/acpi/ec.c. This will report the low level interrupts and communication.

I did the following steps:
1. stopped acpid
2. pressed POWER button 2 times: event reported in /proc/acpi/event
3. pressed the LID 2 times: event NOT reported
4. unplugged the AC two times: my KLaptop icon shows that the I switch between AC and battery, but the event is not reported through /proc/acpi/event
5. pressed the POWER button again
6. pressed the LID switch and checked with "cat /proc/acpi/button/lid/LID/state" if the change is detected by software and yes, it is detected, however no event was reported through /proc/acpi/event
Comment 17 ykzhao 2008-08-28 02:58:07 UTC
Created attachment 17502 [details]
try the debug patch 

   thanks for the test. 
   From the log in comment #16 it seems that the SCI_EVT bit(5) in status register is always unset, which indicates that no _Qxx method will be executed. In such case there will be no AC/LID event. 
   
    Will you please try the attached debug and do the similar test in comment #16?(The patch in comment #12 is still needed).
   Thanks.
Comment 18 ykzhao 2008-08-28 03:02:13 UTC
Hi,Marton
   Will you please enable the DEBUG option in driver/acpi/ec on the 2.6.25-rc5 kernel and do the following test?
   1. stopped acpid
2. pressed POWER button 2 times: event reported in /proc/acpi/event
3. pressed the LID 2 times:
4. unplugged the AC two times:

   Thanks.
Comment 19 Márton Németh 2008-08-28 11:37:30 UTC
(In reply to comment #15)
>     Will you please confirm whether the event can be reported correctly on
> 2.6.27-rc4 if the following commit is reverted?
>     >commit 845625cdcb17119d5f6c5c8dbe586f2f36e8008a
>     >Author: Alexey Starikovskiy <astarikovskiy@suse.de>  
>     > Date:   Fri Mar 21 17:07:03 2008 +0300
>      > ACPI: EC: Add poll timer

I'm afraid the patch of the commit 845625cdcb17119d5f6c5c8dbe586f2f36e8008a cannot be easily reverted. Maybe I need to check the patch by hand and modify 2.6.27-rc4 line by line. If you can help me to create a patch against 2.6.27-rc4 which can revert the mentioned commit I can try it more easily.
Comment 20 Alexey Starikovskiy 2008-08-28 13:47:23 UTC
Created attachment 17512 [details]
don't disable interrupt

please check if this patch changes anything...
Comment 21 Márton Németh 2008-08-28 22:19:21 UTC
(In reply to comment #20)
> please check if this patch changes anything...

Yes, it does. I did the followings:

- applied patch from comment #20 on a clean 2.6.27-rc4.
- enabled the DEBUG option in drivers/acpi/ec.c
- compiled the kernel
- booted into single user mode with parameters "acpi.debug_layer=0x00090004 acpi.debug_level=0x01f" (acpid is not running)
- pressed the POWER button two times: event reported through /proc/acpi/event
- pressed the LID switch two times: event reported through /proc/acpi/event
- unplugged and plugged the AC two times: event reported through /proc/acpi/event

The other thing I recognised is that I get the same problem what I had before in bug #8459, namely I can get the current temperature value very slowly, usually between 1.5sec and 5.0sec.

$ time cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             47 C

real    0m4.749s
user    0m0.001s
sys     0m0.003s

I repeated the test when I boot to normal mode: the POWER and LID switch events are reported. For the AC events to be reported correctly through /proc/acpi/event I first need to stop the KLaptop applet. 
Comment 22 Márton Németh 2008-08-28 22:23:14 UTC
Created attachment 17520 [details]
dmesg with patch from comment #20 + DEBUG
Comment 23 Márton Németh 2008-08-28 22:55:04 UTC
Created attachment 17521 [details]
dmesg + patch from comment #12 and comment #17 + DEBUG

(In reply to comment #17)
>     Will you please try the attached debug and do the similar test in comment
> #16?(The patch in comment #12 is still needed).

This combination does not change anything. I did the followings:

- applied patch from comment #12 and comment #17 on a clean 2.6.27-rc4.
- enabled the DEBUG option in drivers/acpi/ec.c
- compiled the kernel
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- pressed the POWER button two times: event reported through /proc/acpi/event
- pressed the LID switch two times: event NOT reported through /proc/acpi/event
- unplugged and plugged the AC two times: event NOT reported through
/proc/acpi/event
- pressed the POWER button again two times: event reported through /proc/acpi/event

In this case I can read the temperature sensor quite fast:
$ time cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             48 C

real    0m0.014s
user    0m0.000s
sys     0m0.004s
Comment 24 Márton Németh 2008-08-29 00:04:09 UTC
Created attachment 17522 [details]
dmesg 2.6.25-rc5 + DEBUG

(In reply to comment #18)
>    Will you please enable the DEBUG option in driver/acpi/ec on the
>    2.6.25-rc5
> kernel and do the following test?

The 2.6.25-rc5 seems to work fine. I did the following test:

- took the 2.6.25-rc5 and enabled the DEBUG option in drivers/acpi/ec.c
- compiled the kernel
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- pressed the POWER button two times: event reported through /proc/acpi/event
- pressed the LID switch two times: event reported through /proc/acpi/event
- unplugged and plugged the AC two times: event reported through
/proc/acpi/event

I also can get the temperature value with good speed (this is not included in the dmesg):
$ time cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             43 C

real    0m0.005s
user    0m0.000s
sys     0m0.005s
Comment 25 Alexey Starikovskiy 2008-08-29 00:39:12 UTC
Created attachment 17524 [details]
don't disable interrupt

This patch should be applied on top of last patch to 10724, but in your case it should work alone as well.
Comment 26 Márton Németh 2008-08-29 10:26:29 UTC
Created attachment 17533 [details]
dmesg 2.6.27-rc4 + patch from comment #25 + comment #95 of bug #10724 + DEBUG

(In reply to comment #25)
> This patch should be applied on top of last patch to 10724, but in your case
> it
> should work alone as well.

This patch cannot work alone because it removes the function ec_switch_to_poll_mode() which is used by other places as well which are only removed by patch at comment #95 of bug #10724 ( http://bugzilla.kernel.org/attachment.cgi?id=17355 ).

I did the following things:
- patched 2.6.27-rc4 with the patch from comment #25
- also applied the patch from comment #95 of bug #10724 ( http://bugzilla.kernel.org/attachment.cgi?id=17355 )
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid

Results:
POWER button events, AC events and LID events are reported through /proc/acpi/event.
I can also read out the temperature value with good speed:
$ time cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             49 C

real    0m0.025s
user    0m0.000s
sys     0m0.005s

Thank you for your work!
Comment 27 Alexey Starikovskiy 2008-08-29 10:45:25 UTC
Ok, thanks for testing!
Comment 28 ykzhao 2008-09-03 23:09:05 UTC
Created attachment 17607 [details]
Patch 1/2 : try the debug patch in which the query_pending bit is cleared after processing EC notification event

Will you please try the debug patch on the latest kernel(2.6.27-rc5)?
Thanks.
Comment 29 ykzhao 2008-09-03 23:19:59 UTC
Created attachment 17608 [details]
Patch 2/2: try the debug patch 

Hi,Marton 
   Do you have opportunity to try the above two patches on the latest kernel (2.6.27-rc5) and see whether the LID/AC/Battery event can be reported correctly?
   In the patch 1 the query_pending bit will be cleared only after processing the EC notification event.
   In the patch 2 the EC will work in polling mode when EC internal register is accessed.  The EC GPE interrupt handler is only to process the EC notification event.
   
   Thanks.
Comment 30 Márton Németh 2008-09-04 15:04:27 UTC
Created attachment 17624 [details]
dmesg: 2.6.27-rc5 and the patch from comment #28

(In reply to comment #28)
> Created an attachment (id=17607) [details]
> Patch 1/2 : try the debug patch in which the query_pending bit is cleared
> after
> processing EC notification event
> 
> Will you please try the debug patch on the latest kernel(2.6.27-rc5)?

I did the following things:
- patched 2.6.27-rc5 with the patch from comment #28
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- executed "cat /proc/acpi/event"
- pressed LID two times
- pressed POWER button two times
- unplugged and plugged AC two times

Results:
LID and AC events are NOT reported. POWER button events are reported.
Comment 31 Márton Németh 2008-09-04 15:19:31 UTC
Created attachment 17625 [details]
dmesg 2.6.27-rc5 + patched from comment #28 + patch from comment #29 +DEBUG

(In reply to comment #29)
> Created an attachment (id=17608) [details]
> Patch 2/2: try the debug patch 
> 
> Hi,Marton 
>    Do you have opportunity to try the above two patches on the latest kernel
> (2.6.27-rc5) and see whether the LID/AC/Battery event can be reported
> correctly?
>    In the patch 1 the query_pending bit will be cleared only after processing
> the EC notification event.
>    In the patch 2 the EC will work in polling mode when EC internal register
>    is
> accessed.  The EC GPE interrupt handler is only to process the EC
> notification
> event.

I did the following things:
- patched 2.6.27-rc5 with the patch from comment #28
- also applied patch from comment #29
- enabled DEBUG in drivers/acpi/ec.c
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- executed "cat /proc/acpi/event"
- pressed POWER button two times
- pressed LID two times
- unplugged and plugged AC two times
- pressed POWER button two times

Results:
All events are reported through /proc/acpi/event.
Comment 32 ykzhao 2008-09-07 19:18:53 UTC
Hi, Marton
   Do you have an opportunity to try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=9998#76 
and see whether the system can work well?
   Thanks.
Comment 33 Márton Németh 2008-09-08 14:00:47 UTC
Created attachment 17687 [details]
dmesg 2.6.27-rc5 + patch from bug #9998 comment #76

(In reply to comment #32)
>    Do you have an opportunity to try the debug patch in
> http://bugzilla.kernel.org/show_bug.cgi?id=9998#76 
> and see whether the system can work well?

The POWER, LID and AC events are reported through /proc/acpi/event with 2.6.27-rc5 + the patch from bug #9998 comment #76 ( http://bugzilla.kernel.org/attachment.cgi?id=17620&action=view ).
Comment 34 ykzhao 2008-09-11 23:17:05 UTC
Created attachment 17740 [details]
Patch 2/2: Switch GPE mode to polling mode when there is no EC GPE confirmation

Hi, Marton
    Do you have opportunity to try the updated patch on the latest kernel(2.6.27-rc5) and see whether the ACPI event can be reported correctly?
    Of course the patch in comment #28 is also needed.

    In this attached patch EC driver will work in GPE mode. When there is no EC GPE confirmation in some EC transactions, it will be switched to polling mode.
But EC GPE is still enabled.
    Thanks for your test.
Comment 35 Márton Németh 2008-09-13 01:25:49 UTC
Created attachment 17758 [details]
dmesg of 2.6.27-rc6 + patch from comment #28 and comment #34

(In reply to comment #34)
>     Do you have opportunity to try the updated patch on the latest
> kernel(2.6.27-rc5) and see whether the ACPI event can be reported correctly?
>     Of course the patch in comment #28 is also needed.

I tested first the current latest kernel: 2.6.27-rc6. The LID and AC events are not reported in this version.

Then I did the following things:
- patched 2.6.27-rc6 with the patch from comment #28
- also applied patch from comment #34
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- executed "cat /proc/acpi/event"
- pressed POWER button two times
- pressed LID two times
- unplugged and plugged AC two times
- pressed the SLEEP button two times
- pressed POWER button two times

Results:
All events are reported through /proc/acpi/event with this patched version.
Comment 36 Len Brown 2008-10-16 17:20:06 UTC
these patches do not apply to the latest ec driver in the acpi tree.

please test the latest ec driver in the acpi tree, (and linux-next).
re-opening.
Comment 37 Márton Németh 2008-10-19 00:16:58 UTC
Created attachment 18370 [details]
dmesg 2.6.27 + DEBUG

(In reply to comment #36)
> these patches do not apply to the latest ec driver in the acpi tree.
> 
> please test the latest ec driver in the acpi tree, (and linux-next).
> re-opening.

I tested 2.6.27, The LID, AC and SLEEP events are not reported in this version.

Then I did the following things:
- enabled DEBUG in /drivers/acpi/ec.c
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- stopped hald
- executed "cat /proc/acpi/event"
- pressed POWER button four times
- pressed LID two times
- unplugged and plugged AC two times
- pressed the SLEEP button four times

Result: only the POWER button event is reported.


How can I get the latest acpi tree?
Comment 38 Márton Németh 2008-10-19 00:27:03 UTC
(In reply to comment #37)
> (In reply to comment #36)
> > these patches do not apply to the latest ec driver in the acpi tree.
> > 
> > please test the latest ec driver in the acpi tree, (and linux-next).
> > re-opening.
>
> How can I get the latest acpi tree?
> 
Should I follow the description at http://www.lesswatts.org/projects/acpi/git.php ?
Comment 39 Alexey Starikovskiy 2008-10-19 03:12:24 UTC
(In reply to comment #38)
> Should I follow the description at
> http://www.lesswatts.org/projects/acpi/git.php ?
right
Comment 40 Márton Németh 2008-10-20 23:10:29 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > Should I follow the description at
> > http://www.lesswatts.org/projects/acpi/git.php ?
> right

I have some difficulties getting the right acpi tree. What I get is the same as the original linux-2.6.27. I did the following steps:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
$ git clone --reference linux-2.6\
  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
$ cd linux-acpi-2.6
$ git branch -r
  origin/HEAD
  origin/acpica
  origin/linus
  origin/release
  origin/suspend
  origin/test
$ git log
commit 3fa8749e584b55f1180411ab1b51117190bac1e5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Oct 9 15:13:53 2008 -0700

    Linux 2.6.27

[...]

I guess I am at origin/HEAD. Should I choose a different branch?
The last commit I see in "git log" is 3fa8749e584b55f1180411ab1b51117190bac1e5, so I guess something went wrong at my side, so I don't get the acpi tree.
Comment 41 Alexey Starikovskiy 2008-10-29 13:14:20 UTC
Marton,
You can just use Linus tree now...
Comment 42 Márton Németh 2008-11-01 00:42:40 UTC
Created attachment 18562 [details]
dmesg 2.6.28-rc1 + DEBUG

I tested Linux 2.6.28-rc1 and it seems to work correctly.

I did the following things:
- enabled DEBUG in /drivers/acpi/ec.c
- booted into normal mode with parameters "acpi.debug_layer=0x00090004
acpi.debug_level=0x01f"
- stopped acpid
- stopped hald
- executed "cat /proc/acpi/event"
- pressed POWER button two times
- pressed LID two times
- unplugged and plugged AC two times
- pressed the SLEEP button two times
- pressed POWER button two times

Result: all of the POWER, LID, AC and SLEEP events are reported.

Thank you for your work!
Comment 43 Elvis Pranskevichus 2008-11-02 10:14:01 UTC
Guys, 2.6.28-rc1 totally breaks things on my laptop. None of the events get reported. So I guess, changes that helped Marton created a regression on my end. I'm collecting the debug information now. If you can point to a commit to revert and test, that would be great.
Comment 44 Elvis Pranskevichus 2008-11-02 12:21:49 UTC
Created attachment 18597 [details]
dmesg output

Ok, so I booted with debug logging enabled and triggered all buttons, POWER, then SLEEP, then LID and then AC. All I get in response in the log is:

ACPI: EC: ~~~> interrupt
ACPI: EC: ---> status = 0x20

Now, I browsed git log -- drivers/acpi/ a bit, and I see that reverting ec.c changes would not be easy since it's got mangled by a series of commits later. Any ideas how to better debug this one?
Comment 45 Alexey Starikovskiy 2008-11-02 12:51:16 UTC
Elvis,
Please use -rc2 and patch in #11917.
Comment 46 Elvis Pranskevichus 2008-11-02 13:10:01 UTC
(In reply to comment #45)
> Elvis,
> Please use -rc2 and patch in #11917.
> 

The patch fixes the issue for me. Thanks Alexey.
Comment 47 Márton Németh 2008-11-03 00:06:50 UTC
(In reply to comment #46)
> (In reply to comment #45)
> > Please use -rc2 and patch in #11917.
> The patch fixes the issue for me. Thanks Alexey.

Linux 2.6.28-rc3 + the patch from bug #11917 comment #5 works for me correclty (POWER, LID, AC and SLEEP events are reported).
Comment 48 Zhang Rui 2009-01-04 19:27:09 UTC
hmm, we should close this bug, shouldn't we?
Marton and Elvis,
please re-open it if the problem still exists in the latest upstream kernel.
Comment 49 Zhang Rui 2009-01-04 19:29:14 UTC
the patch in bug #11917 comment #5 is replaced by commit d21cf3c16b1191f3154a51e0b20c82bf851cc553
Comment 50 Márton Németh 2009-01-04 21:42:04 UTC
I tested 2.6.28 and it is working for me. I tested the following buttons:
 - button/power PWRF
 - button/sleep SLPB
 - button/lid LID
 - video VGA
Comment 51 Elvis Pranskevichus 2009-01-04 22:13:10 UTC
(In reply to comment #48)
> hmm, we should close this bug, shouldn't we?
> Marton and Elvis,
> please re-open it if the problem still exists in the latest upstream kernel.
> 

Yes. 2.6.28 works perfectly in this regard. The bug can be closed. Thank you