Bug 2109

Summary: poweroff regression @ hwsleep 1.21 - ACPICA 20031203
Product: ACPI Reporter: Ortwin Glück (odi)
Component: Power-OffAssignee: Len Brown (lenb)
Severity: normal CC: acpi-bugzilla, georgmueller, hgfelger, mcaspi
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.2 Subsystem:
Regression: --- Bisected commit-id:
Attachments: hwsleep.c revert part of v1.23 introduced cond. when S5
Do everything but disable BM on the power off path
patch vs 2.6.9
working patched 2.6.6 File

Description Ortwin Glück 2004-02-15 05:30:53 UTC
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
Comment 1 Luming Yu 2004-02-15 23:50:40 UTC
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.) http://linux-acpi.bkbits.net:8080/linux-acpi-test-
Comment 2 Ortwin Glück 2004-02-16 00:58:36 UTC
Sure. I will try this tonight and report back.
Comment 3 Ortwin Glück 2004-02-16 09:46:49 UTC

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.

Comment 4 Luming Yu 2004-02-16 17:09:22 UTC
Thanks for your help. Your experiment shows that Changes for 
drivers/acpi/hardware/hwsleep.c@1.21 cause this regression.
Comment 5 Len Brown 2004-03-04 14:45:54 UTC
*** Bug 2183 has been marked as a duplicate of this bug. ***
Comment 6 Hartwig Felger 2004-03-04 16:06:44 UTC
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...

Comment 7 Ortwin Glück 2004-03-13 08:36:41 UTC
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
Comment 8 Hartwig Felger 2004-03-26 01:00:24 UTC
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? 
Comment 9 Georg Müller 2004-04-05 06:56:22 UTC
The patch in comment 6 works for me too.
Comment 10 Nate Lawson 2004-04-05 12:13:27 UTC
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?
Comment 11 Ortwin Glück 2004-04-05 14:21:47 UTC
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.
Comment 12 Ortwin Glück 2004-04-05 14:24:33 UTC
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.
Comment 13 Sérgio M Basto 2004-04-05 14:58:54 UTC
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 !
Comment 14 Hartwig Felger 2004-04-06 01:41:55 UTC
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 
Comment 15 Nate Lawson 2004-04-14 09:56:39 UTC
Created attachment 2578 [details]
Do everything but disable BM on the power off path
Comment 16 Nate Lawson 2004-04-14 09:57:28 UTC
You really only want to avoid disabling bus mastering only.  The patch above
does this for ACPI-CA, you can hand-merge for Linux.
Comment 17 Moshe Caspi 2004-04-15 03:40:51 UTC
Got the same problem on an old machine/bios, using APM, Mandrake 10.1 with  
kernel 2.6.3.  
Comment 18 Len Brown 2004-04-20 12:47:18 UTC
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. 
Comment 19 Georg Müller 2004-08-01 19:35:58 UTC
3 months later - then will this (very simple) fix will get in?
Comment 20 Ortwin Glück 2004-10-25 16:25:48 UTC

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.


Comment 21 Len Brown 2004-11-03 16:21:40 UTC
Created attachment 3950 [details]
patch vs 2.6.9

does this patch make poweroff start working on this system?
Comment 22 Ortwin Glück 2004-11-04 13:31:03 UTC

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.

Comment 23 Ortwin Glück 2004-11-04 13:32:31 UTC
Created attachment 3966 [details]
working patched 2.6.6 File
Comment 24 Len Brown 2004-11-04 15:52:09 UTC
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)