On Wed, Nov 27, 2019 at 08:46:36PM +0100, Hans de Goede wrote: > Hi, > > On 27-11-2019 20:40, 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) (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? > > Oh, that might explain why the fixes for this are confirmed as working by > some of our users, but not by all. > > Michal, are you perhaps using TLP or some similar software to tune / > improve power-management settings ? Or do you perhaps have some > custom files under /etc/modprobe.conf.d messing with these settings? > > Regards, > > Hans > OK. So that explains everything, it's working as intended with tlp disabled. I'm using tlp and I assumed, that if my tlp's configuration was working before, it should work now. Especially when I've checked live isos and was broken in exactly same way. Clearly I was wrong. BIG THANK YOU! Michał _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
