Bug 3642
| Summary: | poweroff usually fails in 2.6.9 - regression since 2.6.8.1 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Dave Jones (davej) |
| Component: | Power-Off | Assignee: | Luming Yu (luming.yu) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | acpi-bugzilla |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | all since 2.6.8.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: | new version of field operation code | ||
Please describe the kernel version, and machine info. It definitly worked in 2.6.8.1, 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* Opps, I call back my comment# 3 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)
\_SB_.Z001(0x82)
Release(SLP_)
}
If(LEqual(Arg0, 0x4)) {
Store("------------- System S0 to S4 mode -------------", Debug)
Store(0x1, \_SB_.PCI0.PM__.SUSC)
}
}
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. also, please test if booting with "acpi=strict" makes any difference. acpi=strict made no difference, CONFIG_SMP is not set. 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. 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. 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. please try the patch in bug 3669 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. Does it make any difference if you comment out calls to Sleep() in _PTS? Created attachment 4125 [details]
new version of field operation code
Could you please try this patch?
_PTS:
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.
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
-0800
@@ -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,
etc.
*/
patch referenced in bug 3669 made no difference. about to try the ones mentioned in the followups above. whoops forgot to followup - the patch in #17 also didnt have any effect. Have you tried #15? |
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_power_off() -> 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 instantly.