Bug 53441
| Summary: | hda_intel: sound stops working after suspend to ram | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Jose Marino (braket) |
| Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | alan, florian, superquad.vortex2, tiwai |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.7.6 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
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) |
||
which hda codec fail ? idt or hdmi Sound stopped working when using the built in speakers and headphone jack, so I guess that's idt, right? Does the problem persist even if you pass power_save_controller=0 option to snd-hda-intel? 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. 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. 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.
Created attachment 93191 [details]
Output from alsa-info.sh after a fresh reboot
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.
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. 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. Created attachment 93311 [details]
Fix patch (for 3.9)
A patch referencing this bug report has been merged in Linux v3.9-rc1: commit 2c1350fdeaefefe1a149d3b083383409f43f0daa Author: Takashi Iwai <tiwai@suse.de> Date: Thu Feb 14 09:44:55 2013 +0100 ALSA: hda - Disable runtime PM for Intel 5 Series/3400 |
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