At Tue, 24 Feb 2015 22:26:32 +0000, Dang Sananikone wrote:
On 24 February 2015 at 20:57, Takashi Iwai tiwai@suse.de wrote:
At Tue, 24 Feb 2015 20:11:58 +0000, Dang Sananikone wrote:
Thanks, in that case I'll simply attach the files to this post. There are two files:
- alsa-info-notworking.txt: This is the alsa info generated when
power-saving is enabled and after "speaker-test" has been invoked.
- alsa-info-working.txt: This is the alsa info generated when
power-saving
is disabled and after "speaker-test" has been invoked.
To reproduce the problem:
Prerequisite: Set "options snd_hda_intel power_save=1"
Instructions:
- Boot up laptop.
- Insert headphone socket into jack.
- In terminal, type "speaker-test -c 2".
Expected Result: The speaker-test program hangs, and the systemd journal starts filling up with "sound hdaudioC0D0: hda-codec: out of range cmd 0:1:716:ffffffff" messages.
OK, then try to pass power_save_controller=0 option to snd-hda-intel module. It might be that the controller gets screwed up by some reason by power-saving.
If I've understood you correctly I've set the following options: "options snd_hda_intel power_save=1 power_save_controller=0".
Then I've plugged in my headphones before invoking speaker-test. With no audio playing I hear a blip sound every second.
Every second? Is this equal with the length you specified to power_save option? i.e. if you pass power_save=10, the frequency of blip noise changes, too?
Then I invoke "speaker-test -c 2" and I hear the speaker test audio I expect to hear. The program does not hang. After killing the program and with no audio playing I hear the blip sound every second.
So, the problem was basically the HD-audio controller screwed up by the power-saving. BTW, didn't you see the same problem with the explicit suspend/resume (S3 and S4)? For testing it, try a bigger value in power_save so that you go to S3/S4 before the power save is triggered.
If this still doesn't help, we need more logs. Build the kernel with tracing support, and get the HD-audio verb traces as Documentation/sound/alsa/HD-Audio.txt, section Tracepoints.
Takashi
Going back to this setting I set out to get the HD-audio verbs to provide more information: "options snd_hda_intel power_save=1".
I've attached the trace file which was generated after following your instructions (I think the kernel already had tracing support enabled judging by the /proc/config.gz config parameters).
The trace already shows the bad read from the controller, so it's likely an issue in the HDA controller and/or communication.
In anyway, below is a patch to disable runtime PM of the controller again. It's equivalent as passing power_save_controller=1. Could you give it a test?
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable runtime PM for Panther Point again
This is essentially a partial revert of the commit [b1920c21102a: 'ALSA: hda - Enable runtime PM on Panther Point']. There was a bug report showing the HD-audio bus hang during runtime PM on HP Spectre XT.
Reported-by: Dang Sananikone dang.sananikone@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 36d2f20db7a4..4ca3d5d02436 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1966,7 +1966,7 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Panther Point */ { PCI_DEVICE(0x8086, 0x1e20), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Lynx Point */ { PCI_DEVICE(0x8086, 0x8c20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },