Kernel Bug Tracker – Bug 9518
Regression from 2.6.21: snd-hda-intel prevents box from powering off
Last modified: 2009-08-31 14:26:25 UTC
Most recent kernel where this bug did not occur:2.6.21
Hardware Environment:Asus EeePC, Asus EP20
Problem Description:We had originally some problems using a regular "C" reboot(poweroff) call from our init C prog, however writing 5 to /proc/acpi/sleep worked OK.
It was broken in 2.6.22, and still is in 2.6.24-rc4
Steps to reproduce:
echo -n "5">/proc/acpi/sleep
will fail with ENODEV, because in (2.6.24)
valid_state() is called from drivers/acpi/sleep/proc.c/acpi_system_write()
which calls drivers/acpi/sleep/main.c/acpi_suspend(5)
which calls kernel/power/main.c/pm_suspend(4)
which calls kernel/power/main.c/enter_state(4)
which calls kernel/power/main.c/valid_state(4)
/proc/acpi/sleep has been deprecated since 2.6.13
via ACPI_SLEEP_PROC_SLEEP, and has been slated for
removal since then. (that was over 2 years ago)
is there a reason you can't use "poweroff" or "init 0"?
If so, perhaps we should debug that issue, rather
than the /proc/acpi/sleep issue?
As mentioned in the bug description - the acpi sleep was the only method that worked for us in 2.6.21. And is broken since...
As to a "regular" reboot(poweroff) syscall:
After a day of debugging I have established that the most logical source of the "regular" poweroff issue is the snd_hda driver (95% sure).
I suspect that we are trying to bring down the system too quickly without using PM suspend calls first (can sys_reboot(poweroff) function abort or lock if the drivers were not run through PM_suspend routine?)
However this brings a question: what is the user interface to trigger a PM suspend call in the system? Normally it is done by hibernation driver, but here I do not want to go through freezing all tasks and writing the PCI state - just power down...
I have started using an ugly workaround - rmmod'ing all drivers in a loop - and that seems to help...
Hm, perhaps you'll be able to identify the offending module(s).
First, though, please boot with init=/bin/bash and see if the box is powered off properly in this configuration.
How to power-off from /bin/bash?
Just sync;sync; halt -d -p -f ???
No, I meant:
# mount /proc
# echo 5 > /proc/acpi/sleep
# mount /proc
# echo o > /proc/sysrq-trigger
(if you have the magic sysrq compiled in).
Rebuilt the kernel with 0 patches = 100% vanilla 2.6.24-rc4
Booting with init=/bin/bash, mount /proc, mount -o remount,ro /, echo -n "5">/proc/acpi/sleep still returns
"echo: write error: No such device"
The "echo o > /proc/sysrq-trigger" seems to be working in init=/bin/bash mode,
however if snd-hda-intel driver is loaded, it will fail to shutdown properly (the machine's front LED would suggest that it is powered down, but the video seems to be getting sync. I have to keep power button off for 5 seconds to actually power off)
Rmmod'ing snd-hda-intel is also sufficient to let "regular" /sbin/halt -d -p -f to poweroff OK. So it is a sound driver which is causing the root poweroff problems.
However - it has nothing to do with /proc/acpi/sleep error?
For me this bug is now of a low priority - since I have found a good workaround...
Do I understand correctly that you can power off the fully functional system using "/sbin/halt -d -p -f" if snd-hda-intel is unloaded before?
[No, the /proc/acpi/sleep error that you've got with init=/bin/bash doesn't seem to be related to the sound driver.]
Correct. The C system function "reboot(LINUX_REBOOT_CMD_POWER_OFF)" works OK without sound drivers and so does /sbin/halt -d -p -f - which I think calls the same syscall internally...
I wanted to poke this bug as it still exists in 188.8.131.52 as well as 2.6.25-rc4-dirty.
The following also seems to work if the driver is built-in rather than compiled as a module (so cannot be rmmmod-ed):
echo -n "0000:00:1b.0" > /sys/bus/pci/drivers/HDA\ Intel/unbind
if 0000:00:1b.0 is the correct PCI bus location for the sound card.
Hi! In my experience this bug was fixed on the Asus EeePC a couple of revisions ago.
Can anyone confirm this bug on a recent kernel? If not, it should probably be closed.
I have run a check with 184.108.40.206 kernel on one of the original troublesome boxes (EP20).
Confirm that poweroff now works OK without a need to rmmod the snd-hda-intel driver.