My notebook no longer powers down on request, I have "Power Down." message instead. This happens on vanilla sources, gentoo and suspend2 are also broken.
Steps to Reproduce:
1. Power down notebook by issuing 'suspend' or alt+sysrq+o
"Power Down." message
Powered off device
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 72
model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52
stepping : 2
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc
bogomips : 1608.46
clflush size : 64
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)
04:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce Go 7600] (rev a1)
05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
05:01.1 Generic system peripheral : Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
05:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)
05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)
Created attachment 118773 [details]
could you elaborate a little more on "power down" message?
Is this dmesg? and could you attach this as well?
This is the last output from kernel, not a dmesg, just a printk ;) THen kernel is completely halted.
I've tried to make printk more verbose and got last line:
acpi_power_off called (drivers/acpi/sleep/poweroff.c:45)
and the last working kernel version was?
Sorry, forgot to mention that. Last known good is linux-2.6.20-gentoo-r8
which suspension mode do you use?
there should be "platform" "shutdown" and "reboot" , you could try all of them
> there should be "platform" "shutdown" and "reboot" , you could try all of them
I assume that "shutdown" is /sbin/shutdown and "reboot" is /sbin/reboot. What's "platform" then and how can I try it?
I'm a little confused as to whether this bug is about suspend-to-disk or power off..
Does powering off without suspending work? i.e. just running "halt"
how about "reboot"?
This is not suspend2 or any other way of suspend, just power off. halt, poweroff, shutdown, alt+sysrq+o work the same - I get "Power Down." message. reboot works. suspend2 works too, but after suspending (to disk) I have the same "Power Down." message.
OK. Can you shutdown/halt when booted with the "acpi=off" kernel parameter?
The only difference with acpi=off is working system after "Power Down."/"System halted." message, i.e. kernel is not halted.
could you specify what configuration parameters you changed from 2.6.20-r8 to 2.6.21 ? (if any)
Could you try with a newer version of vanilla-sources?
Created attachment 118986 [details]
diff from 2.6.20 to 2.6.21
Do you mean git version by 'a newer version of vanilla-sources'? AFAIK, 126.96.36.199 is the latest one.
so you did try 188.8.131.52 ? Then perhaps the git snapshot yes
also, could you try hitting some keys when you get the powerdown message? I found someone reporting that he could halt the machine that way
could you test with the newly released 2.6.22-rc1 ?
From the dialog in this bug, I don't know if you guys understand what the reporter is saying. The kernel is no longer able to soft off the machine. Remember Windows 95 "It is not safe to turn off your computer." messages? The kernel does the same thing if it cannot soft off a machine.
I may be wrong, but I think the kernel prints that message even when "automatic" power down will happen immediately after.
Also, this worked in earlier kernels, so is a valid bug regardless of what appears on screen.
ok, it's working again in 2.6.22-r1, however I've got half of the screen filled with some messages. Not sure about what they say, because power is down in half a second.
I've researched this and can't find anything other than another unsolved report (http://lkml.org/lkml/2007/5/8/281). I've looked through the various resources (LKML, kernel bugzilla, git logs) but I can't see anything obvious that would have fixed this for 2.6.22. It's also hard to say which part of the kernel the original bug is related to -- it doesn't appear to be ACPI.
If you're interested in helping further, you could do an inverse bisection. First read about bisections here: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
You need to do the opposite, with the aim of finding the patch which solved the issue in 2.6.22 (so that we can backport it). Mark 2.6.21 as good, and 2.6.22-rc1 as bad. When you find a kernel that fails to shutdown, mark it as GOOD. When you find a kernel that shuts down OK, mark it as BAD. Eventually you'll reach the "first bad commit" which will be the commit that fixed the bug.
Given that this is a time consuming process (I estimate 13 kernels required to complete the bisection) and you have already found some working configurations, I understand if you aren't willing to go to this trouble -- this bug will simply sit around until 2.6.22 is released (unless more info appears).
bisect is a really nice thing! Last good revision is 2e42005bcdb4f63bed1cea7f537a5534d4bd7a57. Next revisions:
fail to compile. Next one (ad71860a17ba33eb0e673e9e2cf5ba0d8e3e3fdd) compiles, S5 is broken there. diff between 2e42005b and ad71860a is 9833 lines long and it makes me feel nervous.
Can you please post the output of "git bisect log" ?
Also, am I right in assuming that for the ones that failed to compile, you marked them as good/bad? If so, that probably messed up the bisection result. This is really the only bisect downfall (sorry, I should have mentioned that earlier)
# bad: [de46c33745f5e2ad594c72f2cf5f490861b16ce1] Linux 2.6.21
git-bisect bad de46c33745f5e2ad594c72f2cf5f490861b16ce1
# good: [62d0cfcb27cf755cebdc93ca95dabc83608007cd] Linux 2.6.20
git-bisect good 62d0cfcb27cf755cebdc93ca95dabc83608007cd
# bad: [7292576043666ff39946dee14641fe719ba8c7e8] ACPI: fix S3 fan resume issue
git-bisect bad 7292576043666ff39946dee14641fe719ba8c7e8
# bad: [4768fbcbcfbbcacb785ae08eef33767a0b4fdcdd] [NET]: Fix whitespace errors.
git-bisect bad 4768fbcbcfbbcacb785ae08eef33767a0b4fdcdd
# bad: [905adce4094d64a6691df994e424fbf486301adc] Merge master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6
git-bisect bad 905adce4094d64a6691df994e424fbf486301adc
# good: [64358164f5bfe5e11d4040c1eb674c29e1436ce5] USB: remove duplicate device id from zc0301
git-bisect good 64358164f5bfe5e11d4040c1eb674c29e1436ce5
# bad: [21d37bbc65e39a26856de6b14be371ff24e0d03f] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git-bisect bad 21d37bbc65e39a26856de6b14be371ff24e0d03f
# bad: [5008740e27540e4069a2f8235f8308aba46036a2] ACPICA: Update version to 20061215
git-bisect bad 5008740e27540e4069a2f8235f8308aba46036a2
# bad: [977a6226feae3e2c10a4d8227625ff0f04b49239] ACPICA: Fix trace output name and whitespace
git-bisect bad 977a6226feae3e2c10a4d8227625ff0f04b49239
# bad: [c5a7156959e89b32260ad6072bbf5077bcdfbeee] ACPICA: Disable all wake GPEs after first one recieved
git-bisect bad c5a7156959e89b32260ad6072bbf5077bcdfbeee
# good: [f93a21c7184de3db962d01f11eb2ddad5396c824] ACPICA: Update version to 20060721
git-bisect good f93a21c7184de3db962d01f11eb2ddad5396c824
# bad: [4bf273939c99fae5bae399f51c417a552d74b97f] ACPICA: Fix for FADT conversion in 64-bit mode
git-bisect bad 4bf273939c99fae5bae399f51c417a552d74b97f
# bad: [f3d2e7865c816258c699ff965768e46b50d536d3] ACPICA: Implement simplified Table Manager
git-bisect bad f3d2e7865c816258c699ff965768e46b50d536d3
I've marked failed compilation as bad (that was f3d2e78), after that I've hunted for good/bad by cg-seek.
(In reply to comment #21)
> bisect is a really nice thing! Last good revision is
good as in "shuts down OK"?
> Next one (ad71860a17ba33eb0e673e9e2cf5ba0d8e3e3fdd) compiles,
> S5 is broken there.
OK - I think you've followed the general guide on my weblog, which tracks down the commit that ADDED the bug.
That's really useful when the bug isn't already solved in a newer version, and may still prove to be useful, but I was hoping that you'd invert it in order to find the patch that FIXED the bug (read comment #20).
If you can confirm that you did the bisection in the style written on my weblog (the 'normal' way), I'll write to the ACPI list with that info, asking if they know which patch solved the issue. If they don't then you can consider starting the inverted bisection a day or 2 later (I know it's a time consuming process so let's give email a shot first!)
pleas see comment #25
I've switched to .22-r4 with manually applied gentoo & suspend2 patchsets. So, if nobody else will find this, bug can be safely discarded.