Bug 6712 - CONFIG_ACPI_SLEEP=y prevents poweroff -- it reboots instead - tyan s2882
CONFIG_ACPI_SLEEP=y prevents poweroff -- it reboots instead - tyan s2882
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Off
i386 Linux
: P2 normal
Assigned To: ykzhao
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-18 20:15 UTC by dean gaudet
Modified: 2008-08-26 00:44 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.16.20
Tree: Mainline
Regression: ---


Attachments
dmesg output (17.72 KB, text/plain)
2006-06-18 20:18 UTC, dean gaudet
Details
acpidump output (69.33 KB, text/plain)
2006-06-18 20:19 UTC, dean gaudet
Details
kernel config (58.61 KB, text/plain)
2006-06-18 20:20 UTC, dean gaudet
Details
add some comments indicating where the reboot occurs (770 bytes, text/plain)
2006-06-22 01:16 UTC, dean gaudet
Details
acpidump, nForce 520 chipset, kernel 2.6.25 (28.98 KB, application/octet-stream)
2008-04-28 20:43 UTC, D Herring
Details

Description dean gaudet 2006-06-18 20:15:16 UTC
Most recent kernel where this bug did not occur: unknown
Distribution: debian unstable
Hardware Environment: tyan s2882, amd64
Software Environment:
Problem Description:

if i build the kernel with CONFIG_ACPI_SLEEP=y and do "shutdown -h now" the
system reboots instead of powering off... if i disable that config option and
attempt to "shutdown -h now" the system powers off fine.  i'd like to be able to
run vendor kernels... so resolving the problem with CONFIG_ACPI_SLEEP=y would be
cool.

oh the bios is the latest greatest from tyan (3.07 iirc).

Steps to reproduce:

"shutdown -h now"
Comment 1 dean gaudet 2006-06-18 20:18:40 UTC
Created attachment 8336 [details]
dmesg output
Comment 2 dean gaudet 2006-06-18 20:19:08 UTC
Created attachment 8337 [details]
acpidump output
Comment 3 dean gaudet 2006-06-18 20:20:37 UTC
Created attachment 8338 [details]
kernel config
Comment 4 dean gaudet 2006-06-18 20:24:03 UTC
oh and here's the tail end of serial console output all the way to the point
where it has reboot and grub has restarted (note i added a few printks of my own):

md: md0 stopped.
md: unbind<sda1>
md: export_rdev(sda1)
md: md1 stopped.
md: unbind<sda2>
md: export_rdev(sda2)
md: md2 still in use.
md: md2 still in use.
md: md2 still in use.
Stopping RAID array md2...failed (busy).
Stopping RAID arrays...done (2 array(s) stopped).
Mounting root filesystem read-only...done.
Will now halt.
sys_reboot: cmd=2309737967, pm_power_off=ffffffff8022cc99
sys_reboot: cmd=1126301404, pm_power_off=ffffffff8022cc99
md: stopping all md devices.
md: md0 switched to read-only mode.
md: md1 switched to read-only mode.
md: md2 still in use.
3w-xxxx: Shutting down host 0.
3w-xxxx: Shutdown complete.
acpi_sleep_prepare(5)
[ACPI Debug]  String: [0x04] "SIOS"
Power down.
machine_shutdown()
acpi_power_off()
acpi_power_off called
 hwsleep-0283 [02] enter_sleep_state     : Entering sleep state [S5]
Press any key to continue.
Comment 5 Luming Yu 2006-06-20 08:05:00 UTC
Please continue to add some dead loop to track down the place triggering 
reboot. Say, add a dead loop after 
status = acpi_hw_register_write(ACPI_MTX_DO_NOT_LOCK,
	ACPI_REGISTER_PM1B_CONTROL,
	PM1Bcontrol);
while(1);

If No reboot with this hack, then you need move on,
till you see reboot. Please reoprt back the results.


Comment 6 dean gaudet 2006-06-22 01:16:15 UTC
Created attachment 8377 [details]
add some comments indicating where the reboot occurs

the attached patch indicates which write is causing the reboot... basically it
happens after the PM1Acontrol write for /* Write #2: SLP_TYP + SLP_EN */ ...
Comment 7 Zhang Rui 2007-07-11 01:35:30 UTC
Does this still exist in 2.6.22?
Comment 8 dean gaudet 2007-07-11 01:54:39 UTC
Subject: Re:  CONFIG_ACPI_SLEEP=y prevents poweroff -- it reboots
 instead - tyan s2882

CONFIG_ACPI_SLEEP seems to be gone in 2.6.22:

sixlark:/usr/src/linux-2.6.22/linux% find . -name Kconfig\* -type f | xargs grep CONFIG_ACPI_SLEEP
zsh: done       find . -name Kconfig\* -type f |
zsh: exit 123   xargs grep CONFIG_ACPI_SLEEP

so... i don't know...

when i do "shutdown -h now" the box halts but does not power off.

-dena

Comment 9 dean gaudet 2007-07-11 02:08:33 UTC
Subject: Re:  CONFIG_ACPI_SLEEP=y prevents poweroff -- it reboots
 instead - tyan s2882

woops... i keep forgetting to drop the CONFIG_ when i do such greps.

there's an ACPI_SLEEP entry in drivers/acpi/Kconfig but it depends upon 
(!SMP || SUSPEND_SMP) ... i apparently hadn't set SUSPEND_SMP... 
rebuilding/etc. now.

-dean

Comment 10 dean gaudet 2007-07-11 09:14:37 UTC
Subject: Re:  CONFIG_ACPI_SLEEP=y prevents poweroff -- it reboots
 instead - tyan s2882

yep the problem is still there in 2.6.22.

-dean

Comment 11 t2 2007-08-19 07:33:24 UTC
I think I'm affected by this issue too - any chance of some movement on it?

I'm running AMD64 with 2.6.22 - if I shutdown the machine it simply restarts.
This is definitely related to a kernel change because it didn't happen in earlier kernels (I think it began in 2.6.20, but I'm not 100% on that).

These are the ACPI settings from my config, you can see the SLEEP is not set:
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_PNPACPI=y
# CONFIG_THINKPAD_ACPI is not set
CONFIG_BLK_DEV_IDEACPI=y
CONFIG_ATA_ACPI=y
Comment 12 Natalie Protasevich 2007-10-22 22:58:10 UTC
Any update on this problem from the developer's side please?
Thanks.
Comment 13 Alexey Starikovskiy 2007-10-22 23:38:43 UTC
https://bugzilla.novell.com/show_bug.cgi?id=299882 and 292300.
looks quite similar. There are the patches in recent git for fixing that...
Comment 14 Natalie Protasevich 2007-10-22 23:51:12 UTC
Thanks... Dean, t2 - can you test the latest git please so we can close this bug.
Comment 15 Fu Michael 2007-12-03 01:01:28 UTC
ping Dean, t2 for test of patch mentioned in comment# 13..
Comment 16 dean gaudet 2007-12-17 17:14:24 UTC
sorry for the delay -- the problem still exists in 2.6.24-rc5 ... i only skimmed the referenced bug reports but they seem to refer to patches already in upstream, so i'm hoping they're in 2.6.24-rc5.  let me know if there's a patch i should test on top of 2.6.24-rc5 (i'm not really git-savvy).
Comment 17 Len Brown 2007-12-28 21:44:27 UTC
If 2.6.24-rc5 still fails, then we still have a problem, for
the fix to https://bugzilla.novell.com/show_bug.cgi?id=299882
9c1c6a1ba786d58bd03e27ee49f89a5685e8e07b
(ACPI: sleep: Fix GPE suspend cleanup)
shipped in Linux-2.6.24-rc1-git6, which precedes 2.6.24-rc5
Comment 18 Zhang Rui 2008-03-18 00:07:28 UTC
Dean, could you please try the latest kernel release, say 2.6.24, and if the problem is fixed?
Comment 19 dean gaudet 2008-03-20 07:23:46 UTC
this system is in production now... i can't experiment like i could 
before.  is there something 2.6.24 fixes which 2.6.24-rc5 doesn't?

thanks
-dean

Comment 20 D Herring 2008-04-04 19:01:39 UTC
I'm having the same problem on both 2.6.23.1 (distributed by Slamd64) and 2.6.24.4 (tweaked/compiled by me).  CPU is an Athlon64X2, mobo is a Biostar TF520 A2+ (nForce 520 chipset), gcc 4.1.2.

Here's a snippet from .config:
#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_SUSPEND_SMP_POSSIBLE=y
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATION_SMP_POSSIBLE=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
Comment 21 ykzhao 2008-04-15 01:05:58 UTC
Hi, Dean
    Will you please try the latest kernel (2.6.25-rc9) and see whether the problem still exists?
    Thanks.
Comment 22 ykzhao 2008-04-15 01:45:32 UTC
Hi, D Herring
    Will you please try the latest kernel (2.6.25-rc9) and see whether the problem still exists? 
    Please attach the output of acpidump.
    Thanks.
Comment 23 D Herring 2008-04-28 20:43:31 UTC
Created attachment 15971 [details]
acpidump, nForce 520 chipset, kernel 2.6.25

I upgraded to 2.6.25; the problem still exists.  Hopefully this ACPI dump is helpful in identifying the problem.

Thanks for looking,
Daniel
Comment 24 ykzhao 2008-04-30 02:28:21 UTC
Will you please try the debug patch in the comment 5 of bug 10503 and see whether the problem still exists?
Thanks.
Comment 25 ykzhao 2008-05-04 02:32:55 UTC
Hi, D Herring
    Will you please try the debug patch in comment#5 of bug 10503 and see whether the problem still exists?
    It will be great if you can confirm whether the windows works well on this machine?
    Thanks.
Comment 26 D Herring 2008-05-07 18:28:16 UTC
I applied the patch (1-liner adding enable=0) and tested at least ten shutdowns, of which it did work a few times.  But a few others produced a strange disk error during shutdown, so I'm sticking with an unpatched kernel for actual use.  These drives haven't had any other issues.

Somehow this feels like an uninitialized variable or race condition, but I haven't worked through the code to see where.  Maybe it is the hardware/bios.  FWIW, the same reboot happens with 2.6.23 running in 32-bit mode on another linux install.  Sorry; no MSWin available for testing.

I tried a few kernel parameters; acpi=off causes the machine to halt but not power off, while acpi=strict and acpi=noirq didn't have any noticeable effect.
Comment 27 ykzhao 2008-05-12 02:25:01 UTC
Thanks for the test. 
If the unpatched kernel is used, is the system still rebooted instead of poweroff?
Thanks.
Comment 28 Mike Edwards 2008-06-07 15:13:08 UTC
(In reply to comment #0)
> Most recent kernel where this bug did not occur: unknown
> Distribution: debian unstable
> Hardware Environment: tyan s2882, amd64
> Software Environment:
> Problem Description:
> 
> if i build the kernel with CONFIG_ACPI_SLEEP=y and do "shutdown -h now" the
> system reboots instead of powering off... if i disable that config option and
> attempt to "shutdown -h now" the system powers off fine.  i'd like to be able to
> run vendor kernels... so resolving the problem with CONFIG_ACPI_SLEEP=y would be
> cool.
> 
> oh the bios is the latest greatest from tyan (3.07 iirc).
> 
> Steps to reproduce:
> 
> "shutdown -h now"

Comment 29 Mike Edwards 2008-06-07 18:41:25 UTC
Just to toss my $0.02 in, I'm also experiencing this issue on the S2882.  It shows up in 2.6.24, though the 2.6.18 xen kernel in Debian appears to not have it.
Comment 30 ykzhao 2008-07-21 20:21:49 UTC
Hi, Mike
   Do you experience the similiar issue on your S2882? From your description your system is rebooted instead of shutdown on 2.6.24 kernel, right? Please attach the output of acpidump on your S2882. 
    Will you please disable some PCI devices in bios option and see whether the problem still exists?
    Will you please try the latest kernel(2.6.26-rc8)?
    Thanks.
Comment 31 ykzhao 2008-08-25 22:04:44 UTC
As there is no response from the bug reporter for more than one month, the bug will be rejected. 
If the problem still exists, please reopen it.
thanks.
Comment 32 dean gaudet 2008-08-26 00:31:12 UTC
as i mentioned, the system is in production, i can't just try experimental patches unless you can document to me why you think they solve the problem.
Comment 33 dean gaudet 2008-08-26 00:44:11 UTC
what the heck, it's late evening... i went for it.

2.6.26.1 seems to have solved the problem at least for the following config:

% grep ACPI /boot/config-`uname -r`
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=m
CONFIG_ACPI_BAY=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_NUMA=y
CONFIG_ACPI_WMI=m
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_ACPI_CONTAINER=m
CONFIG_ACPI_SBS=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
CONFIG_PNPACPI=y
CONFIG_THINKPAD_ACPI=m
# CONFIG_THINKPAD_ACPI_DEBUG is not set
CONFIG_THINKPAD_ACPI_BAY=y
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_BLK_DEV_IDEACPI=y
CONFIG_ATA_ACPI=y
# CONFIG_PATA_ACPI is not set

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