Distribution: Gentoo (with kernel from kernel.org)
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]
0000:02:00.0 Network controller: Harris Semiconductor D-Links DWL-g650 A1 (rev 01)
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
Sure. I will try this tonight and report back.
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
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.
Thanks for your help. Your experiment shows that Changes for
firstname.lastname@example.org 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
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...
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!
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_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 !
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.
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
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.
3 months later - then will this (very simple) fix will get in?
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.
Created attachment 3950 [details]
patch vs 2.6.9
does this patch make poweroff start working on this system?
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.
Created attachment 3966 [details]
working patched 2.6.6 File
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)