Bug 9518
Summary: | Regression from 2.6.21: snd-hda-intel prevents box from powering off | ||
---|---|---|---|
Product: | Drivers | Reporter: | Woody Suwalski (woodys) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED CODE_FIX | ||
Severity: | low | CC: | acpi-bugzilla, alan-jenkins, dpmcgee, rjw, tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.25 | Subsystem: | |
Regression: | Yes | Bisected commit-id: |
Description
Woody Suwalski
2007-12-07 07:48:19 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? 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 or # 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 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. 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 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... |