No sound and systemd journal filling when inserting headphones when power-saving is enabled

Commit Message

Takashi Iwai Feb. 25, 2015, 6:59 a.m. UTC

At Tue, 24 Feb 2015 22:26:32 +0000,
Dang Sananikone wrote:
> 
> On 24 February 2015 at 20:57, Takashi Iwai <[e-mail]> 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?

> 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 <[e-mail]>
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 <[e-mail]>
Cc: <[e-mail]>
Signed-off-by: Takashi Iwai <[e-mail]>
---
 sound/pci/hda/hda_intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Dang Sananikone Feb. 25, 2015, 10:15 p.m. UTC | #1

On 25 February 2015 at 06:59, Takashi Iwai <[e-mail]> wrote:

> At Tue, 24 Feb 2015 22:26:32 +0000,
> Dang Sananikone wrote:
> >
> > On 24 February 2015 at 20:57, Takashi Iwai <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> Cc: <[e-mail]>
> Signed-off-by: Takashi Iwai <[e-mail]>
> ---
>  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
>
>

Takashi Iwai Feb. 26, 2015, 8:12 a.m. UTC | #2

At Wed, 25 Feb 2015 22:15:32 +0000,
Dang Sananikone wrote:
> 
> On 25 February 2015 at 06:59, Takashi Iwai <[e-mail]> wrote:
> 
> > At Tue, 24 Feb 2015 22:26:32 +0000,
> > Dang Sananikone wrote:
> > >
> > > On 24 February 2015 at 20:57, Takashi Iwai <[e-mail]> 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.

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

Patch

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 },