Bug 200937

Looks like the HD-audio on the discrete AMD GPU had a trouble
  [   93.478837] snd_hda_intel 0000:67:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x003f0900

This indicates already something odd happened.  Likely a problem of vga_switcheroo and runtime PM.

Lukas, any clue?

Also, is this a regression?  If yes, which kernel did work?

@Aleksandr Mezin: Please add log_buf_len=10M to the kernel command line so that dmesg output is not truncated.

The HDA codec on the AMD GPU is unresponsive after the first system sleep cycle:

[   93.478837] snd_hda_intel 0000:67:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x003f0900
[  135.705372] snd_hda_intel 0000:67:00.1: No response from codec, disabling MSI: last cmd=0x003f0900

Question is why.  Perhaps the BIOS disables the codec on system sleep?  Could you attach an acpidump and the output of "lspci -vv" after the first system sleep cycle?

The issue exposes a bug in hda_jackpoll_work() for unresponsive cards wherein the work item deadlocks because it tries to cancel itself:

hda_jackpoll_work()
  snd_hda_jack_poll_all()
    jack_detect_update()
      read_pin_sense()
        codec_read()
          codec_exec_verb()
            snd_hda_bus_reset()
              snd_hda_bus_reset_codecs()
                /* FIXME: maybe a better way needed for forced reset */
                cancel_delayed_work_sync(&codec->jackpoll_work);

The reason why hda_codec_runtime_suspend() hangs is because it also tries to cancel jackpoll_work,
so it's just a victim of the combination of unresponsive card plus hda_jackpoll_work() deadlock.

(In reply to Lukas Wunner from comment #3)
> The issue exposes a bug in hda_jackpoll_work() for unresponsive cards
> wherein the work item deadlocks because it tries to cancel itself:

Yeah, that looks like a side-effect by the unexpected communication error.
A patch like below may avoid the deadlock (but totally untested):

--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3935,7 +3935,8 @@ void snd_hda_bus_reset_codecs(struct hda_bus *bus)
 
        list_for_each_codec(codec, bus) {
                /* FIXME: maybe a better way needed for forced reset */
-               cancel_delayed_work_sync(&codec->jackpoll_work);
+               if (current_work() != &codec->jackpoll_work.work)
+                       cancel_delayed_work_sync(&codec->jackpoll_work);
 #ifdef CONFIG_PM
                if (hda_codec_is_power_on(codec)) {
                        hda_call_codec_suspend(codec);


Of course, this doesn't fix the root cause, though.

I could reproduce the issue artificially and confirmed that the change in comment 4 works around it, so it's queued in for-linus branch for the next pull request.

It doesn't address the root cause -- why it hits the communication error, though.

Seems that there are multiple suspend/resume related issues with Vega https://bugzilla.kernel.org/show_bug.cgi?id=200531, https://bugzilla.kernel.org/show_bug.cgi?id=201015 (on 4.18 even a monitor switching to standby can cause the driver to hang), so probably there's no bug in snd_hda, but something is wrong in "display code".

Also, I've never seen this bug (snd_hda hang during suspend) on 4.19-rc (where monitor switching to standby doesn't kill amdgpu driver anymore). And currently I can't reproduce it even on 4.18.5