System does not power off on shutdown

If you boot without the "quiet splash" options on grub does it help to pinpoint the problem area on shutdown?

when i remove quiet splash on grup, it says
Power down
acpi_power_off called
But it just stays there and does not power off.

This looks like an ACPI bug in your BIOS. Can you boot with noacpi and see if the machine shuts down properly?

I tried noacpi option then noacpi noapic option. But the machine didn't shut down properly. Also i tried ignorebiostables option but there is no diffrence, it says:
Power down
acpi_power_off called
and stays there

Could you attach the output of
dmidecode
I am utterly baffled as to why an acpi power off would be done when acpi is disabled though (surely it should have fallen back to apm?)...

Here is the dmidecode output. Also, when i boot with option single and then make "shutdown -h now" it shutdowns properly.

Hi, I also have a hard time with power-off, I searched a bit in the launchpad and bug #31993 seems related too.

The system goes to until the power off message, you can ear the hard drives being stopped, the screen goes dark, but power remains on motherboard.

I have a Bi-Opteron system, and was using for a long time Fedora Core distros, the problem appears erraticly, the kernels that doesn't power-off my system are kernel 2.6.11, 2.6.12, 2.6.15 and 2.6.16.

Ubuntu 6.06-flight6 is falty too.

I strongly believe in a kernel flaw that triggers subtily at kernel releases, sometimes if works sometimes not (as you can see in the kernels numbers I said above).
Since this happens at a moment the system does not give any command to the user, and no process can still berunning, there is no log nor evidence of the fail, so what can we do ?

As I read the posts above I tried the acpi and runlevel 1 tests ... no success everything fails.

I'll include my dmidecode output too.

my output

Does a trace (https://wiki.ubuntu.com/DebuggingSystemCrash) reveal anything of interest?

> Does a trace (https://wiki.ubuntu.com/DebuggingSystemCrash) reveal anything of interest?

This happens AFTER the shutdown process being completed, at the moment the power is supposed to be turned off, there is no more process running, no more indication there is a system still running in fact ...

So no, it doesn't reveal anything

I experience the same problem on my desktop computer.
I tried noacpi then noacpi noapic too, the same behavior than capacman occured.

As corsaire01 said i also think that this is a kernel flaw that triggers subtily at kernel releases. Because my computer power-off when i had been using ubuntu 5.10. If i do not remember wrong it also power-off properly with kubuntu 6.04 flight 4 cd. However it is still working when i boot with recovery mode. Is there any other module related to acpi or apm that is loaded when we boot normaly rather than init 1?

I think this bug report is also duplicate of this https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39499

capacman> as you pointed it can (and it seems, must) have a relation with the bug you pointed, however the main problem here is :
"what information can we provide to kernel developpers so they can have something to study ?"

giving the dmidecode output is a step but is it enough ? What do you need ? How can we help ?

See also the dmseg output which follows.

"[4294667.296000] ACPI: BIOS age (1999) fails cutoff (2000), acpi=force is required to enable ACPI"

If I boot with the acpi=force argument, I can successfuly shutdown.

Otherwise, the apm module is loaded, but I cannot poweroff.

There is a lot of bugs related to "system not powering off on shutdown". I think there are two types of problems. One type is people that have apm enabled by default and the other type is people that have acpi enabled by default. Those with apm can solve the problem booting with the acpi=force argument, but the other type has no solution till now.

I think i found a workaround for those with acpi enabled. When i shutdown my system, everything is ok, but when the machine is supposed to power off the console says "acpi_power_off called" and nothing happens. I discover that when i hibernate the machine (hibernate works out of the box in this machine, thanks ubuntu devs!) there is a power off.

The workaround i propose consists of using S5 acpi state to power off the machine. In /etc/init.d/halt replace the line that says "halt -d -f -i $poweroff $hddown" with "echo 5 > /proc/acpi/sleep".
I don't know if is a good or a bad solution, but it works for me and i haven't found any problem using it.

Sorry for my poor english. It isn't my native language.

Is this the same bug as #33775?

It is quite possible that Bug #33775 is related to this one.

A large number of these problems may revolve around buggy bios that a crashing when they are told to power off. If at all possible check whether there is a newer BIOS for your motherboard (of course flashing your BIOS is done at your own risk etc.)

>A large number of these problems may revolve around buggy bios that a crashing when they are told to power off. If at all possible check whether there is a newer BIOS for your motherboard (of course flashing your BIOS is done at your own risk etc.)

I diseagree here on this explonation, as I reported before this buggy behaviour goes and come back on different kernel versions, the 2.6.15 and 2.6.16 are at fault too, really feels more like a change badly done in the kernel than a hardware related trouble.
And btw I have the last available firmware and the result is the same.

> >A large number of these problems may revolve around buggy bios that a
> crashing when they are told to power off. If at all possible check
> whether there is a newer BIOS for your motherboard (of course flashing
> your BIOS is done at your own risk etc.)

_Could_ be, as that computer is some six years old. But the strange
thing is, that it worked well in Breezy!

> I diseagree here on this explonation, as I reported before this buggy behaviour goes and come back on different kernel versions, the 2.6.15 and 2.6.16 are at fault too, really feels more like a change badly done in the kernel than a hardware related trouble.
> And btw I have the last available firmware and the result is the same.

So it is kernel-dependant problem, not init script or something like that?

you raise an interesting question, I am (and I bet we all are) more than willing to help and knock down this trouble, I am even ready to do some tests or reports on my system.
However until now nobody asked precise questions or asked to verify precise parts or to test configs and see the results of it.

If someone around here have something concrete to ask I am listening.

Power off doesn't work with shutdown and it works with "echo 5 > /proc/acpi/sleep" in one of my systems.
Why?

After Sitsofe Wheeler post on buggy bios issue, i upgraded my bios from revision 1006.1 to 1007.3(beta bios). But the problem remains same. However upgrade i made some tests. First, i turned off acpi 2.0 support from bios. This did not change anything. But when i turned off acpi apic support , it said some weird things in boot process. Those are:
acpi: acpi bus type scsi registered
#set misaliggned resource pointer: df861dc2 type 07 len 0
ata1 slow to respond
after those warnings my harddisk worked slowly. Actually i do not know whether this information is related to this bug but i reported it because it hapened after i turned off acpi apic support. Then i turned on acpi apic support. But i encountered more interesthing thing accidentally. If i do not log into system when kdm asks me for my password and press ctrl+alt+f1 and then log in and issue the command sudo shutdown -h now, system shutdown properly. But if i log into system from kdm and issue the same command from ttys0 or from konsole or from start menu "turn off the computer" button after kde started it does not shutdown itself. is someone have an idea about that?(:))

I tryed the manipulation pointed by Roax : "echo 5 > /proc/acpi/sleep"

It produced the same result than with "power off", the machine goes down, the HDD drives are stopping down, but at the end the power remains and the motherdoard start to beep.

no success here, the mystery remains.

I too have encounter the "system does not poweroff on shutdown" problem when I upgraded the kernel from 2.6.12-9 to 2.6.15-22.

Under kernel-2.6.12-9, there is a /proc/acpi directory, where as under kernel-2.6.15-22, /proc/acpi was missing. I read somewhere the acpi was to be moved to /sys, but i couldn't fine it there.

From the same cource, it suggest that acpi function for BIOS that is older then year 2000 is not supported. (http://justlinux.com/forum/archive/index.php/t-130279.html)

Then I recalled I saw a kernel configuration option for 2.6.15-22 under the ACPI section with the number 2000, the option is CONFIG_APCI_BLACKLIST_YEAR

When I check this CONFIG_ACPI_BLACKLIST_YEAR option in the config file for kernel-2.6.12-9, the option was set to 0.

The next clue to confirm the findings was from dmesg,

ACPI: BIOS age (1999) fails cutoff (2000), acpi=force is required to enable ACPI

So i added "acpi=force" to menu.lst, and rebooted, this soft the "no power off" problem for me.

Now the next question is, why is kernel-2.6.15-22 compiled with CONFIG_ACPI_BLACKLIST_YEAR=2000 where this was set to 0 in kernel-2.6.12-9?

Is this a policy by Ubuntu or from upstream Debian? What is the consquence if we reconfigure and recompile the kernel to set CONFIG_ACPI_BLACKLIST_YEAR=0 for kernel-2.6.15-22?

Also from #31993 Peter Whittaker suggected that "acpi=force" is not a work around for him because of the "S3 sleep" (whatever that is), will setting CONFIG_ACPI_BLACKLIST_YEAR=0 solve his problem too? Since kernel-2.6.12-9 works fine with that.

Good point you raised here tsanghan , however there's one thing I did not understand well, does it mean your motherboard is older than the year 2000 ?
If not it just shows that there is something really wrong with the ACPI section in the actual kernels.

For my system, the Tyan Tiger K8W, it is at most older than september 2003, I bought mine last year and I did the Bios upgrades.

ACPI is complicated and a lot of people seemingly get it wrong.

Back in the late 90s ACPI was very new and an awful lot of BIOS vendors were creating BIOSes that did awful things to the hardware when ACPI was turned on. I used a K6-III that had random lockups with ACPI turned on. However over time ACPI became a little bit more reliable (there are still a sad number of cases of BIOSes being released with bad ACPI though).

Anyway so many of the old BIOSes had broken ACPI it was decided that an arbitrary cut off date *for the BIOS itself* should be set. BIOSes with ACPI that were older than this date would need ACPI to be forced in order to use it. This avoided having to create a blacklist for each individual old BIOS (remember if an update comes out it is seen as different and if it were broken it might have to be listed seperately) with broken ACPI out there.

Most people never run into this because their BIOS is new enough that ACPI defaults to on however there are cases of people with pre 1999 BIOSes that don't have broken ACPI but do have broken APM.

You can see a Red Hat dev talking about the Ubuntu BIOS cut off year here:
http://kernelslacker.livejournal.com/30664.html

I suppose the question is was the patch that Ubuntu was carrying to disable the cutoff dropped on purpose?

If someone REALLY wants to have a shot at getting this fixed soon and it really is a problem that only shows up in certain kernels (i.e. it worked on some 2.6.15 kernels but not others) you can try selectively compiling different kernels until the change that causes the problem is narrowed down. It's a brute force attempt at tackling the issue and may require dozens (or more) of kernels to compiled and tested. However if you succeed in narrowing the problem down to a single patch you stand a very good chance of having the problem fixed.

To answer Corsaire01, yes my "System does not power off on shutdown" problem was on an old hand-me-down HP OmniBook 4150 notebook with a Pentium III Coppermine CPU, apprently my BIOS was "born" in the year 1999.

It seems to me that the "System does not power off on shutdown" bug resports here can generally be categorised into 2 main portions,
1) People who have old hardware with BIOS older then 2000 (like me :)
2) People who genuinely have ACPI or BIOS problem. (like Corsaire01)

I admit I have no idea what is the different between ACPI and APM. But looking at the perspective that it is only 5 days to June (exactly when in June Dapper will be release?) and that I did not see any mention of the 2000 year cutoff date set in the Kernel-2.6.15, other then a brief "dmesg" line from Andrew Zajac earlier. I feel that this information may help filter out the old BIOS problem category and have developers concentrate on actual ACPI or BISO problems category.

So what can be done to have this information out to help users of actual 6.06 Dapper (to be release in June, and assuming this is still not fixed) to do a self diagnostic first before filing an actual ACPI/BIOS problem (and cut out the old BISO problem noise)? Perhaps a wiki page on this old BIOS issue? I bring this up because when I encounter the problem a few days ago, there was not much info on this issue after googling.

to Sitsofe Wheeler,

I'm sorry there but if we discuss about this issue it's precisely because we are unsure about the problem and would like ways to be sure.

On a second hand not everyone does know how to compile a kernel for Ubuntu, I did not done it for a long while, since I do not use slackware anymore in fact, and so first question coming in mind is how to get the .config file needed in the source tree to have the exact config of the kernel given in the Ubuntu release before trying to tamper with it ?

I don't see myself trying to guess all the possible options to have the same than the Ubuntu stock kernel.

Well since no one have answer to Corsaire01, I will take a shot.

If I am not wrong, the content of the ".config" file for the current running kernel on your machine is stored in the file "/boot/config-$(uname -r)". So take this file save it under your kernel source tree and rename to ".config". Run "make menuconfig" and change what ever option you want to try, you can save the new ".config" as another filename, and load it back later from menuconfig too. I hope I get this right, as I am recalling from memory.

Hope this will help.

See also bug 43961.

I have to confirm the not powering down bug for Edgy!

I get the message
[SOME.NUMBER] Power Down
but the system does not power down.

My Laptop showed this messages for several hours, since I did shutdown the machine and left at night without waiting for the laptop to actually power down. The next day it was still on and showing this message.

Hardware: Vaio VGN-S560P

Breezy did the same, Dapper worked while there was some delay between the moment it could power down (for example when hibernate did turn of the HDD) and the actual power down.

I have to confirm the not powering down bug for Edgy!

I get the message
[SOME.NUMBER] Power Down
but the system does not power down.

My Laptop showed this messages for several hours, since I did shutdown the machine and left at night without waiting for the laptop to actually power down. The next day it was still on and showing this message.

Hardware: Vaio VGN-S560P

Breezy did the same, Dapper worked while there was some delay between the moment it could power down (for example when hibernate did turn of the HDD) and the actual power down.

By the way, there are several bugs describing this issue, they should be consolidated!

bug #43961
bug #36158
bug #31933

This is not a complete list and there are some bugs which link this behavior to a specific laptop model but basically describe the same symptom and therefore most likely have the same problem source.

This is a mayor annoyance and makes this great Distro look unprofessional! Somebody should investigate this!

Marked as duplicate of bug 43961 - upstream kernel bug.

[Expired for linux-source-2.6.15 (Ubuntu) because there has been no activity for 60 days.]