Bug 3642 - poweroff usually fails in 2.6.9 - regression since
Summary: poweroff usually fails in 2.6.9 - regression since
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Off (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Luming Yu
Depends on:
Reported: 2004-10-25 12:44 UTC by Dave Jones
Modified: 2005-03-14 01:39 UTC (History)
1 user (show)

See Also:
Kernel Version: all since
Regression: ---
Bisected commit-id:

new version of field operation code (20.15 KB, patch)
2004-11-23 07:27 UTC, Alexey Starikovskiy
Details | Diff

Description Dave Jones 2004-10-25 12:44:54 UTC
My laptop hangs after printing 'calling acpi_power_off()' for about a minute or
two before it actually powers off. On a coworkers laptop, he waited 30-45
minutes, and it still didnt power off.
I added printk checks to the power off code, and traced its execution.

-> acpi_enter_sleep_state_prep(ACPI_STATE_S5);
   status = acpi_evaluate_object (NULL, METHOD_NAME__PTS, &arg_list, NULL);
   ->status = acpi_ns_evaluate_by_name(pathname, &info);
     -> status = acpi_ns_evaluate_by_handle(info);
           -> acpi_ns_execute_control_method(info);
          -> acpi_psx_execute(info)
                    -> acpi_ds_init_aml_walk(walk_state...   (line 207)

When I added printk's to acpi_ds_init_aml_walk, the machine would poweroff
Comment 1 Luming Yu 2004-10-25 19:37:23 UTC
Please describe the kernel version, and machine info.
Comment 2 Dave Jones 2004-10-25 19:46:38 UTC
It definitly worked in, and for sometime afterwards. It broke somewhere
around the 2.6.9rc1/rc2 period.

I can reproduce this 100% of the time on a Compaq Evo N1015v

DSDT/disassembly is at http://www.codemonkey.org.uk/projects/acpi/dsdt/dsdt.evo*
Comment 3 Luming Yu 2004-10-26 02:27:41 UTC
Hmmm. would you please try patch at bug 1653.
Comment 4 Luming Yu 2004-10-26 02:37:05 UTC
Opps, I call back my comment# 3
Comment 5 Luming Yu 2004-10-26 02:46:37 UTC
Would you like to customize DSDT like below to figure out where is hang?
Method(\_PTS, 1) {

    If(LEqual(Arg0, 0x3)) {
        Store("------------- System S0 to S3 mode -------------", Debug)
        Acquire(SLP_, 0xffff)
        If(\_SB_.PCI0.PIB_.EC__.ECOK) {
            Store(\_SB_.PCI0.PM__.LIDI, \_SB_.PCI0.PM__.LPOL)
            Store(0x1, \_SB_.PCI0.PIB_.EC__.SLPT)
            Store(0x0, \_SB_.PCI0.PIB_.EC__.Z000)
        Store(0x1, \_SB_.PCI0.PM__.USBP)
        Store(0x0, \_SB_.PCI0.PM__.SUSC)
        Store(0x1, \_SB_.PCI0.CRD0.PMST)
    If(LEqual(Arg0, 0x4)) {
        Store("------------- System S0 to S4 mode -------------", Debug)
        Store(0x1, \_SB_.PCI0.PM__.SUSC)
Comment 6 Len Brown 2004-10-26 10:53:16 UTC
unlikely the same issue, but since it is easy to test, please
comment on if CONFIG_SMP= y or n, and if the patch in bug 2593
makes any difference.
Comment 7 Len Brown 2004-10-26 10:54:05 UTC
also, please test if booting with "acpi=strict" makes any difference.
Comment 8 Dave Jones 2004-10-26 12:04:53 UTC
acpi=strict made no difference, CONFIG_SMP is not set.
Comment 9 Jason Baron 2004-10-26 12:34:38 UTC
i have an old ibm laptop x20, which exhibits exactly these problems. Perhaps it
is really too old for any kind of acpi support? In anycase, acpi=strict made no
difference, and CONFIG_SMP is not set. Booting with acpi=off allowed shutdown to
work normally.
Comment 10 Jason Baron 2004-10-26 12:39:35 UTC
i have an old ibm laptop x20, which exhibits exactly these problems. Perhaps it
is really too old for any kind of acpi support? In anycase, acpi=strict made no
difference, and CONFIG_SMP is not set. Booting with acpi=off allowed shutdown to
work normally.
Comment 11 Len Brown 2004-11-04 18:29:21 UTC
does this happen just when running on AC or also when runing on battery?

in bug 3696 it was reported to happen only when running on AC
but poweroff worked correctly when running on battery.

please try the test patch in bug 3696, which reverts the
fix to bug 2109.
Comment 12 Len Brown 2004-11-15 19:33:08 UTC
please try the patch in bug 3669 
Comment 13 Dave Jones 2004-11-16 14:06:54 UTC
happens on AC and on battery.
Patch makes no difference.
Still takes about 30s to a minute to power off after printing
the acpi_power_off message.
Comment 14 Alexey Starikovskiy 2004-11-17 05:19:11 UTC
Does it make any difference if you comment out calls to Sleep() in _PTS? 
Comment 15 Alexey Starikovskiy 2004-11-23 07:27:09 UTC
Created attachment 4125 [details]
new version of field operation code

Could you please try this patch?
Comment 16 Luming Yu 2004-11-30 19:19:07 UTC
        If (LEqual (Arg0, 0x05))
            Store (0x95, \_SB.PCI0.ISA.BCMD)
            Store (Zero, \_SB.PCI0.ISA.SMIC)
            Sleep (0x07D0)

The execution of sleep(07D0) will involve acpi_ex_exit_interpreter & 
acpi_ex_enter_interpreter. This could make the thing unable to be
predicted, because I'm not sure how many threads could be sleeping on
the queue of ACPI_MTX_EXECUTE.
Comment 17 Luming Yu 2004-11-30 19:34:40 UTC
The following patch is trying to eliminate the interference from GPE 
interrupt, which could ask for service from interpreter. Please have it a try. 
--- 2.6/drivers/acpi/hardware/hwsleep.c 2004-12-03 10:28:31.300961648 -0800 
+++ 2.6/drivers/acpi/hardware/hwsleep.c.1       2004-12-03 10:28:21.209495784 
@@ -165,6 +165,8 @@ 
        ACPI_FUNCTION_TRACE ("acpi_enter_sleep_state_prep"); 
+       acpi_hw_disable_all_gpes (ACPI_NOT_ISR); 
         * _PSW methods could be run here to enable wake-on keyboard, LAN, 
Comment 18 Dave Jones 2004-12-01 09:39:26 UTC
patch referenced in bug 3669 made no difference.
about to try the ones mentioned in the followups above.
Comment 19 Dave Jones 2004-12-09 15:11:52 UTC
whoops forgot to followup - the patch in #17 also didnt have any effect.
Comment 20 Alexey Starikovskiy 2004-12-14 04:26:34 UTC
Have you tried #15?

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