|Summary:||hda_intel: sound stops working after suspend to ram|
|Product:||Drivers||Reporter:||Jose Marino (braket)|
|Component:||Sound(ALSA)||Assignee:||Jaroslav Kysela (perex)|
|Severity:||normal||CC:||alan, florian, superquad.vortex2, tiwai|
dmesg showing error messages
Output from alsa-info.sh right after bug happened
Output from alsa-info.sh after a fresh reboot
dmesg showing reload of iwlwifi and hda-intel bug
Fix patch (for 3.9)
Description Jose Marino 2013-02-05 21:40:31 UTC
Created attachment 92591 [details] dmesg showing error messages On a fresh boot the sound card works fine. After a few suspends to ram (it doesn't necessarily happen after just one) the sound card stops working well. The sound comes out chopppy, as a series of clicks separated by 2 second or so silences. I see these messages in the kernel log right after resume: hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x00170503 hda-intel: No response from codec, disabling MSI: last cmd=0x00170503 hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x00170503 The only way to fix the sound seems to be a reboot. I don't have this problem with v3.6.11, it appeared with kernel v3.7.1 (I have not tested v3.7). Right now I'm running 3.7.6 and the problem is still there. $ lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05) 01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) $ lsmod | grep snd snd_hda_codec_hdmi 24993 4 snd_hda_codec_idt 54740 1 snd_hda_intel 24840 6 snd_hda_codec 71155 3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel snd_pcm 74322 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel snd_page_alloc 7333 2 snd_pcm,snd_hda_intel snd_timer 17563 1 snd_pcm
Comment 1 Raymond 2013-02-06 05:23:32 UTC
which hda codec fail ? idt or hdmi
Comment 2 Jose Marino 2013-02-06 15:48:27 UTC
Sound stopped working when using the built in speakers and headphone jack, so I guess that's idt, right?
Comment 3 Takashi Iwai 2013-02-06 16:39:43 UTC
Does the problem persist even if you pass power_save_controller=0 option to snd-hda-intel?
Comment 4 Jose Marino 2013-02-06 16:55:52 UTC
I'll test passing power_save_controller=0 and I'll report back. Let me also point out that sometimes I can go through quite a few suspend/resume cycles without triggering the bug, so this may take a while.
Comment 5 Takashi Iwai 2013-02-06 17:07:46 UTC
OK. Also, please get alsa-info.sh output at working and non-working states. Also, if the problem appears, test whether reloading the sound driver module helps or not. If it doesn't help, it implies that the problem in a deeper level, such as PCI core or ACPI. In that case, I'd ask you for git bisection.
Comment 6 Jose Marino 2013-02-13 05:01:36 UTC
Created attachment 93181 [details] Output from alsa-info.sh right after bug happened Finally I saw this problem happen again. For the longest time I could not reproduce the problem. I did not reboot the laptop for over 6 days, with lots of suspend/resume cycles, and sound worked fine the whole time. This afternoon, I upgraded to 3.7.7 and after suspending twice or so the problem happened again. I'm attaching the output of alsa-info.sh taken right after the problem happened and taken after a fresh reboot right after. I'll test passing power_save_controller=0 option to snd-hda-intel and see if I can reproduce the problem.
Comment 7 Jose Marino 2013-02-13 05:02:19 UTC
Created attachment 93191 [details] Output from alsa-info.sh after a fresh reboot
Comment 8 Jose Marino 2013-02-13 05:35:12 UTC
Created attachment 93201 [details] dmesg showing reload of iwlwifi and hda-intel bug Oh boy I'm on a roll. I just reproduced the bug again. This time I tested reloading the sound driver as suggested and after reloading the modules the sound works fine again. This is what I did: $ rmmod snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hda_intel (had to run it a few times to get them all) And then: $ modprobe snd_hda_intel This is just a guess at this point but I was able to reproduce the snd-hda bug by reloading the wireless modules iwlwifi & iwldvm. The iwlwifi driver has never worked perfectly for this laptop, so earlier I was forced to reload it and that's when the snd-hda bug showed up. After the fresh reboot I repeated the reloading of iwlwifi on a hunch and the snd-hda bug happened again. I'll test a few times to see if I can reliably reproduce it. For now I'll attach the dmesg since the reboot: with reloading of iwlwifi module, bug appearing, and reloading of snd-hda-intel to fix the sound.
Comment 9 Jose Marino 2013-02-13 18:27:09 UTC
I found a way to reliably reproduce the bug: - Boot - Play sound (aplay /usr/share/sounds/alsa/Front_Center.wav) -> all is good - Wait a few seconds until I hear a small squeak/chirp - Reload wireless drivers (rmmod iwldvm iwlwifi ; modprobe iwlwifi) - Suspend/resume - Play sound -> it works fine - Wait for the squeak/chirp - Reload wireless drivers - Suspend/resume - Play sound -> Bug appears If I pass power_save_controller=0 to snd-hda-intel the bug does not occur.
Comment 10 Takashi Iwai 2013-02-14 08:49:28 UTC
OK, then I added the patch below to sound git tree now. You can keep power_save_controller=0 option. It's essentially doing the same thing.
Comment 11 Takashi Iwai 2013-02-14 08:50:04 UTC
Created attachment 93311 [details] Fix patch (for 3.9)