* snd-hda-intel runtime PM fail after module reload
@ 2016-02-25 19:19 Ville Syrjälä
2016-02-25 20:28 ` Takashi Iwai
0 siblings, 1 reply; 4+ messages in thread
From: Ville Syrjälä @ 2016-02-25 19:19 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, intel-gfx
Hi,
My investigation into some sporadic i915 runtime PM failures seem to
point the finger at snd-hda-intel.
I just tried to play around unloding and reloading snd-hda-intel and
sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
but actually the device won't runtime suspend. At which point frobbing
with power/control is enough to kick it back into submission.
# for i in `seq 1 3`; do sleep 1 ; grep . /sys/bus/pci/devices/0000\:00\:03.0/power/* ; done
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:222657
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:223666
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:224674
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
# rmmod snd-hda-intel
# modprobe snd-hda-intel
# for i in `seq 1 3`; do sleep 1 ; grep . /sys/bus/pci/devices/0000\:00\:03.0/power/* ; done
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:121454
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:122463
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:123472
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
# echo on > /sys/bus/pci/devices/0000:00:03.0/power/control
# echo auto > /sys/bus/pci/devices/0000:00:03.0/power/control
# for i in `seq 1 3`; do sleep 1 ; grep . /sys/bus/pci/devices/0000\:00\:03.0/power/* ; done
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:141459
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:231699
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:141459
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:232706
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:03.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:03.0/power/control:auto
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:03.0/power/runtime_active_time:141459
/sys/bus/pci/devices/0000:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:03.0/power/runtime_suspended_time:233713
/sys/bus/pci/devices/0000:00:03.0/power/runtime_usage:0
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: snd-hda-intel runtime PM fail after module reload
2016-02-25 19:19 snd-hda-intel runtime PM fail after module reload Ville Syrjälä
@ 2016-02-25 20:28 ` Takashi Iwai
2016-02-25 21:57 ` Ville Syrjälä
0 siblings, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2016-02-25 20:28 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: alsa-devel, intel-gfx
On Thu, 25 Feb 2016 20:19:08 +0100,
Ville Syrjälä wrote:
>
> Hi,
>
> My investigation into some sporadic i915 runtime PM failures seem to
> point the finger at snd-hda-intel.
>
> I just tried to play around unloding and reloading snd-hda-intel and
> sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> but actually the device won't runtime suspend. At which point frobbing
> with power/control is enough to kick it back into submission.
Which platform are you testing? If it's SKL, BSW or later, multiple
codecs are on a single HD-audio bus. In general, you have to adjust
the runtime PM of all these codecs in addition to the runtime PM of
the controller. Some of them are immediately runtime PM enabled but
some of them aren't, left the default as is.
It might be that your desktop environment adjusts the runtime PM of
HD-audio stuff, often depending on the power state. But when you
reload, this adjustment is also lost, so you'd have to adjust
manually.
Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: snd-hda-intel runtime PM fail after module reload
2016-02-25 20:28 ` Takashi Iwai
@ 2016-02-25 21:57 ` Ville Syrjälä
2016-02-26 7:49 ` Takashi Iwai
0 siblings, 1 reply; 4+ messages in thread
From: Ville Syrjälä @ 2016-02-25 21:57 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, intel-gfx
On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> On Thu, 25 Feb 2016 20:19:08 +0100,
> Ville Syrjälä wrote:
> >
> > Hi,
> >
> > My investigation into some sporadic i915 runtime PM failures seem to
> > point the finger at snd-hda-intel.
> >
> > I just tried to play around unloding and reloading snd-hda-intel and
> > sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> > but actually the device won't runtime suspend. At which point frobbing
> > with power/control is enough to kick it back into submission.
>
> Which platform are you testing? If it's SKL, BSW or later, multiple
> codecs are on a single HD-audio bus. In general, you have to adjust
> the runtime PM of all these codecs in addition to the runtime PM of
> the controller. Some of them are immediately runtime PM enabled but
> some of them aren't, left the default as is.
This was on a HSW.
I also have CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 which I presume should
enable codec power saving by deafault?
> It might be that your desktop environment adjusts the runtime PM of
> HD-audio stuff, often depending on the power state. But when you
> reload, this adjustment is also lost, so you'd have to adjust
> manually.
There's no desktop environment. Well, unless you count systemd as such.
As you can see from the log I included at least the pci device power/control
file stayed at 'auto' the whole time until I flipped it to 'on' and then
back to 'auto' to fix the problem.
Also the problem didn't happen on every reload AFAICS, so there's
something rather non-deterministic happening.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: snd-hda-intel runtime PM fail after module reload
2016-02-25 21:57 ` Ville Syrjälä
@ 2016-02-26 7:49 ` Takashi Iwai
0 siblings, 0 replies; 4+ messages in thread
From: Takashi Iwai @ 2016-02-26 7:49 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: alsa-devel, intel-gfx
On Thu, 25 Feb 2016 22:57:34 +0100,
Ville Syrjälä wrote:
>
> On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> > On Thu, 25 Feb 2016 20:19:08 +0100,
> > Ville Syrjälä wrote:
> > >
> > > Hi,
> > >
> > > My investigation into some sporadic i915 runtime PM failures seem to
> > > point the finger at snd-hda-intel.
> > >
> > > I just tried to play around unloding and reloading snd-hda-intel and
> > > sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> > > but actually the device won't runtime suspend. At which point frobbing
> > > with power/control is enough to kick it back into submission.
> >
> > Which platform are you testing? If it's SKL, BSW or later, multiple
> > codecs are on a single HD-audio bus. In general, you have to adjust
> > the runtime PM of all these codecs in addition to the runtime PM of
> > the controller. Some of them are immediately runtime PM enabled but
> > some of them aren't, left the default as is.
>
> This was on a HSW.
OK, then the HDMI/DP has its own controller.
> I also have CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 which I presume should
> enable codec power saving by deafault?
Yes, unless something overwrites it. Often there are udev rules to
override something for that.
> > It might be that your desktop environment adjusts the runtime PM of
> > HD-audio stuff, often depending on the power state. But when you
> > reload, this adjustment is also lost, so you'd have to adjust
> > manually.
>
> There's no desktop environment. Well, unless you count systemd as such.
> As you can see from the log I included at least the pci device power/control
> file stayed at 'auto' the whole time until I flipped it to 'on' and then
> back to 'auto' to fix the problem.
It implies that the problem is the PM layer itself...
> Also the problem didn't happen on every reload AFAICS, so there's
> something rather non-deterministic happening.
In anyway, please check the runtime PM status in the codec devices,
i.e. /sys/bus/hdaudio/devices/*. The controller runtime PM is
activated only when the codec is power-saved.
If the codec is in runtime-suspended but the controller still doesn't,
put some debug codes in azx_runtime_idle() in
sound/pci/hda/hda_intel.c, whether any EBUSY condition there hits.
Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-26 7:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-25 19:19 snd-hda-intel runtime PM fail after module reload Ville Syrjälä
2016-02-25 20:28 ` Takashi Iwai
2016-02-25 21:57 ` Ville Syrjälä
2016-02-26 7:49 ` Takashi Iwai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.