Bug 11857

Created attachment 18444 [details]
output of acpidump

Output of acpidump

Created attachment 18445 [details]
Original DSDT

The original DSDT

Created attachment 18446 [details]
Output of dmesg

Output of dmesg | grep -i acpi

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.

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.

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

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?

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.

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

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. 

    

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

Created attachment 18804 [details]
acpi interrupts after pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27

Created attachment 18805 [details]
acpi interrupts before pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27

Created attachment 18807 [details]
dmesg output on Sony VGB-SZ61WN laptop kernel 2.6.27

Created attachment 18808 [details]
acpi event log during pressing buttons on Sony VGB-SZ61WN laptop kernel 2.6.27

any difference with the sony-laptop module excluded from the kernel?

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)

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

Created attachment 18840 [details]
ACPI interrupts before plug/unplug

Created attachment 18841 [details]
Acpi event log during plug/unplug

Created attachment 18842 [details]
ACPI interrupts after plug/unplug

Created attachment 18843 [details]
dmesg after plug/unplug

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. 
      
    

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.
    

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

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.

Hi, Balazs
    Will you please confirm whether the box can work well on windows?
    thanks.

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

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.

    

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.

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.

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

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

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.
    

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

Created attachment 19276 [details]
tests of comment #26 without custom dsdt

Output of grep . /sys/firmware/acpi/interrupts/* > acpi_int_before

Created attachment 19277 [details]
tests of comment #26 without custom dsdt (event_log)

Output of cat /proc/acpi/event > /root/event_log

Created attachment 19278 [details]
tests of comment #26 without custom dsdt (acpi_int_after)

Output of grep . /sys/firmware/acpi/interrupts/* > acpi_int_after

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.

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.

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.

(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

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.
   
   
   

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.

Will you please add the boot option of "acpi_osi=!Linux" ?
Thanks.

Created attachment 19591 [details]
test of comment #26 with acpi_osi=!Linux (acpi_int_before)

Created attachment 19592 [details]
test of comment #26 with acpi_osi=!Linux (event_log)

Created attachment 19593 [details]
test of comment #26 with acpi_osi=!Linux (acpi_int_after)

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.

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.

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!

Created attachment 19636 [details]
acpi_int_before (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)

Created attachment 19637 [details]
event_log (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)

Created attachment 19638 [details]
acpi_int_after (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)

Created attachment 19639 [details]
lspci (test of comment #26, no custom DSDT, no patches, no acpi_osi boot parameters)

lspci -vxxx > lspci

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.

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.

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

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.

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

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.

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.

(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

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  

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 ***