Bug 3669

Summary: poweroff no longer switch off the machine but reboots
Product: ACPI Reporter: GCS (gcs)
Component: Power-OffAssignee: Len Brown (lenb)
Status: CLOSED CODE_FIX    
Severity: high CC: acpi-bugzilla, hgfelger, peter, pierre-bugzilla, shaohua.li, stephen.walton
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.8.1-bk1 Subsystem:
Regression: --- Bisected commit-id:
Attachments: boot log with acpi=debug on a buggy kernel
dmidecode output on a buggy kernel
lspci -vv output on a buggy kernel
Temporary "fix" for this problem, until I understand what's going on
/proc/acpi/dsdt contents as requested by Luming Yu
patch for the issue
patch for the issue
use #ifdef CONFIG_ACPI_SLEEP to build properly without this setting
patch using #ifdef CONFIG_ACPI_SLEEP

Description GCS 2004-10-30 09:36:14 UTC
Distribution: Debian Sarge, up-to-date
Hardware Environment: Gericom 1st Supersonic laptop, PIII 1200Mhz/512 Mb RAM
Software Environment: N/A I think
Problem Description: I have used the 2.4 series, switched to 2.6 when it was
released. The halt command was working all kernels as I have always upgraded
until 2.6.8.1. From 2.6.9 the machine reboots instead of halt. I could 'trace'
it back to 2.6.8.1 + the first bk patch applied. If I remove all the ACPI
update from -bk1 and apply only the rest, then it is still working, so the bug
is in that ACPI update.

Steps to reproduce:
Compile a kernel which released _after_ 2.6.8.1 with ACPI enabled (APIC is
disabled for me, but that does not matter in my case), boot and try to issue
halt. The box will reboot instead, at least on this machine. My .config is the
same I used for other 2.6.x kernels.
Comment 1 GCS 2004-10-30 09:40:11 UTC
Created attachment 3910 [details]
boot log with acpi=debug on a buggy kernel

I have booted the kernel with acpi=debug, hope this helps a bit. I do not see
any relevant, but at least it shows that I have a VIA based motherboard.
Comment 2 GCS 2004-10-30 09:54:02 UTC
Created attachment 3911 [details]
dmidecode output on a buggy kernel

The same output is given on a working kernel.
Comment 3 GCS 2004-10-30 09:56:58 UTC
Created attachment 3912 [details]
lspci -vv output on a buggy kernel

The output differs from the one which is got under a working kernel:
--- acpi-lspci-vv-bad.txt	2004-10-30 18:47:40.000000000 +0200
+++ acpi-lspci-vv-good.txt	2004-10-27 21:30:43.000000000 +0200
@@ -5,7 +5,7 @@
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW- AGP3- Rate=x1,x2,x4
-		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=x4
+		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x1
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
@@ -140,15 +140,16 @@

 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
M6 LY (prog-if 00 [VGA])
	Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1930
-	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B+
+	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
+	Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at 9000 [size=256]
	Region 2: Memory at e0000000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW- AGP3- Rate=x1,x2,x4
-		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW-
Rate=<none>
+		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x1
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Comment 4 Pavel Machek 2004-11-01 00:49:10 UTC
I have similar problems on compaq evo n620c... With acpi on, machine self-powers
up as soon as I open the lid. With acpi off, I get strange light-show at system
leds, and machine reboots instead off powering off. 
Comment 5 Pavel Machek 2004-11-01 00:52:57 UTC
There's very similar bug at bugzilla.suse.de, bug #47048. I tried to mark the
bug okay for public access, but I'm not sure how it is supposed to work.
Comment 6 Fred Labrosse 2004-11-01 02:41:08 UTC
I have the same problem on a ACER TM 636 on 2.6.7, 2.6.8.1 and 2.6.9. 
Comment 7 GCS 2004-11-01 10:40:04 UTC
Fred added to the following on the acpi-devel mailing list:
Sorry, doing more tests reveal that this only happens in 2.6.9.  I just
tried in 2.6.8.1 and it worked. (The thing happening from 2.6.7 and above
is the battery and temperature status.)

So he has the very same bug I have, and it was added in 2.6.8.1 + 2.6.9-bk1.
Please note that all of us have a notebook, and none reported it on desktop.
HTH.
Comment 8 Len Brown 2004-11-04 16:04:01 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.
Comment 9 GCS 2004-11-04 23:49:58 UTC
Thanks for looking into this Len. The bug 3696 seems similar, as I experience
reboot while on AC, and it _seems_ the machine poweroff normally when running
on battery (seems, because my battery is worn out, I was happy that I could
boot up, as I could not start again the machine because of low power, maybe
it could not reboot because of this).
Anyway I have applied the patch to my already compiled 2.6.9 tree, saw that
hwsleep was recompiled but I still have the same bug. Should I do a
'make mrproper' first on my kernel tree? Will try that.
The mentioned bug is only similar, as under 2.6.7, 2.6.8 and 2.6.8.1 I do not
have this problem. I could track it down to 2.6.9-bk1, where the bug was
first introduced.
Comment 10 GCS 2004-11-05 00:58:27 UTC
Oops, forgot to mention that I try to tighten the bug location. So I removed all
ACPI relevant changes from 2.6.9-bk1, applied and it still works. Then with help
of Pavel Machek I was able to get the merged in ACPI changesets individually.
Currently I am merging them step by step (tried changesets so far: ACPICA
20040402, ACPICA 20040427, ACPICA 20040514, ACPICA 20040527, ACPICA 20040615,
fix return-from-sleep PM/ACPI state conversion bug, reserve IOPORTS for ACPI,
and I am not sure in ACPICA 20040715 now) but still could not find the location
as with these patches also applied poweroff still works.
Comment 11 Hartwig Felger 2004-11-06 14:25:02 UTC
To #9 
Salut GCS 
>Thanks for looking into this Len. The bug 3696 seems similar, as I experience 
>reboot while on AC, and it _seems_ the machine poweroff normally when running 
>on battery (seems, because my battery is worn out, I was happy that I could 
>boot up, as I could not start again the machine because of low power, maybe 
>it could not reboot because of this). 
I just tryed it with my laptop. It also shows this lake of poweingoff since 
2.6.9. I tryed it on AC and without AC. So I am pretty sure, that it's your 
worn-out batteries that keeps you from restarting when not on AC. 
 
Be sure, when testing to not have the lid shut, as with some notebooks it will 
not start/reboot if the lid is closed, no matter what command you issued for 
going down - or restart. 
Comment 12 GCS 2004-11-07 12:36:57 UTC
Created attachment 3977 [details]
Temporary "fix" for this problem, until I understand what's going on

This is more like a test case for others; please apply it against 2.6.9 and
report back if this fixes this odd behaviour for you or not. Thanks in advance!
Comment 13 Hartwig Felger 2004-11-08 04:35:36 UTC
Salut Laszlo, 
you applying the patch from #12 does fix the problem for me. So this points to 
wakeup-GPEs? Don't know how to handle these. Maybe it's more a configuration 
problem? Doing cat /proc/acpi/wakeup on the vanilla (i.e. unpatched) 2.6.9 
would show the following: 
 
Device  Sleep state     Status 
SLPB       3            *enabled 
 LID       3            *enabled 
 MDM       3            disabled 
CRD0       3            disabled 
 LAN       4            disabled 
 
Does anyone know, how to change this entries (from enabled to disabled). Maybe 
setting this wakeup-items all to disable would also help?  
Comment 14 GCS 2004-11-08 07:42:14 UTC
Created attachment 3989 [details]
/proc/acpi/dsdt contents as requested by Luming Yu

Actually this is for an other bug, which cause kacpid to hang in a D state
sometimes; but attaching here as it may be relevant, and there's no bug open
for
the other bug yet.
Comment 15 Shaohua 2004-11-09 18:31:09 UTC
I checked the dsdt, and I don't think it's a wakeup GPE issue. The power off 
code path doen't touch any wakeup GPE, and your wakeup GPE only can wakeup 
your system from S1. Please check if removing some drivers make any difference.
Comment 16 Johnny Casey 2004-11-11 19:15:19 UTC
Responding to Comment #12,

I have a Asus SK8V Motherboard with Athlon FX51, with 2.6.9 (or 2.6.9-rc1,
haven't tried others yet) halt turns into the reboot problem, but not 2.6.8.1. 
The patch solved the problem.

Thanks
Comment 17 Shaohua 2004-11-11 19:22:50 UTC
Hmm, how about only apply the button.c part of the patch?
Comment 18 Hartwig Felger 2004-11-13 02:21:55 UTC
Salut David, 
I just double cheked. No just applining the button.c-part of the patch does not 
fix the problem. 
 
Sorry 
Comment 19 Hartwig Felger 2004-11-13 09:07:22 UTC
So, just went on to try which part of the patch is relevant. For that I tryed 
the button.c and the wakup.c part each alone. That could not fix the issue. 
Only if they are applied both, the machine would do a proper power-off. 
 
Cheers 
Comment 20 Len Brown 2004-11-14 20:12:50 UTC
are you powering off by pressing the power button, or by running /sbin/poweroff? 
Does it make any difference if you rmmod button before you /sbin/poweroff? 
 
Comment 21 Hartwig Felger 2004-11-15 02:50:43 UTC
Salut Len, 
I run "shutdown -h now" on a SuSE 9.1 prof., which calls "halt -p" 
where /sbin/poweroff is linked to. 
Just tryed to rmmod button before going down, but it did not help. 
 
Sorry 
 hartwig :-(  
Comment 22 Shaohua 2004-11-15 18:20:38 UTC
Ok, please just apply below patch (sorry, you possibly need manualy merge it)
diff -Nur linux-2.6.9.orig/drivers/acpi/button.c linux-
2.6.9/drivers/acpi/button.c
--- linux-2.6.9.orig/drivers/acpi/button.c	2004-10-19 16:58:28.000000000 
+0200
+++ linux-2.6.9/drivers/acpi/button.c	2004-11-07 21:28:06.000000000 +0100
@@ -456,15 +456,6 @@
 		goto end;
 	}
 
-	if (device->wakeup.flags.valid) {
-		/* Button's GPE is run-wake GPE */
-		acpi_set_gpe_type(device->wakeup.gpe_device, 
-			device->wakeup.gpe_number, ACPI_GPE_TYPE_WAKE_RUN);
-		acpi_enable_gpe(device->wakeup.gpe_device, 
-			device->wakeup.gpe_number, ACPI_NOT_ISR);
-		device->wakeup.state.enabled = 1;
-	}
-
 	printk(KERN_INFO PREFIX "%s [%s]\n", 
 		acpi_device_name(device), acpi_device_bid(device));
 diff -Nur linux-2.6.9.orig/drivers/acpi/sleep/wakeup.c linux-
2.6.9/drivers/acpi/sleep/wakeup.c
--- linux-2.6.9.orig/drivers/acpi/sleep/wakeup.c	2004-10-19 
16:58:29.000000000 +0200
+++ linux-2.6.9/drivers/acpi/sleep/wakeup.c	2004-11-07 21:28:06.000000000 
+0100
@@ -159,14 +129,12 @@
 	list_for_each_safe(node, next, &acpi_wakeup_device_list) {
 		struct acpi_device * dev = container_of(node, 
 			struct acpi_device, wakeup_list);
-		
-		/* In case user doesn't load button driver */
-		if (dev->wakeup.flags.run_wake && !dev->wakeup.state.enabled) {
+
+		/* Enable wakeup GPE for Lid/sleep button by default */
+		if (dev->wakeup.flags.run_wake) {
 			spin_unlock(&acpi_device_lock);
 			acpi_set_gpe_type(dev->wakeup.gpe_device, 
 				dev->wakeup.gpe_number, 
ACPI_GPE_TYPE_WAKE_RUN);
-			acpi_enable_gpe(dev->wakeup.gpe_device, 
-				dev->wakeup.gpe_number, ACPI_NOT_ISR);
 			dev->wakeup.state.enabled = 1;
 			spin_lock(&acpi_device_lock);
 		}
Comment 23 Len Brown 2004-11-15 19:12:07 UTC
anybody seeing this in 2.4.27, per bug 3748? 
Comment 24 Shaohua 2004-11-15 19:13:20 UTC
Created attachment 4033 [details]
patch for the issue

Or please try the patch, it's much formal.
Comment 25 Shaohua 2004-11-15 19:13:26 UTC
Created attachment 4034 [details]
patch for the issue

Or please try the patch, it's much formal.
Comment 26 Hartwig Felger 2004-11-16 08:11:57 UTC
Salut David, 
id=4034 fixes it for me, (as well, as your inlined version in #22). 
 
Thanks ;-) 
  hartwig 
Comment 27 Shaohua 2004-11-16 16:31:50 UTC
*** Bug 3696 has been marked as a duplicate of this bug. ***
Comment 28 Shaohua 2004-11-16 18:05:35 UTC
Ok, till now we receive positive news. Thanks GCS's original patch.
But still doesn't know why some systems require this patch (apparently only 
small part of laptops require it), one guess is this is a BIOS or even 
hardware bug.
Comment 29 Shaohua 2004-11-17 17:34:30 UTC
*** Bug 3405 has been marked as a duplicate of this bug. ***
Comment 30 GCS 2004-11-19 08:44:08 UTC
I am back for a while, answers coming:
- applied the last patch from David Shaohua to 2.6.10-rc2, and now the machine
switches off correctly,
- I do not use 2.4.x for a long time now, I can not comment if that has this bug
as well or not; will try to get time to check it out,
- I always issue halt, I do not use the button.

If someone interested and have a way for testing whether this is a
BIOS/hardware/else bug, then let me know. Please commit this fix, and submit it
for Andrew/Linus.
Thanks for co-operating!
Comment 31 GCS 2004-11-19 08:47:35 UTC
Comment on attachment 3977 [details]
Temporary "fix" for this problem, until I understand what's going on

Obsoloted by David Shaohua's patch, which is the real fix.
Comment 32 Thomas Renninger 2004-11-19 10:40:14 UTC
acpi_wakeup_gpe_poweroff_prepare(); 
should be embedded into #ifdef CONFIG_ACPI_SLEEP as whole driver/acpi/wakeup.o 
is depending on it. 
reopened to not get overseen. 
will attach patch... 
Comment 33 Thomas Renninger 2004-11-19 10:43:54 UTC
Created attachment 4088 [details]
use #ifdef CONFIG_ACPI_SLEEP to build properly without this setting
Comment 34 Len Brown 2004-11-20 01:53:08 UTC
a note about states:

NEW and ASSIGNED mean it is open and unresolved.
RESOVLVED means there is a patch to test, review, and potentially apply.
CLOSED means that the fix has shipped in the upstream kernel.
Comment 35 Shaohua 2004-11-21 17:42:57 UTC
Good catch, Thomas. But the patch isn't completely 
right. 'acpi_wakeup_gpe_poweroff_prepare' shoule be always called, since in 
some systems, button will cause reboot and button GPE is enabled in button.c. 
I'll figure out a new one.
Comment 36 Shaohua 2004-11-21 18:26:08 UTC
Created attachment 4105 [details]
patch using #ifdef CONFIG_ACPI_SLEEP

Please try this patch.
Comment 37 Akos Maroy 2004-11-23 15:59:23 UTC
I'd just like to say that this patch works for me splendidly...
Comment 38 Eric Schott 2004-11-30 06:24:56 UTC
I had troubles with SWSUSP2 power off not always working.  This may have fixed it.
Comment 39 Len Brown 2004-12-05 19:39:32 UTC
shipped in 2.6.10-rc3 
closing 
Comment 40 Stephen Walton 2004-12-06 11:18:42 UTC
I know this is marked FIXED, but just so it is officially "here":  I applied the
patch in attachment id=4105 to the 2.6.9-1.681_FC3 kernel, and my laptop (Compaq
2199US) still does not power down after acpi_power_off.  All 2.6.8 kernels did
so on this system.
Comment 41 Ortwin Glück 2004-12-06 13:51:19 UTC
My laptop now powers off correctly with kernel 2.6.10-rc3. Thanks guys.
Comment 42 Stephen Walton 2004-12-10 09:46:49 UTC
2.6.10-rc3 also makes my laptop power off correctly.  Thanks.