At Wed, 25 Feb 2015 22:15:32 +0000, Dang Sananikone wrote:
On 25 February 2015 at 06:59, Takashi Iwai tiwai@suse.de wrote:
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?
Yes, it is equal to the value specified in the power_save option. I changed power_save to 10 and the frequency changed to 10 seconds.
OK, then this is some artifact by the codec power down. Maybe we can reduce it by tweaking something, e.g. skipping the pin shutdown or putting some longer delay at EAPD flip. But it's basically a different issue from the hang you reported.
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.
I set "options snd_hda_intel power_save=600", then performed the following actions:
- Reboot laptop.
- Invoke "speaker-test -c 2", and wait for audio to play.
- Enter suspend mode by calling "systemctl suspend" in another terminal
---> audio stops playing.
- Exit suspend mode ---> audio restarts playing.
So, the same problem does not exist when entering/exiting suspend state.
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?
I set "options snd_hda_intel power_save=1", then built and installed the kernel with the patched file. Invoking "speaker-test -c 2" caused no program hang and the audio was what I expected. Upon stopping the program I could hear the periodic blip. Upon repeated test, sometimes there was a periodic blip, sometimes there wasn't.
OK, I'll queue the patch.
Takashi