[alsa-devel] kernel oops related to the new HDA audio handling for DP MST

Wed Nov 27 20:47:22 CET 2019

On Wed, Nov 27, 2019 at 08:40:41PM +0100, Takashi Iwai wrote:
> On Wed, 27 Nov 2019 20:31:20 +0100,
> Hans de Goede wrote:
> > 
> > Hi,
> > 
> > On 27-11-2019 20:27, Takashi Iwai wrote:
> > > On Wed, 27 Nov 2019 20:24:49 +0100,
> > > Takashi Iwai wrote:
> > >>
> > >> On Wed, 27 Nov 2019 19:52:37 +0100,
> > >> Michał Matysiak wrote:
> > >>>
> > >>> On Wed, Nov 27, 2019 at 06:00:17PM +0100, Takashi Iwai wrote:
> > >>>> On Wed, 27 Nov 2019 16:57:04 +0100,
> > >>>> Takashi Iwai wrote:
> > >>>>>
> > >>>>> On Wed, 27 Nov 2019 16:46:00 +0100,
> > >>>>> Hans de Goede wrote:
> > >>>>>>
> > >>>>>> Hi Takashi,
> > >>>>>>
> > >>>>>> On 27-11-2019 15:39, Takashi Iwai wrote:
> > >>>>>>> On Wed, 27 Nov 2019 15:26:37 +0100,
> > >>>>>>> Michał Matysiak wrote:
> > >>>>>>>>
> > >>>>>>>> Hi
> > >>>>>>>>
> > >>>>>>>> Recently I've encountered this error and as Hans de Goede's request I'm
> > >>>>>>>> reporting this back to you. This happens while booting my laptop
> > >>>>>>>> connected to docking station and without using one.
> > >>>>>>>>
> > >>>>>>>> kernel: WARNING: CPU: 1 PID: 330 at sound/hda/hdac_component.c:290 snd_hdac_acomp_init+0xde/0x130 [snd_hda_core]
> > >>>>>>>> There are 2 more "cut here", but they're almost identical so I've only
> > >>>>>>>> included one in this email.
> > >>>>>>>>
> > >>>>>>>> Don't know what will be valuable to you, but I'm willing to help test
> > >>>>>>>> this and do what I'm told. So, how can I help?
> > >>>>>>>>
> > >>>>>>>> More info about this particular kernel and issue, that led to this is at:
> > >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1757891
> > >>>>>>>>
> > >>>>>>>> dmesg output:
> > >>>>>>>>
> > >>>>>>>> Nov 26 18:05:45 kernel: microcode: microcode updated early to revision 0x2f, date = 2019-02-17
> > >>>>>>>> Nov 26 18:05:45 kernel: Linux version 5.4.0-0.rc8.git0.1.rhbz1757891.fc31.x86_64 (mockbuild at buildhw-10.phx2.fedoraproject.org) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Wed Nov 20 14:50:34 UTC 2019
> > >>>>>>>> Nov 26 18:05:45 kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.4.0-0.rc8.git0.1.rhbz1757891.fc31.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-efd8b438-8f56-405a-8cea-88f83ca38d2b rd.lvm.lv=fedora/swap rhgb quiet
> > >>>>>>>> ...
> > >>>>>>>> ...
> > >>>>>>>> ...
> > >>>>>>>> Nov 26 18:06:16 kernel: ------------[ cut here ]------------
> > >>>>>>>> Nov 26 18:06:16 kernel: WARNING: CPU: 0 PID: 461 at sound/hda/hdac_component.c:290 snd_hdac_acomp_init+0xde/0x130 [snd_hda_core]
> > >>>>>>>
> > >>>>>>> This should have been already fixed by the recent commit
> > >>>>>>> 5a858e79c911330678b5a9be91a24830e94a0dc9
> > >>>>>>>       ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs
> > >>>>>>> which is already included in Linus tree.  Please check it.
> > >>>>>>
> > >>>>>> Thanks, I've started a scratch kernel build with the relevant patches added,
> > >>>>>> for the Fedora users hitting this to test.
> > >>>>>>
> > >>>>>> The reason they started looking into their dmesg is that their nvidia GPU (hybrid gfx setup)
> > >>>>>> will no longer suspend with recent kernels, this is with a 5.4 kernel which already has the
> > >>>>>>
> > >>>>>> "ALSA: hda - Force runtime PM on Nvidia HDMI codecs"
> > >>>>>>
> > >>>>>> Fix and for good measure I've already given them a test kernel with the:
> > >>>>>> "ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a drive"
> > >>>>>>
> > >>>>>> patch added. But looking at the fix for the oops I'm not sure if fixing
> > >>>>>> the oops is also going to fix the issue with the dGPU no longer suspending?
> > >>>>>
> > >>>>> I guess it's irrelevant with that problem, as this kernel warning (not
> > >>>>> really an Oops) is just about skipping the multiple audio component
> > >>>>> registration.  And the audio component isn't used in nouveau side on
> > >>>>> 5.4.x at all, and it's just a placeholder.  But who knows the black
> > >>>>> magic behind the scene :)
> > >>>>
> > >>>> ... and if this still doesn't fix the problem, please check the
> > >>>> runtime PM state of all HD-audio codec devices and HD-audio controller
> > >>>> device.  Do all show the runtime-suspended but the power consumption
> > >>>> is high?  Or is some device blocked?
> > >>>>
> > >>>> Basically the audio controller corresponding to the dGPU should have
> > >>>> chip->bus.keep_power = 0, which allows the runtime PM.  This flag is
> > >>>> cleared at azx_vx_gpu_bound() only for the dGPU.  For the primary GPU,
> > >>>> we need to keep the link power unless the notification is done via the
> > >>>> audio component (like i915 or amdgpu).  I already submitted a patch to
> > >>>> enable the audio component for nouveau in the past, but it's ignored,
> > >>>> so far.
> > >>>>
> > >>>>
> > >>>> thanks,
> > >>>>
> > >>>> Takashi
> > >>>
> > >>> Hi Takashi
> > >>>
> > >>> On linux-next-20191127 warning indeed disappeared. Thanks!
> > >>>
> > >>> Rest of problems did not. This is my output from alsa-info.sh
> > >>> http://alsa-project.org/db/?f=91bb789a01f9eed92d0534fe8951619312b355da
> > >>> Don't know if it's helpful, so I'll leave it here. Power consumption is
> > >>> high, because runtime-suspended is not enabled/active (and cannot be
> > >>> forced) without removing nvidia's audio.
> > >>
> > >> What if you pass power_save=1 to snd-hda-intel option?
> > >>
> > >>    echo -n 1 > /sys/module/snd_hda_intel/parameters/power_save
> > >
> > > and the following, too:
> > >      echo -n 1 > /sys/module/snd_hda_intel/parameters/power_save_controller
> > >
> > > Otherwise the controller device will keep on.
> > 
> > Thank you for helping us getting to the root of this.
> > 
> > These both default to 1 resp. Y on Fedora kernels, so I do not think
> > that this will help, as they are both already 1/Y.
> 
> Well, the alsa-info.sh output Michal suggested shows differently:
>   http://alsa-project.org/db/?f=91bb789a01f9eed92d0534fe8951619312b355da
> 
>   !!Loaded sound module options
>   !!---------------------------
>   ....
>   power_save : 0
>   power_save_controller : N
> 
> If these values are true, maybe some desktop tuning modifies on the
> fly?
> 
> 
> Takashi

I'll check it in a few. This was linux next with config from some fedora
rawhide kernel. Don't know if this values are like defaults from
F31, and I didn't exec alsa-info.sh on Hans de Goede's kernel, so I'll
add this also.

Michał