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 Tree: Mainline
Regression: Yes
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)

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)
Comment 12 Florian Mickler 2013-03-04 21:25:27 UTC
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