Bug 11857 - no lid switch, ac adapter, or power button events - Sony VAIO VGN-SZ650N
no lid switch, ac adapter, or power button events - Sony VAIO VGN-SZ650N
Status: CLOSED DUPLICATE of bug 1752
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts
All Linux
: P1 normal
Assigned To: ykzhao
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-25 20:40 UTC by Sumant Oemrawsingh
Modified: 2009-04-01 05:27 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.25
Tree: Mainline
Regression: No


Attachments
output of acpidump (171.12 KB, application/octet-stream)
2008-10-25 20:42 UTC, Sumant Oemrawsingh
Details
Original DSDT (29.87 KB, application/octet-stream)
2008-10-25 20:43 UTC, Sumant Oemrawsingh
Details
Output of dmesg (7.55 KB, application/octet-stream)
2008-10-25 20:44 UTC, Sumant Oemrawsingh
Details
try the custom DSDT, in which the ECOK flag will be initialized correctly. (274.92 KB, patch)
2008-10-26 20:07 UTC, ykzhao
Details | Diff
output of dmesg with modified DSDT, after plug/unplug adapter test (28.23 KB, application/octet-stream)
2008-11-02 17:10 UTC, Sumant Oemrawsingh
Details
Output of dmesg unmodified DSDT, after plug/unplug adapter test (intel video card) (26.94 KB, application/octet-stream)
2008-11-02 17:22 UTC, Sumant Oemrawsingh
Details
Original DSDT (stamina mode, intel video card) (29.87 KB, application/octet-stream)
2008-11-02 17:26 UTC, Sumant Oemrawsingh
Details
acpi interrupts after pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27 (2.09 KB, application/octet-stream)
2008-11-11 10:25 UTC, Balazs Sipos
Details
acpi interrupts before pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27 (2.09 KB, application/octet-stream)
2008-11-11 10:26 UTC, Balazs Sipos
Details
dmesg output on Sony VGB-SZ61WN laptop kernel 2.6.27 (57.82 KB, application/octet-stream)
2008-11-11 10:27 UTC, Balazs Sipos
Details
acpi event log during pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27 (70 bytes, application/octet-stream)
2008-11-11 10:27 UTC, Balazs Sipos
Details
ACPI interrupts before plug/unplug (1.51 KB, application/octet-stream)
2008-11-12 21:05 UTC, Sumant Oemrawsingh
Details
Acpi event log during plug/unplug (70 bytes, application/octet-stream)
2008-11-12 21:06 UTC, Sumant Oemrawsingh
Details
ACPI interrupts after plug/unplug (1.51 KB, application/octet-stream)
2008-11-12 21:07 UTC, Sumant Oemrawsingh
Details
dmesg after plug/unplug (27.37 KB, application/octet-stream)
2008-11-12 21:07 UTC, Sumant Oemrawsingh
Details
lspci output (31.34 KB, application/octet-stream)
2008-11-18 06:24 UTC, Balazs Sipos
Details
use the attached tool to read/write some I/O ports (2.47 KB, patch)
2008-11-24 01:36 UTC, ykzhao
Details | Diff
tests of comment #26 without custom dsdt (1.51 KB, text/plain)
2008-12-13 03:56 UTC, Sumant Oemrawsingh
Details
tests of comment #26 without custom dsdt (event_log) (944 bytes, application/octet-stream)
2008-12-13 03:57 UTC, Sumant Oemrawsingh
Details
tests of comment #26 without custom dsdt (acpi_int_after) (1.51 KB, text/plain)
2008-12-13 03:58 UTC, Sumant Oemrawsingh
Details
[debug patch]: the current mode is ignored while ACPI/legacy transition (808 bytes, patch)
2008-12-15 19:32 UTC, ykzhao
Details | Diff
output of lspci after debug patch (30.98 KB, text/plain)
2008-12-16 01:41 UTC, Sumant Oemrawsingh
Details
test of comment #26 with acpi_osi=!Linux (acpi_int_before) (1.51 KB, text/plain)
2009-01-01 18:16 UTC, Sumant Oemrawsingh
Details
test of comment #26 with acpi_osi=!Linux (event_log) (1.14 KB, text/plain)
2009-01-01 18:17 UTC, Sumant Oemrawsingh
Details
test of comment #26 with acpi_osi=!Linux (acpi_int_after) (1.51 KB, text/plain)
2009-01-01 18:17 UTC, Sumant Oemrawsingh
Details
acpi_int_before (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters) (1.51 KB, text/plain)
2009-01-04 06:26 UTC, Sumant Oemrawsingh
Details
event_log (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters) (844 bytes, text/plain)
2009-01-04 06:27 UTC, Sumant Oemrawsingh
Details
acpi_int_after (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters) (1.51 KB, text/plain)
2009-01-04 06:27 UTC, Sumant Oemrawsingh
Details
lspci (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters) (30.98 KB, text/plain)
2009-01-04 06:28 UTC, Sumant Oemrawsingh
Details
lspci (no custom DSDT, no patches, acpi_osi=!Linux) (30.98 KB, text/plain)
2009-01-04 06:41 UTC, Sumant Oemrawsingh
Details
call the _WAK object after ACPI full initialization (933 bytes, patch)
2009-03-04 18:19 UTC, ykzhao
Details | Diff

Description Sumant Oemrawsingh 2008-10-25 20:40:59 UTC
Latest working kernel version: None
Earliest failing kernel version:
Distribution: Gentoo
Hardware Environment: Sony VAIO VGN-SZ650N
Software Environment: kernel 2.6.25
Problem Description: The following things don't generate events (as tried with acpi_listen):
* LID button (but /proc/acpi/button/lid/LID0/state reports correct state)
* ACAD ac adapter (but /proc/acpi/ac_adapter/ACAD/state reports correct state)
* Power button

Interestingly, removing and putting back the battery does generate ACPI events.

I have tried using kernel 2.6.26 as well (both vanilla and gentoo), but something else in my setup broke with that kernel, so I switched back to 2.6.25. This laptop has two video cards (speed profile uses an nvidia card, stamina profile uses an intel card), and it does not matter which one I use. With the nvidia card, I tried with and without the nvidia binary driver.

I have also tried to fix the DSDT (from many errors to zero) but that did not fix anything. The fixed DSDT actually broke the thermal zone when switching videocard from nvidia to intel (detected always too hot). I also tried setting the acpi name to one of the Windows strings found in the DSDT, and I've tried setting acpi_apic_instance=2, but none made any difference.

So at this moment, I wrote a shell script, that runs as a service, that polls the two proc files and switches to powersave or suspends accordingly. But this should not be the way to go.

Steps to reproduce: Always
Comment 1 Sumant Oemrawsingh 2008-10-25 20:42:07 UTC
Created attachment 18444 [details]
output of acpidump

Output of acpidump
Comment 2 Sumant Oemrawsingh 2008-10-25 20:43:17 UTC
Created attachment 18445 [details]
Original DSDT

The original DSDT
Comment 3 Sumant Oemrawsingh 2008-10-25 20:44:12 UTC
Created attachment 18446 [details]
Output of dmesg

Output of dmesg | grep -i acpi
Comment 4 ykzhao 2008-10-26 20:07:24 UTC
Created attachment 18461 [details]
try the custom DSDT, in which the ECOK flag will be initialized correctly.

Hi, Sumant
    From the acpidump it seems that there exists the following error.  There exists the EC device. But after the EC is initialized, the ECOK flag is still Zero. 
    >Method (_REG, 2, NotSerialized)
                    {
                        If (LEqual (Arg0, 0x03)) {                                }
                    }
     Will you please try the custom DSDT and see whether the problem still exists? In the custom DSDT the ECOK flag will be initialized when the EC _REG object is evaluated.
     How to use the custom DSDT can be found in 
    http://www.lesswatts.org/projects/acpi/faq.php
    Thanks.
Comment 5 ykzhao 2008-10-26 21:01:09 UTC
Will you please do the following test?
   a. enable the "CONFIG_ACPI_DEBUG" in kernel configuration
   b. kill the process which is using the /proc/acpi/event after the system is booted. ( please use the command of "lsof /proc/acpi/event " to get the process id which is using the /proc/acpi/event)
   c. echo 0x0009004 > /sys/module/acpi/parameters/debug_layer ; echo 0x001f > /sys/modules/acpi/parameters/debug_level
   d. cat /proc/acpi/event and plug/unplug AC adaptor several times. Please confirm whether the ACPI event is triggered.
   e. after step D is finished, please press "CTRL+C" and attach the output of dmesg.

   Thanks.
Comment 6 Sumant Oemrawsingh 2008-11-02 16:58:34 UTC
(In reply to comment #4)
> Created an attachment (id=18461) [details]
> try the custom DSDT, in which the ECOK flag will be initialized correctly.

Sorry for the late reply. The custom DSDT does compile cleanly, but does not to fix anything in speed mode (i.e. with the nVidia video card). Both acpi_listen and directly cat-ing /proc/acpi/event reveal no additional events.

Also, with the custom DSDT, another problem exists, as I also mentioned in my first post. In stamina mode (i.e. with the intel video card), upon boot, I get messages that the temperature exceeds the safe temperature (I think it says the value is 255 or something), and immediately shuts down again, before even allowing a login. I could attach the dmesg, if I knew how to save it before it shuts down.

Thanks for the help.
Comment 7 Sumant Oemrawsingh 2008-11-02 17:10:12 UTC
Created attachment 18599 [details]
output of dmesg with modified DSDT, after plug/unplug adapter test

cat /proc/acpi/event shows nothing when unplugging/plugging the AC adapter.

This is the output of dmesg after booting in speed mode (nvidia video card), while using the custom DSDT, and after performing the cat test.

I'll recompile a kernel without the custom DSDT, reboot in stamina mode (intel video card) and repeat the same in that mode, but I doubt very much anything will be shown.

How is it possible that files under /proc do show the proper state of the ac adapter and the lid switch, but sysfs doesn't? Is it a difference that proc asks the state when the file is accessed, while sysfs depends on the state being reported by the hardware?
Comment 8 Sumant Oemrawsingh 2008-11-02 17:22:04 UTC
Created attachment 18600 [details]
Output of dmesg unmodified DSDT, after plug/unplug adapter test (intel video card)

Same as previous, but now with the original DSDT and booted with the intel video card (see below for DSDT). again, no output after cat /proc/acpi/event and plugging/unplugging adapter.
Comment 9 Sumant Oemrawsingh 2008-11-02 17:26:12 UTC
Created attachment 18601 [details]
Original DSDT (stamina mode, intel video card)

So while in stamina mode, I took a look at the original DSDT by doing cat /proc/acpi/dsdt and compared it to the original DSDT that was taken while in speed mode (attachment 18445 [details]). In stamina mode (intel video card), the DSDT seems to be different, so here's that one too. So there's the reason that the modified DSDT didn't work in stamina mode, and resulted in an immediate shutdown.

If possible, it would be nice to get all working under both modes, but acpi events are more important under stamina mode (with intel card) than speed mode (nvidia card), since I use the former when on the move, and the latter when playing games at home :)
Comment 10 ykzhao 2008-11-06 08:06:33 UTC
Hi, Sumant
    Will you please enable the "CONFIG_ACPI_DEBUG" in kernel configuration and do the following test on the 2.6.25 kernel?
    a. echo 0x010004 > /sys/module/acpi/parameters/debug_layer ; echo 0x1f > /sys/module/acpi/parameters/debug_level
    b. kill the process which is using the /proc/acpi/event (please use the command of "lsof /proc/acpi/event" to get the process using /proc/acpi/event) && grep . /sys/firmware/acpi/interrupts/* > acpi_int_before
    c. cat /proc/acpi/event > /root/event_log and after the step d, e,f is finished, please press "CTRL + C" .
    d .plug/unplug the AC adapter several times
    e. remove the battery and insert it again.
    f. press the power button
    g. grep . /sys/firmware/acpi/interrupts/* > acpi_int_after

    After the test, please attach the output of event_log, dmesg, acpi_int_before, acpi_int_after.
    Thanks. 

    
Comment 11 Balazs Sipos 2008-11-11 10:21:58 UTC
Hi

I have a bit different system Sony VGN-SZ61WN, but I think is almost similar to the above mentioned one. That is a system with the original DSDT tables, and the kernel is 2.6.27. 
I did the requested, and I attach the results.
I hope they will be useful

Sipi
Comment 12 Balazs Sipos 2008-11-11 10:25:43 UTC
Created attachment 18804 [details]
acpi interrupts after pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27
Comment 13 Balazs Sipos 2008-11-11 10:26:29 UTC
Created attachment 18805 [details]
acpi interrupts before pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27
Comment 14 Balazs Sipos 2008-11-11 10:27:04 UTC
Created attachment 18807 [details]
dmesg output on Sony VGB-SZ61WN laptop kernel 2.6.27
Comment 15 Balazs Sipos 2008-11-11 10:27:40 UTC
Created attachment 18808 [details]
acpi event log during pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27
Comment 16 Len Brown 2008-11-11 23:15:01 UTC
any difference with the sony-laptop module excluded from the kernel?
Comment 17 Balazs Sipos 2008-11-12 03:10:17 UTC
In that case the event log is empty,
in the interrupts 
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0  disable
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0     enable
(Here I only marked the changes)
Comment 18 Sumant Oemrawsingh 2008-11-12 21:03:57 UTC
(In reply to comment #10)
> Hi, Sumant
(...)
>     After the test, please attach the output of event_log, dmesg,
> acpi_int_before, acpi_int_after.
>     Thanks. 

I did the test you wanted, but you probably already got what you needed to know. I'll just put this up for future reference.

Note that these tests were done using the stamina mode.

Comment 19 Sumant Oemrawsingh 2008-11-12 21:05:45 UTC
Created attachment 18840 [details]
ACPI interrupts before plug/unplug
Comment 20 Sumant Oemrawsingh 2008-11-12 21:06:31 UTC
Created attachment 18841 [details]
Acpi event log during plug/unplug
Comment 21 Sumant Oemrawsingh 2008-11-12 21:07:06 UTC
Created attachment 18842 [details]
ACPI interrupts after plug/unplug
Comment 22 Sumant Oemrawsingh 2008-11-12 21:07:29 UTC
Created attachment 18843 [details]
dmesg after plug/unplug
Comment 23 ykzhao 2008-11-12 23:13:28 UTC
Hi, Sumant & Balazs
    Thanks for the test.
    From the event log it seems that the event can be reported when battery is removed and inserted. In fact the battery event is reported by sony-laptop platform driver(drivers/misc/sony-laptop). It is not reported by the generic battery driver(drivers/acpi/battery). 

    From the test result it seems that no ACPI interrupt is triggered after plug/unluging the AC adaptor. And there is no ACPI interrupt even when power button is pressed. NO EC interrupt/NO fixed power button. 
    It is very strange.
    From the acpidump it seems that the fixed power button is not supported accoding to the FADT flag bit. 
    >Power button is generic : 1
    In such case it is declared as the generic device power button. And the corresponding GPE number is 0x18. But unfortunately there is no thing to do in the _L18 object.
    >Method (_L18, 0, NotSerialized)
    >   {
    >   }
    
     But very strange is why there is no ACPI interrupt when pluging/unpluging the AC adaptor. 
      
    
Comment 24 ykzhao 2008-11-12 23:17:23 UTC
Will you please try the following boot option of "acpi_sci=low" and see whether the acpi event can be reported when plug/unplug AC adaptor? In the current kernel the trigger type of acpi sci is high, level. 

    Will you please also attach the output of lspci -vxxx?
    Thanks.
    
Comment 25 Balazs Sipos 2008-11-18 06:24:02 UTC
Created attachment 18912 [details]
lspci output

I tried what you asked (acpi_sci=low), and the event log is still empty. I attach the result of the lspci -vxxx
Comment 26 ykzhao 2008-11-18 18:54:49 UTC
Hi, Balazs
    thanks for the test.
    From the acpidump we know that the GPE of EC controller is 0x17, which is routed to the GPIO7. But from the lspci it seems that GPI routing bit for GPIO7 is zero, which means that no ACPI interrupt can be triggered.
     >00 = No effect.
     >01 = SMI# (if corresponding ALT_GPI_SMI_EN bit is also set)
     >10 = SCI (if corresponding GPE0_EN bit is also set)
     >11 = Reserved

    Will you please try the custom DSDT in comment #3 and do the following test?
    a. setpci -s 00:00:1f.0 b9.b=0x80
    b. echo 0x010004 > /sys/module/acpi/parameters/debug_layer ; echo 0x1f >
/sys/module/acpi/parameters/debug_level
    c. kill the process which is using the /proc/acpi/event (please use the
command of "lsof /proc/acpi/event" to get the process using /proc/acpi/event)
&& grep . /sys/firmware/acpi/interrupts/* > acpi_int_before
    d. cat /proc/acpi/event > /root/event_log and after the step d, e,f is
finished, please press "CTRL + C" .
    e .plug/unplug the AC adapter several times
    f. press the power button
    g. grep . /sys/firmware/acpi/interrupts/* > acpi_int_after

    After the test, please attach the above output.
   Thanks.
Comment 27 ykzhao 2008-11-18 18:58:50 UTC
Hi, Balazs
    Will you please confirm whether the box can work well on windows?
    thanks.
Comment 28 Balazs Sipos 2008-11-19 05:42:22 UTC
(In reply to comment #27)
> Hi, Balazs
>     Will you please confirm whether the box can work well on windows?
>     thanks.
> 
Hi ykzhao,
   I rebooted my computer in windows and there everything (power button, AC plug, lid switch) works perfectly.
Comment 29 ykzhao 2008-11-20 01:02:09 UTC
Thanks for the test. From the test it seems that windows can work well on the box but Linux can't work well. I will continue to investigate why Linux can't work well. 

   Will you please do the test as mentioned in comment #26? 
   Thanks.

    
Comment 30 ykzhao 2008-11-24 01:36:42 UTC
Created attachment 18998 [details]
use the attached tool to read/write some I/O ports

Will you please boot the system with ACPI disabled(by adding the boot option of "acpi=off") and do the following test?
    a. lspci -vxxx > lspci_before, 
    b. read the 0x1004 I/O port ( ./ior --addr 0x10004 --width 16)
    c. write 0xF1 to 0xB2 I/O port ( ./iow --addr 0xb2 --width 8 --value 0xF0)
    d. lspci -vxxx >lspci_after  , read the 0x1004 I/O port

   After the test, please attach the above output.
   Thanks.
Comment 31 ykzhao 2008-12-03 22:10:37 UTC
HI, Balazs
    Will you please do the above test mentioned in comment #26, #30 and attach the output ?
    Will you please also attach the output of acpidump?
    thanks.
Comment 32 Sumant Oemrawsingh 2008-12-04 13:34:47 UTC
(In reply to comment #30)
> Created an attachment (id=18998) [details]
> use the attached tool to read/write some I/O ports
> 
> Will you please boot the system with ACPI disabled(by adding the boot option of
> "acpi=off") and do the following test?

Hi ykzhao,

I don't know if you still need my help. I tried the test in comment #30, but the kernel hangs during boot when acpi=off is appended to the kernel.

Next, I'll try the test in comment #26.
Comment 33 Sumant Oemrawsingh 2008-12-04 14:20:34 UTC
(In reply to comment #31)

Hi ykzhao,

I tried the comment #26 test as well. The kernel with the custom DSDT is booted, but during boot, the thermal zone is detected to be at its max temperature value (255), and the laptop automatically shuts down. So no testing is possible.

I hope that Balazs has more luck in his tests.

Is there anything I can try?

Comment 34 ykzhao 2008-12-04 17:13:30 UTC
Hi, Sumant
    Thanks for the test. From the test it seems that the system will hang with ACPI disabled.     
    Will you please not use the custom DSDT and do the test as mentioned in comment #26?
    Thanks.
    
Comment 35 Sumant Oemrawsingh 2008-12-13 03:54:19 UTC
>     Will you please not use the custom DSDT and do the test as mentioned in
> comment #26?

Hi ykzhao,

I did the tests in comment #26. The output follows here. I do find ac adapter events in the log now.
Comment 36 Sumant Oemrawsingh 2008-12-13 03:56:27 UTC
Created attachment 19276 [details]
tests of comment #26 without custom dsdt

Output of grep . /sys/firmware/acpi/interrupts/* > acpi_int_before
Comment 37 Sumant Oemrawsingh 2008-12-13 03:57:27 UTC
Created attachment 19277 [details]
tests of comment #26 without custom dsdt (event_log)

Output of cat /proc/acpi/event > /root/event_log
Comment 38 Sumant Oemrawsingh 2008-12-13 03:58:56 UTC
Created attachment 19278 [details]
tests of comment #26 without custom dsdt (acpi_int_after)

Output of grep . /sys/firmware/acpi/interrupts/* > acpi_int_after
Comment 39 ykzhao 2008-12-15 19:32:59 UTC
Created attachment 19322 [details]
[debug patch]: the current mode is ignored while ACPI/legacy transition

Will you please try the debug patch and see whether the ACPI event can be reported correctly?
   Please attach the output of lspci -vxxx after the patch is applied.
   Thanks.
Comment 40 Sumant Oemrawsingh 2008-12-16 01:41:23 UTC
Created attachment 19324 [details]
output of lspci after debug patch

I patched the kernel, rebooted and tried both with acpi_listen and just cat /proc/acpi/event (after killing acpid), but no lid switch events and no ac adapter events.

lspci -vxxx is attached.
Comment 41 ykzhao 2008-12-18 01:39:24 UTC
Hi, summan
    thanks for the test. Now the issue is related with the incorrect GPI routing of 00:00:1f.0 LPC bridge. But it is very strange that it can't be initialized correctly after issuing ACPI_ENABLE command to SMI I/O port. 
     
    Will you please add the boot option of "acpi=off noapic" and see whether the system can be booted? If it can booted, please do the test as mentioned in comment #26.
    Thanks.
Comment 42 Sumant Oemrawsingh 2008-12-19 15:45:18 UTC
(In reply to comment #41)

>     Will you please add the boot option of "acpi=off noapic" and see whether
> the system can be booted? If it can booted, please do the test as mentioned in
> comment #26.

Hi ykzhao,

Thanks for the patience and helping out. I tried appending acpi=off and noapic to the kernel boot line. Basically, the booting process then stops after the following lines (written down somewhere and then I lost the paper...):

io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)

So, as indicated in comment #32 the kernel won't boot without acpi. Maybe I should try this again with a new kernel with acpi not enabled? But I guess that would give the same result.

Anyway, is there something specific you would like me to look for when booting with acpi=off, before the booting process stops/hangs? I can't send you a full log, but I'm willing to write down what I can see.

Thanks
Comment 43 ykzhao 2008-12-21 19:33:34 UTC
Hi, Sumant
   Thanks for the confirmation.
   Now it is clear that this bug is related with incorrect GPI routing of 00:00:1.f0 LPC bridge. If it is configured correctly, the ACPI event can be reported correctly. On windows the ACPI event can be reported correctly. Maybe the GPI routing is configured correctly. 
   In theory the GPI routing should be configured by BIOS after issuing ACPI_ENABLE command to SMI I/O port. But unfortunately it is not initialized correclty on Linux. But it is correct on Windows XP.
   We don't know whether some ACPI objects are not used correctly on Linux or the initiali order about PCI devices/ACPI devices is incorrect.
   
   What I mentioned in comment #30 is to test whether the GPI routing is correctly configured after issuing the ACPI_ENABLE command if the system is booted with ACPI disabled. 
  
   But unfortunately the system can't be booted with ACPI disabled. 
   Thanks.
   
   
   
Comment 44 Sumant Oemrawsingh 2008-12-22 02:59:51 UTC
Hi ykzhao,

I saw that in the DSDT, there is an if statement which changes stuff depending on the OSI. Would changing the acpi os string help?

Thanks.
Comment 45 ykzhao 2008-12-29 00:42:18 UTC
Will you please add the boot option of "acpi_osi=!Linux" ?
Thanks.
Comment 46 Sumant Oemrawsingh 2009-01-01 18:16:32 UTC
Created attachment 19591 [details]
test of comment #26 with acpi_osi=!Linux (acpi_int_before)
Comment 47 Sumant Oemrawsingh 2009-01-01 18:17:08 UTC
Created attachment 19592 [details]
test of comment #26 with acpi_osi=!Linux (event_log)
Comment 48 Sumant Oemrawsingh 2009-01-01 18:17:49 UTC
Created attachment 19593 [details]
test of comment #26 with acpi_osi=!Linux (acpi_int_after)
Comment 49 ykzhao 2009-01-03 18:42:07 UTC
Hi, Sumant
    Thanks for the test.
    From the test it seems that the AC adapter event can be reported correctly if the boot option of "acpi_osi=!Linux" is added.
    Will you please attach the output of lspci -vxxx after the system is booted with "acpi_osi=!Linux"?
    Thanks.
Comment 50 ykzhao 2009-01-03 18:54:13 UTC
Hi, Sumant
    Will you please confirm whether the box is shipped with Windows XP?
    It is very interesting that the AC adapter event can be reported correctly if the boot option of "acpi_osi=!Linux" is added.
    Thanks.
Comment 51 Sumant Oemrawsingh 2009-01-04 06:23:41 UTC
Hi ykzhao,

First of all, the notebook is shipped with Vista. There was an option to downgrade to XP, though, but this would "stop certain things from working since the computer is optimized for Vista" (as they put it).

Second, I must have confused several things during the tests, because I don't really see a difference between the event log from comment #32 and comment #47. So I redid the test in comment #26 under the following conditions:

* Without custom DSDT (i.e. using the original one)
* Without the debug patch you supplied earlier
* Following all other instructions in comment #26 (i.e. using setpci, setting debug level and layer, killing acpid etc)

This gives me an event log where everything is reported. Please find the results below. If you really want to, I can redo the whole thing using acpi_osi=!Linux, but I don't see the point. (But then again, I don't know what to look for).

Would this mean that I have to use the setpci command and/or raise the debug level/layer at boot time to have all events logged? Or is there some sort of patch that can be distilled from this?

Thanks a lot for your help!
Comment 52 Sumant Oemrawsingh 2009-01-04 06:26:07 UTC
Created attachment 19636 [details]
acpi_int_before (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)
Comment 53 Sumant Oemrawsingh 2009-01-04 06:27:05 UTC
Created attachment 19637 [details]
event_log (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)
Comment 54 Sumant Oemrawsingh 2009-01-04 06:27:40 UTC
Created attachment 19638 [details]
acpi_int_after (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)
Comment 55 Sumant Oemrawsingh 2009-01-04 06:28:26 UTC
Created attachment 19639 [details]
lspci (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)

lspci -vxxx > lspci
Comment 56 Sumant Oemrawsingh 2009-01-04 06:41:27 UTC
Created attachment 19640 [details]
lspci (no custom DSDT, no patches, acpi_osi=!Linux)

I rebooted with acpi_osi=!Linux and redid lspci -vxxx. Output is attached. A diff between the normal boot (attachment 19639 [details]) and this boot with the acpi_osi=!Linux gives the following result:

415c415
< b0: 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 00
---
> b0: 00 00 f0 00 00 00 00 00 00 80 00 00 00 00 00 00

But I can confirm that this is only because I did a setpci -s 00:00:1f.0 b9.b=0x80 before generating attachment 19639 [details]. Otherwise, there are apparently no differences.
Comment 57 ykzhao 2009-01-04 18:07:23 UTC
Hi, Sumant
    Thanks for the patient test. And what you have done is very right. That AC adapter event is reported is only becaused you do the command of "setpci -s ". In fact the boot option of "acpi_osi=!Linux" is helpless.
    And the root cause is that the LPC GPI routing is not configured correctly in course of transistion from legacy mode to ACPI mode. But it is very strange that Windows Vista can work well but Linux can't.
    Thanks again.
Comment 58 Sumant Oemrawsingh 2009-01-04 18:24:51 UTC
I guess the quick fix then is to run a script at boot time and wakeup which runs the setpci command. This will work fine, I guess.

I don't understand DSDT's at all, but I'm kinda thinking this should be fixable in a nicer way. For instance, what is the acpi_osi for windows vista? Can you see from the DSDT if (depending on that osi) the DSDT corrects or kills the proper behaviour? I'm not sure if I have the time to dive into this, but I would like to fix this in a proper way. Or do you think there's no hope?

Thanks
Comment 59 ykzhao 2009-01-04 18:59:34 UTC
Hi, Sumant
    What you said is right. The issue can be workaround by that the command of setpci is run in a script at the boot time. But the trouble is that windows Vista can work well while Linux can't work. And we don't know whether this is caused by what is ignored by Linux in course of ACPI initialization. 
   The ACPI_osi for vista is "windows 2006". In fact this is supported on Linux. 
    From the test I am afraid that this issue is difficult to fix in the generic solution. Maybe the script is a better workaround. 
    Thanks.
Comment 60 Sumant Oemrawsingh 2009-01-10 08:49:21 UTC
Hi ykzhao,

I've been looking a bit into this problem you mentioned, that the LPC GPI routing is not configured correctly. I found the following:

1. I turn my laptop on and boot in linux
2. I find that several acpi events are not reported
3. I use the setpci -s... command
4. I verify that the acpi events are now reported correctly (power button, lid switch, adapter)
5. I put the laptop to sleep (suspend to memory)
6. I press a button and everything restores correctly. acpi events are reported correctly.
7. I put the laptop to hibernate (suspend to disc)
8. I turn the laptop back on (using the power button of course) and use the kernel boot line to set the resume partition.
9. Once restored, I verify that acpi events are still reported correctly.

So as far as I understand, when suspending to disk, the laptop is effectively turned off. So when I turn it back on, I would expect to have the same problems and would require a setpci command to turn the correct acpi event reporting back on. Does suspend to disk and restore also restore the pci registers completely? Is this behaviour expected, or does it give some hint as to where the incorrect LPC GPI routing occurs?

Thanks
Comment 61 ykzhao 2009-02-22 19:47:17 UTC
Hi, Sumant
    Sorry for the late response. Thanks for your test and the test result is very interesting.
    It seems that the LPC GPI routing is configured correctly after resuming from disk. But after checking the source code the pci registers related with LPC GPI routing won't be saved/restored in course of suspend to disk.
    Will you please do the following test?
    a. boot the box normally.
    b. put the laptop to hibernate mode
    c. press the power button and resume from the disk.
    d. check whether the acpi event can be reported correctly
    thanks.
Comment 62 ykzhao 2009-03-04 18:19:28 UTC
Created attachment 20433 [details]
call the _WAK object after ACPI full initialization

Will you please try the debug patch and see whether the ACPI event can be reported correctly?
    Please attach the output of lspci -vxxx.
    Thanks.
Comment 63 Sumant Oemrawsingh 2009-03-15 20:13:10 UTC
(In reply to comment #61)
> Hi, Sumant
>     Sorry for the late response. Thanks for your test and the test result is
> very interesting.

Hi ykzhao,

Thanks again for the help. I've tried booting normally, entering hibernate, resuming and checking if the acpi events work; they DO NOT.

So to be sure of the correctness of the earlier comment, I boot normally, use the setpci command, hibernate, resume and verify that (without using the setpci command) the acpi events indeed work.

Seeing that resuming without having used the setpci command doesn't seem to do the trick, I'm not sure if calling _WAK after initialization will work, as per your patch. But when I have a bit more time to play around, I'll try the patch.

Thanks again for your help
Comment 64 ykzhao 2009-03-17 18:32:51 UTC
Hi, Sumant
    Thank for the test and double check.
    From the test it seems that if the command of setpci is not executed, it still can't work after hibernate/resume. But if the command of setpci is executed, it can work well after hibernate/resume. 
    In fact the LCP GPI routing register is not explicitly saved/restored by OS in course of hibernate/resume. Maybe it is done by BIOS.
    
    If so, it still can't work well after applying the patch in comment #62.

    Now I have no idea how to fix this issue. Maybe the workaround is to execute the command of setpci for this box in script. 
    Thanks  
Comment 65 ykzhao 2009-03-23 02:28:06 UTC
Hi, Sumant
    Now it is very clear that this issue is caused by incorrect GPI routing. We have no idea why windows can work well on this box.
    There exists the same issue on another box(1752). If the GPI routing is incorrect, there is no ACPI event.
    So the bug will be marked as the duplicate of bug1752.
    Thanks.

*** This bug has been marked as a duplicate of bug 1752 ***

Note You need to log in before you can comment on or make changes to this bug.