Bug 11428

Created attachment 17452 [details]
acpidump of Clevo D410J

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.

Hi, Marton
    Will you please confirm whether the LID event can be reported correctly after suspend/resume cycle on the working kernel?
    Thanks.

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.

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.

(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".

Hi, Marton
    Do you have an opportunity to try the debug patch in comment #4?
    Thanks.

(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.

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.

Created attachment 17483 [details]
kernel .config

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.

    

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.

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.

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

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.

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

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.

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.

(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.

Created attachment 17512 [details]
don't disable interrupt

please check if this patch changes anything...

(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. 

Created attachment 17520 [details]
dmesg with patch from comment #20 + DEBUG

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

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

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.

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!

Ok, thanks for testing!

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.

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.

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.

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.

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.

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 ).

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.

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.

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.

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?

(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 ?

(In reply to comment #38)
> Should I follow the description at
> http://www.lesswatts.org/projects/acpi/git.php ?
right

(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.

Marton,
You can just use Linus tree now...

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!

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.

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?

Elvis,
Please use -rc2 and patch in #11917.

(In reply to comment #45)
> Elvis,
> Please use -rc2 and patch in #11917.
> 

The patch fixes the issue for me. Thanks Alexey.

(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).

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.

the patch in bug #11917 comment #5 is replaced by commit d21cf3c16b1191f3154a51e0b20c82bf851cc553

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

(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