ALso see: http://bugzilla.kernel.org/show_bug.cgi?id=12321 With all kernels starting from commit 1289e9e8b42f973f2ab39e5f4f2239ff826c27e9 Author: Takashi Iwai <tiwai@suse.de> Date: Thu Nov 27 15:47:11 2008 +0100 ALSA: hda - Modularize HD-audio driver the init script for alsa locks the shutdown/restart process, because it tries to unload alsa modules in the wrong order, at least with intel hd audio Reproducible: Always Steps to Reproduce: 1. install kernel > 2.6.28 2. reboot/shutdown 3. Actual Results: system does not shut down
According to the kernel bugzilla link you posted, this problem is not a kernel bug but a problem on alsa init script. Which sources did you try to reproduce that? git? We cant support git sources. Since this bug is already filled upstream we can observe it :)
I am using kernel sources from kernel.org, live git. I mailed Takashi Iwai about the change he made in the kernel, and it is not a kernel bug, but a change, which will also hit gentoo's sources beginning with 2.6.29-rc. The problem is, as Takashi stated here: lkml.org/lkml/2009/1/3/34 [The init script] seems to try to remove the modules that are being used at shutdown. It seems to be a general bug, as init is not checking, if modules are still used. Therefor it is a bug in the init system, and maybe it should not be assigned to kernel but to baselayout or wherever init stuff is.
That is what I though I ll CC base-system team on this bug, plus I ll mark it as UPSTREAM. We will keelp an eye on it :)
Re opening this bug since it is best to let alsa-bugs guys to look at this
Adding kernel team to CC in order to keep an eye on it
I just thought that might be of some interest: The modules, which are loaded, show up in lsmod like: Module Size Used by snd_seq_dummy 5252 0 snd_seq_oss 34752 0 snd_seq_midi_event 9344 1 snd_seq_oss snd_seq 56992 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 9108 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 43808 0 snd_mixer_oss 18048 1 snd_pcm_oss snd_hda_codec_analog 80896 1 snd_hda_intel 30408 0 snd_hda_codec 61888 2 snd_hda_codec_analog,snd_hda_intel snd_pcm 81544 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec snd_timer 23952 2 snd_seq,snd_pcm snd 63688 10 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer snd_page_alloc 11408 2 snd_hda_intel,snd_pcm The problem now is the following: snd_hda_intel depends on snd_hda_codec_analog, even if it is not shown in lsmod. so as it removes them kind of alphabetically, it fails with snd_hda_codec_analog. Adding rmmod snd_hda_intel in the beginning of unload_modules_26 in /etc/init.d/alsasound fixes the problem.
So what happens if you manually run "rmmod snd_hda_codec_analog" before removing snd_hda_intel? Error message? Kernel crash?
ERROR: Module snd_hda_codec_analog is in use
Created attachment 178134 [details, diff] Proposed patch Sorts loaded drivers by "Used By" count field, before unloading Uses "modprobe -r" instead of "rmmod --wait" to unload drivers
i got the same problem; using alsa hda realtek 262 on sony vaio sr19xn; if it can help, here is my lsmod output; as you can see in my system related to audio there is only snd_hda_intel module but it fails anyway. remotehost linux # lsmod Module Size Used by snd_hda_intel 247244 0 i915 55620 2 btusb 11352 6 iwlagn 70084 0 iwlcore 72000 1 iwlagn sdhci_pci 7040 0 sky2 43396 0 mac80211 129680 2 iwlagn,iwlcore sdhci 15236 1 sdhci_pci sony_laptop 31132 0 ehci_hcd 33036 0 uhci_hcd 21644 0
Have you tried setting UNLOAD_ON_STOP to "no" in your /etc/conf.d/alsasound ? Takashi Iwai says that there is no need for the modules to be unloaded on shutdown and the upstream bug reporter at http://bugzilla.kernel.org/show_bug.cgi?id=12321 confirmed that this fixed the hangs.
(In reply to comment #11) > Have you tried setting UNLOAD_ON_STOP to "no" in your /etc/conf.d/alsasound ? > Takashi Iwai says that there is no need for the modules to be unloaded I wholeheartedly agree with that sentiment. As of ALSA 1.0.19 automatic module unloading is disabled. We will no longer support it, but it is there for those who want it for a few more releases. (Until, like all broken code, it gets tipped into the bit bucket) Sorry for the inconvenience and thanks for reporting a bug.
*** Bug 254816 has been marked as a duplicate of this bug. ***
*** Bug 258413 has been marked as a duplicate of this bug. ***
this module unloading code works, btw: mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) while [ -n "$mod" ]; do mod=${mod%% *} /sbin/modprobe -r $mod mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) done
i have the same problem on an x86 build. however, apart from the unloading to never finish, the sound on my system has stopped working.
*** Bug 264674 has been marked as a duplicate of this bug. ***
*** Bug 263973 has been marked as a duplicate of this bug. ***
*** Bug 268365 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > this module unloading code works, btw: > > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > while [ -n "$mod" ]; do > mod=${mod%% *} > /sbin/modprobe -r $mod > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > done > I have Tested it,WOW! It works.
(In reply to comment #15) > this module unloading code works, btw: > > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > while [ -n "$mod" ]; do > mod=${mod%% *} > /sbin/modprobe -r $mod > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > done > i confirm the above code is working fine for me on 2.6.29-gentoo-r3 with hda-intel. the attached alsasound.patch file does stop alsa too, but on the contrary with this FATAL: * Service alsasound stopping FATAL: Module snd_hda_codec_analog is in use. * Service alsasound stopped
*** Bug 271363 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > ERROR: Module snd_hda_codec_analog is in use > There seems to be a bug here - snd_hda_codec_analog has count 1, but does not list the module that uses it
(In reply to comment #23) > (In reply to comment #8) > > ERROR: Module snd_hda_codec_analog is in use > > > > There seems to be a bug here - snd_hda_codec_analog has count 1, but does not > list the module that uses it > that's not a bug. it is a 'dynamic' module dependancie. this is, it is not clear at compile time which modules will use it. (or smth like that) (dynamic in contrast to static module dependancies)
hit this bug with gentoo-sources-2.6.29-r5 being marked stable for amd64. it is important to note that the workaround of disabling unloading of the modules is not yet the default for the current stable version of alsa-utils making this bug IMHO having a not "resolved" state at least for "amd64". if nothing else, reopening this bug will help people find this workaround faster and probably prevent duplicated bugs (like probably BUG271880) to be filed.
I agree with Carlo. Now that 2.6.29-r5 is stable on amd64, a lot more people will need to find this workaround, and preferably alsa-utils should be updated with correct default behavior and an appropriate elog.
*** Bug 271880 has been marked as a duplicate of this bug. ***
*** Bug 272743 has been marked as a duplicate of this bug. ***
*** Bug 273241 has been marked as a duplicate of this bug. ***
The patch works for me on amd64 , 2.6.29 kernel and snd_hda modules.
Setting UNLOAD_ON_STOP to "no" in your /etc/conf.d/alsasound works for me.
Also works for me! What would be the reason to unload the modules before shutdown?
*** Bug 275421 has been marked as a duplicate of this bug. ***
*** Bug 275783 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > hit this bug with gentoo-sources-2.6.29-r5 being marked stable for amd64. > > it is important to note that the workaround of disabling unloading of the > modules is not yet the default for the current stable version of alsa-utils > making this bug IMHO having a not "resolved" state at least for "amd64". Also hit this bug on STABLE x86. This leaves the system in a frozen state such that file journals need to be replayed after a hard reset. I don't think such a severe bug should be marked resolved until the fix to the configuration file hits stable and get fixed by normal dispatch-conf means. Please reopen and assign it to the right package and get the fix into stable ASAP.
(In reply to comment #35) > Also hit this bug on STABLE x86. This leaves the system in a frozen state such > that file journals need to be replayed after a hard reset. I don't think such a > severe bug should be marked resolved until the fix to the configuration file > hits stable and get fixed by normal dispatch-conf means. Please reopen and > assign it to the right package and get the fix into stable ASAP. > Just wanted to send out a thank you to whoever pushed the configuration file update through, as I know no one is paying you to do these things. THANKS!
This isn't a complaint - I just wanted to point out something minor-ish: I agree that the unloading of modules during shutdown is obviously pointless, which leads me to suspect that *that* wasn't the reason the unloading functionality was implemented. Rather, it's likely that the thought was that a user should be able to "/etc/init.d/alsasound stop" at will for whatever reason, and be secure in the knowledge that he's just unloaded the alsa environment. There are many possible reasons for wanting to do that - the most obvious is for users who are still using media-sound/alsa-driver, which hopefully isn't many anymore - for them "/etc/init.d/alsasound restart" used to complete their upgrade by unloading and re-loading the driver modules. With these changes, it will silently *not* load the upgraded modules.
(In reply to comment #37) > This isn't a complaint - I just wanted to point out something minor-ish: I > agree that the unloading of modules during shutdown is obviously pointless, > which leads me to suspect that *that* wasn't the reason the unloading > functionality was implemented. Rather, it's likely that the thought was that a > user should be able to "/etc/init.d/alsasound stop" at will for whatever > reason, and be secure in the knowledge that he's just unloaded the alsa > environment. There are many possible reasons for wanting to do that - the most > obvious is for users who are still using media-sound/alsa-driver, which > hopefully isn't many anymore - for them "/etc/init.d/alsasound restart" used to > complete their upgrade by unloading and re-loading the driver modules. With > these changes, it will silently *not* load the upgraded modules. > I agree with this, and don't think it is something minor.
(In reply to comment #15) > this module unloading code works, btw: > > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > while [ -n "$mod" ]; do > mod=${mod%% *} > /sbin/modprobe -r $mod > mod=$(grep -m1 -E '^(snd[^ ]*|ac97_bus) [0-9]+ 0' /proc/modules) > done > +1 to that
I have run into this issue with 2.6.31-gentoo-r6 I tried the UNLOAD_ON_STOP to no avail. I want to try the code change mentioned below (http://bugs.gentoo.org/show_bug.cgi?id=253535#c15) but i can not figure out WHERE it goes? I am guessing /etc/init.d/alsasound in stop? This is what i have already? stop() { if [ ! -d /proc/asound ] ; then eerror "ALSA is not loaded" return 0 fi [ "${SAVE_ON_STOP}" = "yes" ] && save ebegin "Killing processes using ALSA" terminate eend 0 if [ -f /proc/modules ]; then local ver="24" rmmod --version | grep -q module-init-tools && ver="26" ebegin "Unloading ALSA modules" eindent unload_modules_${ver} eend $? eoutdent fi return 0 }
