Kernel 5.6: system freeze when resuming from suspend or hibernate

I followed the guide from that post but it seems nvidia audio can not be turned on no matter what.

snd_hda_intel 0000:01:00.1: can’t change power state from D3cold to D0 (config space inaccessible)
snd_hda_intel 0000:01:00.1: can’t change power state from D3hot to D0 (config space inaccessible)

01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

I have dual boot with Windows 10, I checked in Windows and that audio device is not present either. But then again, HDMI output I have comes from integrated graphics, not nvidia. So 740M card doesn’t have any outputs. My guess is that audio device is disabled by manufacturer’s (ASUS) design. Windows 10 comes from stand by mode just fine, maybe nvidia driver tries to power audio unconditionally.
I’ll try to remove those udev rules completely.

UPDATE: Nope, that didn’t help

Thank you, @generix, for pointing me in the right direction! I added the simple udev rule to remove problematic device completely:

cat /etc/udev/rules.d/10-remove-nvidia-audio.rules
ACTION==“add”, KERNEL==“0000:01:00.1”, SUBSYSTEM==“pci”, RUN+="/bin/sh -c ‘echo 1 > /sys/bus/pci/devices/0000:01:00.1/remove’"

Now lspci doesn’t list the device. And the problem is gone! Laptop wakes up perfectly!

Nice sleuthing tracking that down.

I wonder if this problem is related to a workaround in the Linux kernel that tries to enable audio on NVIDIA devices in laptops that normally disable them at boot and expect the Windows driver to enable it dynamically. There was a thread about this recently: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

It’s possible that this Linux kernel quirk is enabling the audio function on your GPU when it really doesn’t have one, causing this problem.

The quirk was introduced in kernel 5.4, the discussions back then resembled the new one, really a déja vue.
Though I guess while the dead audio device being the trigger, the cause is the new power management, as to why it needs to access the audio device and hangs if it’s inaccessible. Since the other thread linked here showed this can happen in other ways, too.