Bug 3669

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.

Created attachment 3911 [details]
dmidecode output on a buggy kernel

The same output is given on a working kernel.

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-

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. 

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.

I have the same problem on a ACER TM 636 on 2.6.7, 2.6.8.1 and 2.6.9. 

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.

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.

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.

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.

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. 

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!

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?  

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.

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.

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

Hmm, how about only apply the button.c part of the patch?

Salut David, 
I just double cheked. No just applining the button.c-part of the patch does not 
fix the problem. 
 
Sorry 

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 

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? 
 

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

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);
 		}

anybody seeing this in 2.4.27, per bug 3748? 

Created attachment 4033 [details]
patch for the issue

Or please try the patch, it's much formal.

Created attachment 4034 [details]
patch for the issue

Or please try the patch, it's much formal.

Salut David, 
id=4034 fixes it for me, (as well, as your inlined version in #22). 
 
Thanks ;-) 
  hartwig 

*** Bug 3696 has been marked as a duplicate of this bug. ***

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.

*** Bug 3405 has been marked as a duplicate of this bug. ***

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

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

Created attachment 4088 [details]
use #ifdef CONFIG_ACPI_SLEEP to build properly without this setting

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.

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.

Created attachment 4105 [details]
patch using #ifdef CONFIG_ACPI_SLEEP

Please try this patch.

I'd just like to say that this patch works for me splendidly...

I had troubles with SWSUSP2 power off not always working.  This may have fixed it.

shipped in 2.6.10-rc3 
closing 

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.

My laptop now powers off correctly with kernel 2.6.10-rc3. Thanks guys.

2.6.10-rc3 also makes my laptop power off correctly.  Thanks.