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