Ubuntu

snd_hda_intel fails to unload (or unload correctly) on shut down; laptop fails to halt

Reported by Bradley Nampel on 2007-07-15
This bug report is a duplicate of:  Bug #296500: Update to 2.6.27.5 stable kernel. Edit Remove
46
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Unknown
Fedora
Fix Released
Unknown
Mandriva
Fix Released
Unknown
Ubuntu
Undecided
Unassigned
linux (Ubuntu)
Medium
Unassigned
linux-source-2.6.22 (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: kernel-image-2.6.22-8-generic-di

I chose to file this under the current Gutsy kernel, but this issue has plagued me since Dapper. Ever since Dapper my laptop wouldn't shut down properly. I would get the infamous "will now halt" message, but my computer would never completely shut down. Today I found the culprit: the snd_hda_intel module. If I manually remove this module (rmmod snd_hda_intel) before shutting down everything works perfectly. My laptop is a Toshiba Satellite A105-S2716.

I also came across a post from bug #43961 that confirms the same behavior. Coincidentally, he has the same model laptop I do:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/43961/comments/157

Workaround:

To work around this problem, I created an init.d script to run at shutdown. All the script does is remove the snd_hda_intel module at shutdown (rmmod snd-hda-intel) and things work smoothly.
See this thread for more detail: http://ubuntuforums.org/showthread.php?t=500268

Bradley Nampel (bnampel) on 2007-07-15
description: updated
Bradley Nampel (bnampel) on 2007-07-15
description: updated
description: updated
Bradley Nampel (bnampel) wrote :
Bradley Nampel (bnampel) wrote :
Bradley Nampel (bnampel) wrote :
Bradley Nampel (bnampel) wrote :
uBo (ubo) wrote :

I can confirm the same problem since Dapper too. I am using Feisty at the moment and still can only properly shut down when first manually remove the snd-hda-intel module. The problem must lie in the module.

Laptop: Toshiba Satellite A105-S2716

uBo (ubo) on 2007-07-29
Changed in linux-source-2.6.22:
status: New → Confirmed
Bradley Nampel (bnampel) wrote :
Bradley Nampel (bnampel) wrote :
Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
TJ (tj) wrote :

Allocated to xorg since shutting down Gnome prior to halting the system solves the issue. Reports from other distributions suggest the same cause.

Changed in xorg:
status: New → Confirmed
TJ (tj) wrote :

From working with snd_hda_intel and ACPI I'm reasonably confident this isn't an ACPI bug.

Changed in linux-source-2.6.22:
status: Confirmed → Invalid
Bradley Nampel (bnampel) on 2007-08-01
description: updated
description: updated
Bradley Nampel (bnampel) wrote :
Divilinux (divilinux) wrote :

have u seen if audio uses another busy IRQ channel?

Bradley Nampel (bnampel) wrote :

No, I haven't. I've attached the output for 'cat /proc/interrupts' because I think that's what you're refering to. I really don't know what to look for on this though.

Divilinux (divilinux) wrote :

yes, is the file i needed
normally you can find various interrupts at the same channel..but on some bugged bios you can find an intel-interrupts that can damage irqrouting table, so is better to deactivate the IO APIC system to avoid bad communications between devices and BUS peripherals.
Try to boot with options "nolapic" o "noapic" (local apic and apic) to see changes. Remind that some interrupts can drive crazy for switching-off the irqtable..

Bradley Nampel (bnampel) wrote :

I've done all the things you've listed above and they don't make a difference.

Timo Aaltonen (tjaalton) wrote :

Not X related.

Changed in xorg:
status: Confirmed → Invalid
Martijn vdS (martijn) wrote :

I see this on the Eee PC as well. I can provide lspci/dmesg/lshal/etc. output if required.

Yes please..long time has passed
;)

2008/1/13, Martijn van de Streek <email address hidden>:
>
> I see this on the Eee PC as well. I can provide lspci/dmesg/lshal/etc.
> output if required.
>
> --
> snd_hda_intel fails to unload (or unload correctly) on shut down; laptop
> fails to halt
> https://bugs.launchpad.net/bugs/126140
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Ubuntu-it
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x8773719CCAFA17BE

Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :

These came from hardy alpha-3

Bradley Nampel (bnampel) wrote :

Martijn-

Does the workaround mentioned in my description of the bug work for you?

description: updated
Martijn vdS (martijn) wrote :

Yes, rmmod'ing snd-hda-intel before shutdown fixes poweroff.

Just adding a note that I'm reassigning the Ubuntu Hardy kernel source package from 'linux-source-2.6.24' to just 'linux'. Beginning with the Hardy release the package naming convention changed from linux-source-2.6.x to just linux. Sorry for any confusion.

Hi Martijn,

Care to try the latest 2.6.24-7.12 kernel and verify this is still an issue? If so, please attach an update dmesg output. Thanks!

Changed in linux:
status: New → Incomplete
Matt Austin (mattaustin) wrote :

Still occurs using 2.6.24-16-generic on my EeePC (Ubuntu 8.04 LTS). Adding "modprobe -r snd-hda-intel" to /etc/init.d/halt is the workaround I have been using.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Matt Austin (mattaustin) wrote :

Confirming that this is still an issue in Intrepid Ibex Alpha 1 (Asus EeePC 701, kernel 2.6.26-2).

Adam McDaniel (adamrmcd) wrote :

This problem appears fixed in Alsa 1.0.17

Bradley Nampel (bnampel) wrote :

I haven't been able to follow development as closely as I have in the past. What are the chances of seeing 1.0.17 in Intrepid?

Matt Austin (mattaustin) wrote :

Confirming that this is still an issue in Intrepid Ibex Alpha 4 (Asus EeePC 701, latest updates with kernel 2.6.27-1-generic).

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Krinn (kr86420) wrote :

Problem still occurs using linux-image-2.6.27-1-generic on Asus Eee PC 900 (ALC662).

Tested my EeePC 701 (4G) with Intrepid Alpha 5. The module still fails to unload correctly.

Sitsofe Wheeler (sitsofe) wrote :

It might be worth noting that if you have ALSA Intel HDA (either within the kernel at compilation time or via sysfs) set to aggressive powersaving (e.g. after two seconds) then this problem will also go away. Both methods are outlined on http://www.thinkwiki.org/wiki/How_to_enable_AC97_power_saving .

The powersaving trick works, my EeePc (4G) doesn't hang on poweroff anymore. And I didn't notice any odd behavior playing sounds, nor any lag. Assuming this will also save some battery life I will start using it.

I followed the instructions supplied at the thinkwiki link. To write to sysfs you need to logon as root, using sudo won't work. So create a password for root, or better yet, include those commands in an init script.

Thanks Sitsofe!

Adam McDaniel (adamrmcd) wrote :

Tested on EeePC 900 (Realtek ALC62 rev1) using Hardy (Alsa 1.0.16) with the powersaving technique quoted by Sitsofe.

This is still a problem. The device will not shutdown if snd_hda_intel is still loaded.

Interesting side note #1: A known issue with snd_hda_intel is that the CPU never reaches C3 state while this module is loaded, according to powertop. Even after setting the power_save parameter, it never makes it there.

Interesting side note #2: Forcing the module to reload with "sudo alsa force-reload" will allow the CPU to move into C3, but playing anything out out of the soundcard keeps something active in the module as the C3 state is no longer attainable.

So, what's my point? :) ... If the CPU is able to reach C3 state with snd_hda_intel loaded, the device can power-off properly without manually unloading the module.

Sitsofe Wheeler (sitsofe) wrote :

Paulo:
I have no idea whether it saves any power or how much - I'll have to sit down and measure it. There might also be side effects but I haven't seen its effect on shutdown mentioned elsewhere.

Adam:
Are you sure? I have an EeePC 900 too and see the same results as Paulo. Remember it's not enough to "just" enable powersaving - you also have to set a timeout in seconds too. Since I have the ability to use modules compiled out of my kernel I can be sure snd_hda_intel is not being unloaded at any point and my machine powers off : )

On a related note my EeePC hits the C3 state for up to 100 ms (but then I'm using this timeout setting in sysfs/Kconfig for snd_hda). However according to my power meter this does not save me a watt of power (its resolution is only to a watt though so if it's saving 0.5W I wouldn't notice).

Sitsofe Wheeler (sitsofe) wrote :

Paulo:
Using sudo to get a root shell (e.g. /usr/bin/sudo -s ) will work. sudo cat "foo" /sysfs/... will not (unless you use tee too).

Adam McDaniel (adamrmcd) wrote :

@Sitsofe ... I just double checked. My 900 never reaches C3 with these power settings after playing sound. Are you running Intrepid? .. I cannot remember, has Intrepid upgraded to alsa 1.0.17?

If so, I know that snd_hda_intel's patch_realtek.c code has changed in this version. The EeePC's 901/1000/1000h models for example no longer have a shutdown issue (in my experience) under 1.0.17 as they did under hardy's 1.0.16.

I haven't upgraded my EeePC 900 to Intrepid quite yet. (Still validating some other legacy issues under hardy.) Perhaps I'll do that and double check these results.

Sitsofe Wheeler (sitsofe) wrote :

Adam:
Hmm. While I'm not using Intrepid I am using a hand compiled 2.6.27 prerelease kernel (from around a month ago) on Hardy. I shall see if Hardy's default kernel behaves as you describe. The default Hardy kernel is missing too many EeePC workarounds to make it useful for daily life.

Sitsofe:
Thanks for the tip on sudo. I have been investigating and there is yet another way for setting those parameters using the sysctl command. And it looks like the correct/best way of perpetuating the settings is through the /etc/sysctl.conf file, that loads sysctl values at boot time. See http://www.linux.com/feature/146599.

Sitsofe Wheeler (sitsofe) wrote :

Adam:
I've just retested with the 2.6.26-19-generic and my machine reaches C3 even when playing music in rhythmbox. I can only think that this might have something to do with BIOS versions (mine is 802) or some other piece of hardware in your machine (e.g. wifi card).

Adam McDaniel (adamrmcd) wrote :

Good carch. My 900 is running BIOS 0601.

I wonder if there's a difference in the sound card model too?
Attached is my "sudo lspci -v -nn". Note the system/vendor ID for the Audio card: [8086:2668]

Sitsofe Wheeler (sitsofe) wrote :

Same sound card.

Adam McDaniel (adamrmcd) wrote :

Confirmed, Sitsofe ;)

I upgraded to 0802 and I can now reach C3 state with ease, regardless of snd_hda_intel's status.

Also, the device powers off cleanly after setting "/sys/module/snd_hda_intel/parameters/power_save" to "10" Neat!

Rather than running sysctl on bootup each time to set these parameters, I've created a general modprobe.d file that does the same thing. (It also loads the 700-series specific parameter when needed, which was another hack I've previously worked on)

/etc/modprobe.d/eeepc:

install snd_hda_intel \
    if [ `/usr/sbin/dmidecode -s system-product-name` = "700" ]; then \
        /sbin/modprobe --ignore-install snd_hda_intel model=3stack-dig $CMDLINE_OPTS ; \
    else \
        /sbin/modprobe --ignore-install snd_hda_intel $CMDLINE_OPTS; \
    fi
options snd_hda_intel power_save=10 power_save_controller=Y

Adam McDaniel (adamrmcd) wrote :

I've just found something odd...

After setting the power_save parameter to "10", there is no output from the soundcard after 10 idle seconds.

I actually have to run "sudo alsa force-reload" before I get any sound again. (Ofcourse, the process repeats itself because I have "options snd_hda_intel power_save=10" in modprobe.d.)

I've yet to upgrade my EeePC 900 to Intrepid, so I don't know if this has been fixed in upstream alsa yet or not.
Can anyone else confirm this in hardy? .. If not, I'll upgrade this weekend and test again.

Sitsofe Wheeler (sitsofe) wrote :

Adam:
I can confirm the behaviour you describe (loss of sound after timeout when using power_save) with kernels before May (e.g. 2.6.22). The problem seems to have been fixed in later 2.6.26 kernels.

Adam McDaniel (adamrmcd) wrote :

I've upgraded my 900 to Intrepid alpha5 and the sound card continues works correctly with the "power_save=10" option.

Shutdown works correctly as well.

Luiz Capitulino (lcapitulino) wrote :

This issue has been discussed upstream and there is a patch available at:

http://bugzilla.kernel.org/show_bug.cgi?id=11889

Changed in linux:
status: Unknown → Confirmed
Changed in linux:
status: Confirmed → Fix Released

Luiz, thanks for the usptream reference. The patch you mention was recently applied to the Intrepid kernel when it pulled in the upstream 2.6.27.5 patch set - see Bug 296500:

ogasawara@yoji:~/ubuntu-intrepid$ git log -p 9293a8e3dd8a61f71510790af88430f6e32f86d6
commit 9293a8e3dd8a61f71510790af88430f6e32f86d6
Author: Takashi Iwai <email address hidden>
Date: Thu Oct 30 19:10:15 2008 +0000

    ALSA: hda - Add reboot notifier

    commit 0cbf00980f0fc4cc064a15ab3dfce19b5fae9130 upstream

    The current snd-hda-intel driver seems blocking the power-off on some
    devices like eeepc. Although this is likely a BIOS problem, we can add
    a workaround by disabling IRQ lines before power-off operation.
    This patch adds the reboot notifier to achieve it.

    The detailed problem description is found in bug#11889:
        http://bugme.linux-foundation.org/show_bug.cgi?id=11889

    Tested-by: Luiz Fernando N. Capitulino <email address hidden>
    Signed-off-by: Takashi Iwai <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Signed-off-by: Tim Gardner <email address hidden>

The Ubuntu kernel which contains this patch is still making it's way into the intrepid-proposed repository. If you can please monitor bug 296500 for when the kernel is available for testing in intrepid-proposed and provide feedback after testing that would be great. For information on how to enable -proposed, please see https://wiki.ubuntu.com/Testing/EnableProposed . The wiki uses 'hardy' in it's examples, so please make sure to use 'intrepid' instread. Thanks.

Changed in linux:
status: Triaged → Fix Committed

Actually, I'm just going to mark this as a duplicate of bug 296500 so that everyone is automatically notified when the kernel with this patch has been moved to the intrepid-proposed repository for testing. Please continue to track this bug at that report. I'll also make a note in the master bug 296500. Thanks.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

LinkedIn
------------

Bug,

Vorrei aggiungerti alla mia rete professionale su LinkedIn.

-nicola

nicola crupi
Libero professionista Internet
Maceió Area, Brazil

Conferma che conosci nicola crupi
https://www.linkedin.com/e/3seso8-gnvtfkzf-2w/isd/2935366537/8DPE-nZk/

--
(c) 2011, LinkedIn Corporation

Curtis Hovey (sinzui) on 2012-04-09
Changed in linux-source-2.6.22 (Ubuntu):
assignee: Registry Administrators (registry) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.