Distribution: Gentoo (with kernel from kernel.org) Hardware Environment: 0000:00:00.0 Host bridge: ALi Corporation M1671 Super P4 Northbridge [AGP4X,PCI and SDR/DDR] (rev 02) 0000:00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller 0000:00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) 0000:00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] 0000:00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem] 0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 0000:00:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) 0000:00:0f.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 0000:00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) 0000:00:11.0 Bridge: ALi Corporation M7101 PMU 0000:00:13.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 02) 0000:00:13.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 02) 0000:00:14.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 0000:01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 Go] (rev b2) 0000:02:00.0 Network controller: Harris Semiconductor D-Links DWL-g650 A1 (rev 01) Problem Description: Power off works with 2.6.1 but not with 2.6.2 anymore. Probably due to changes in drivers/acpi/hardware/hwsleep.c
To confirm this is a regression of hwsleep.c, would you try to revert below two patches? 1.) http://linux-acpi.bkbits.net:8080/linux-acpi-test- 2.6.2/diffs/drivers/acpi/hardware/hwsleep.c@1.22? nav=index.html|src/.|src/drivers|src/drivers/acpi|src/drivers/acpi/hardware|his t/drivers/acpi/hardware/hwsleep.c 2.) http://linux-acpi.bkbits.net:8080/linux-acpi-test- 2.6.2/diffs/drivers/acpi/hardware/hwsleep.c@1.21? nav=index.html|src/.|src/drivers|src/drivers/acpi|src/drivers/acpi/hardware|his t/drivers/acpi/hardware/hwsleep.c
Sure. I will try this tonight and report back.
Luming, I gave revision 1.21 of hwsleep.c a spin and it did not power off. Then I gave revision 1.20 a spin and it powered off correctly! So it seems that the problem is with the patch from 1.20 to 1.21. I have not turned on ACPI debug messages unfortunately. So I can not tell what's happening exactly. Do you want me to enable debug messages and take 1.21 for a spin again? Thanks for looking into this. I am not familiar with kernel hacking (Java is my world), but I am willing to help as well as I can. Odi
Thanks for your help. Your experiment shows that Changes for drivers/acpi/hardware/hwsleep.c@1.21 cause this regression.
*** Bug 2183 has been marked as a duplicate of this bug. ***
Created attachment 2286 [details] hwsleep.c revert part of v1.23 introduced cond. when S5 ...fixes the bug for me. I have tested it with 2.4.24+acpi-20031203-2.4.24.diff.bz2 and 2.4.25 and 2.5.26-pre1. I just figured out, that the block with the 3 statments (+error-checking) that was set conditional on S5 which was introduced with v1.23 of hwsleep.c is a bit too much. My machine needs the middle of the 3 statements also in case of a S5. I did not try to understand, what this means... Cheers
The patch mentioned in comment 6 applied to 2.6.4 fixes the problem for me. Please try to get this patch into the kernel. Thanks a lot! kind regards Ortwin Gl
As Andy Kleen started a new thread on acpi-devel list "Re: [ACPI] [PATCH] Handle disabled local apic better" I got the idea of just disabling APIC in the kernel configuration. So I do no longer need the patch, if I compile a kernel without APIC support. My dmesg did tell me earlier, that it disabled APIC-support, as my machine does not have one... but it had an impact on powering-off anyway! So this might be a better way to handle it, as long a Andy did not have the final solution on the above... Ortwin, may you please prove, if this way works for you too?
The patch in comment 6 works for me too.
I just checked ACPI-CA 20040326 and it does not have this change or an equivalent. How can this be marked as CODE_FIX if it hasn't made it into ACPI-CA?
Hartwig, my kernel has root@gimli /usr/src/linux # grep APIC .config CONFIG_X86_GOOD_APIC=y # CONFIG_X86_UP_APIC is not set So I guess this will not work for me.
Nate, the documentation on the status / resolution flags led me to mark it as CODE_FIX. Maybe that is wrong. I'll reopen and leave it up to the owner to set the bug status appropriately as I am not familiar enough with the kernel development process. Sorry if I caused any confusion.
Yes, Nate is right, this patch hasn't be applied yet, so if we need this patch for working with something, marked as CODE_FIX is wrong. I think is marked as CODE_FIX, because someone think this patch, now, is useless !
Salut Folks, as Ortwin told me today, his issue is not (as mine) dependant on APIC, as he has disabled it in his kernel-config. I think it would be best to find the person, who commited the 1.23v of hardware/hwsleep.c. LEN may you have a look into the commit-log? From there the question will be, what have this committer changed, for what reason, and what did my patch revert (semantically). On the other hand Ortwin stated, that his regression was starting with v1.21. As my problem is solved (and my patch was pure combinatorial), somebody else need to step up to push this bug out of the kernel. Cheers hartwig
Created attachment 2578 [details] Do everything but disable BM on the power off path
You really only want to avoid disabling bus mastering only. The patch above does this for ACPI-CA, you can hand-merge for Linux.
Got the same problem on an old machine/bios, using APM, Mandrake 10.1 with kernel 2.6.3.
actually in this bugzilla, RESOLVED/CODE_FIX means a patch exists. Also, it moves the bug into my queue of things that may be ready to be integrated. (and clearing RESOLVED moved it out...) When the patch is actually shipped in ACPICA and the kernel, the bugzilla is CLOSED. thanks, -Len
3 months later - then will this (very simple) fix will get in?
Len, Is there a good reason why this patch has not made it into the kernel yet? Please give people here an idea of the timeframe. Cheers Ortwin
Created attachment 3950 [details] patch vs 2.6.9 does this patch make poweroff start working on this system?
Len, thanks for the patch. It fails to apply however. Don't know what's the problem. Looks like the patch is reversed. But patch -R did not work either. I just attach the hwsleep.c that I use with 2.6.6 and that works. Ortwin
Created attachment 3966 [details] working patched 2.6.6 File
my mistake. the change in comment #21 shipped in ACPICA 20040427 which is already in linux-2.6.9. So please re-open this bug if poweroff doesn't work for you in 2.6.9. I've applied the patch in comment #21 to the ACPI 2.4 tree for 2.4.28. the mystery is why this patch was necessary, and if it is what caused the reboot-on-halt problems seein in 2.6.9 (bug 3696)