Bug 9518 - Regression from 2.6.21: snd-hda-intel prevents box from powering off
Regression from 2.6.21: snd-hda-intel prevents box from powering off
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 low
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-07 07:48 UTC by Woody Suwalski
Modified: 2009-08-31 14:26 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.25
Tree: Mainline
Regression: Yes


Attachments

Description Woody Suwalski 2007-12-07 07:48:19 UTC
Most recent kernel where this bug did not occur:2.6.21
Distribution:xandros, debian
Hardware Environment:Asus EeePC, Asus EP20
Software Environment:
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)

kernel/power/main.c/valid_state(4)/suspend_ops->valid(state) 

returns NULL

Call chain:

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)
Comment 1 Len Brown 2007-12-07 22:23:41 UTC
/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?

Comment 2 Woody Suwalski 2007-12-08 12:34:35 UTC
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...
Comment 3 Rafael J. Wysocki 2007-12-08 12:47:28 UTC
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.
Comment 4 Woody Suwalski 2007-12-08 13:00:03 UTC
How to power-off from /bin/bash?
Just sync;sync; halt -d -p -f ???
Comment 5 Rafael J. Wysocki 2007-12-08 14:35:40 UTC
No, I meant:

# mount /proc
# echo 5 > /proc/acpi/sleep

or

# mount /proc
# echo o > /proc/sysrq-trigger

(if you have the magic sysrq compiled in).
Comment 6 Woody Suwalski 2007-12-10 08:42:12 UTC
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...

Comment 7 Rafael J. Wysocki 2007-12-10 08:57:31 UTC
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.]
Comment 8 Woody Suwalski 2007-12-10 09:08:30 UTC
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...
Comment 9 Dan McGee 2008-03-17 20:54:19 UTC
I wanted to poke this bug as it still exists in 2.6.24.3 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.
Comment 10 Alan Jenkins 2009-08-31 10:28:23 UTC
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.
Comment 11 Woody Suwalski 2009-08-31 14:26:25 UTC
I have run a check with 2.6.30.4 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.

Marking resolved...

Note You need to log in before you can comment on or make changes to this bug.