[alsa-devel] No sound and systemd journal filling when inserting headphones when power-saving is enabled
Dang Sananikone
dang.sananikone at gmail.com
Wed Feb 25 23:15:32 CET 2015
On 25 February 2015 at 06:59, Takashi Iwai <tiwai at 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 at 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:
> > > > 1. Boot up laptop.
> > > > 2. Insert headphone socket into jack.
> > > > 3. 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.
>
> > 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.
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <tiwai at 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 at gmail.com>
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai at 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 },
> --
> 2.3.0
>
>
More information about the Alsa-devel
mailing list