I was using some script to unbind the Thunderbolt controllers from their hardware on suspend, which appears to have indirectly confused the audio drivers.

IOW, nothing to see here as far as I can tell. Sorry for the noise!

Context:

- https://gitlab.com/emrose/xps13-7390_debian/issues/1
- https://gitlab.com/emrose/xps13-7390_debian/issues/2

A BIOS upgrade and the removal of the Thunderbolt suspend fix have lessened the incidence of this issue, but the program hangs in conjunction with

[ 1673.440034] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x202f8100
[ 1674.448043] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x202f8100
[ 1675.456078] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x202f8100
[ 1676.468278] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x202f8100

in dmesg do still occur, often in conjunction with plugging in and/or removing external monitors from the Thunderbolt ports of the machine.

I'd be grateful for any advice in tracking down what the problem might be. In particular, I'm happy to run patched kernels if that helps.

Thanks in advance!

I have the same issue.

hardware: xps 13 7390 2-in-1
bios version: 1.0.13
kernel: 5.4-rc5

Created attachment 285743 [details]
Call traces during suspend

I've attached call traces from dmesg during suspend which causes suspend exit.

There is a known mutex deadlock up to 5.4-rc5.  The fix is already in Linus tree and will be in rc6.

This won't fix the codec communication error the original reports suggests, but the hang up can be addressed by that.

And the codec communication error is likely caused by other component like GPU or Thunderbolt side, not in the audio side.  It's a pseudo device on GPU, after all.

After attaching this stack trace, I've found out that there is a fix for this. I'll check in a moment if it will fix suspend issue.

Regards to communication error, will try to do some more investigation. Thanks for notice.

> This won't fix the codec communication error the original reports suggests,
> but the hang up can be addressed by that.

I'm on 5.4-rc6 now, and I still have the issue as originally described. I wasn't able to observe any change in behavior from 5.4-rc5 to 5.4-rc6.

Just as I said that, something did happen: The process responded to being killed, and this showed up in the kernel log:

Nov 04 17:22:12 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20bf0015
Nov 04 17:22:13 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20bf0015
Nov 04 17:22:14 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20b3b000
Nov 04 17:22:15 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20b70740
Nov 04 17:22:16 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20278103
Nov 04 17:22:16 lightning kernel: snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11
Nov 04 17:22:17 lightning kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20af0015
Nov 04 17:22:18 lightning kernel: ------------[ cut here ]------------
Nov 04 17:22:18 lightning kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20170503
Nov 04 17:22:18 lightning kernel: WARNING: CPU: 6 PID: 77517 at sound/pci/hda/hda_controller.c:887 azx_rirb_get_response+0x21e/0x2c0 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel: Modules linked in: uinput(E) fuse(E) ax88179_178a(E) usbnet(E) mii(E) cmac(E) rfcomm(E) typec_displayport(E) uvcvideo(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_common(E) snd_usb_audio(E) snd_usbmidi_lib(E) videodev(E) snd_rawmidi(E) t>
Nov 04 17:22:18 lightning kernel:  hid_sensor_als(E) hid_sensor_accel_3d(E) hid_sensor_magn_3d(E) hid_sensor_incl_3d(E) hid_sensor_rotation(E) hid_sensor_gyro_3d(E) hid_sensor_trigger(E) snd_pcm(E) hid_sensor_iio_common(E) tpm_tis(E) intel_cstate(E) industrialio_triggered_buffer(E) ucsi_acpi(E) pr>
Nov 04 17:22:18 lightning kernel:  crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) hid_logitech_hidpp(E) hid_logitech_dj(E) dm_crypt(E) dm_mod(E) wacom(E) usbhid(E) mmc_block(E) hid_sensor_custom(E) hid_sensor_hub(E) hid_generic(E) intel_ishtp_hid(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(>
Nov 04 17:22:18 lightning kernel: CPU: 6 PID: 77517 Comm: xournalpp Tainted: G           OE     5.4.0-rc6 #1
Nov 04 17:22:18 lightning kernel: Hardware name: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.0.13 09/17/2019
Nov 04 17:22:18 lightning kernel: RIP: 0010:azx_rirb_get_response+0x21e/0x2c0 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel: Code: 45 8b ae d8 03 00 00 4c 8b 67 50 4d 85 e4 74 3d e8 67 e2 93 e4 44 89 e9 4c 89 e2 48 c7 c7 90 34 63 c1 48 89 c6 e8 e0 c2 45 e4 <0f> 0b 80 8d 04 06 00 00 04 48 89 ef 80 a5 50 05 00 00 f7 e8 fa 01
Nov 04 17:22:18 lightning kernel: RSP: 0018:ffffbfe5c3e87850 EFLAGS: 00010282
Nov 04 17:22:18 lightning kernel: RAX: 0000000000000000 RBX: 0000000000000c05 RCX: 0000000000000006
Nov 04 17:22:18 lightning kernel: RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffffa0eeaf597680
Nov 04 17:22:18 lightning kernel: RBP: ffffa0ee9e553000 R08: 0000000000000797 R09: 0000000000000004
Nov 04 17:22:18 lightning kernel: R10: 0000000000000000 R11: 0000000000000001 R12: ffffa0eeaaf67590
Nov 04 17:22:18 lightning kernel: R13: 0000000020170503 R14: ffffa0ee9e553008 R15: 0000000000000001
Nov 04 17:22:18 lightning kernel: FS:  00007f3fbec19ac0(0000) GS:ffffa0eeaf580000(0000) knlGS:0000000000000000
Nov 04 17:22:18 lightning kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 04 17:22:18 lightning kernel: CR2: 00007fc910609000 CR3: 00000006738b2006 CR4: 0000000000760ee0
Nov 04 17:22:18 lightning kernel: PKRU: 55555554
Nov 04 17:22:18 lightning kernel: Call Trace:
Nov 04 17:22:18 lightning kernel:  snd_hdac_bus_exec_verb_unlocked+0x9c/0x180 [snd_hda_core]
Nov 04 17:22:18 lightning kernel:  codec_exec_verb+0x72/0x110 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  codec_read+0x41/0x70 [snd_hda_core]
Nov 04 17:22:18 lightning kernel:  haswell_set_power_state+0x2d/0x50 [snd_hda_codec_hdmi]
Nov 04 17:22:18 lightning kernel:  hda_set_power_state+0x49/0x100 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  hda_call_codec_suspend+0x6f/0xa0 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  snd_hda_bus_reset_codecs+0x25/0x70 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  snd_hda_bus_reset+0x3c/0x50 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  codec_exec_verb+0xb7/0x110 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  hda_reg_read+0x1ad/0x240 [snd_hda_core]
Nov 04 17:22:18 lightning kernel:  __snd_hdac_regmap_read_raw+0x61/0xb0 [snd_hda_core]
Nov 04 17:22:18 lightning kernel:  snd_hdac_read_parm_uncached+0x2e/0x60 [snd_hda_core]
Nov 04 17:22:18 lightning kernel:  ? rpm_idle+0x20/0x2f0
Nov 04 17:22:18 lightning kernel:  snd_hda_get_num_devices+0x69/0x80 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  intel_not_share_assigned_cvt+0x85/0x150 [snd_hda_codec_hdmi]
Nov 04 17:22:18 lightning kernel:  hdmi_pcm_open+0x303/0x390 [snd_hda_codec_hdmi]
Nov 04 17:22:18 lightning kernel:  azx_pcm_open+0x211/0x370 [snd_hda_codec]
Nov 04 17:22:18 lightning kernel:  snd_pcm_open_substream+0x7f/0x140 [snd_pcm]
Nov 04 17:22:18 lightning kernel:  snd_pcm_open+0xf0/0x240 [snd_pcm]
Nov 04 17:22:18 lightning kernel:  ? dput+0xb6/0x2d0
Nov 04 17:22:18 lightning kernel:  ? wake_up_q+0x60/0x60
Nov 04 17:22:18 lightning kernel:  snd_pcm_playback_open+0x3d/0x60 [snd_pcm]
Nov 04 17:22:18 lightning kernel:  chrdev_open+0xcb/0x1e0
Nov 04 17:22:18 lightning kernel:  ? cdev_default_release+0x20/0x20
Nov 04 17:22:18 lightning kernel:  do_dentry_open+0x13a/0x380
Nov 04 17:22:18 lightning kernel:  path_openat+0x58e/0x1600
Nov 04 17:22:18 lightning kernel:  do_filp_open+0x91/0x100
Nov 04 17:22:18 lightning kernel:  ? __check_object_size+0x136/0x147
Nov 04 17:22:18 lightning kernel:  do_sys_open+0x184/0x220
Nov 04 17:22:18 lightning kernel:  do_syscall_64+0x52/0x160
Nov 04 17:22:18 lightning kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Nov 04 17:22:18 lightning kernel: RIP: 0033:0x7f3fc3a0b655
Nov 04 17:22:18 lightning kernel: Code: 8b 00 85 c0 74 95 44 89 54 24 0c e8 55 bf 01 00 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 89 44 24 0c e8 87 bf 01 00 8b 44
Nov 04 17:22:18 lightning kernel: RSP: 002b:00007fff6372f670 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
Nov 04 17:22:18 lightning kernel: RAX: ffffffffffffffda RBX: 0000000000080802 RCX: 00007f3fc3a0b655
Nov 04 17:22:18 lightning kernel: RDX: 0000000000080802 RSI: 00007fff6372f830 RDI: 00000000ffffff9c
Nov 04 17:22:18 lightning kernel: RBP: 00007fff6372f830 R08: 0000000000000000 R09: 0000000000000011
Nov 04 17:22:18 lightning kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000080802
Nov 04 17:22:18 lightning kernel: R13: 0000000000000004 R14: 0000000000000000 R15: 00007fff6372f830
Nov 04 17:22:18 lightning kernel: ---[ end trace e1f9a0df878fc560 ]---
Nov 04 17:22:18 lightning kernel: snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -5

A few more details:

- There is a Debian code signing issue flying around, where the issue appears to be related to not being able to even load snd-hda-intel. (IMO) that's distinct from the current issue.

- For me, a semi-reliable way of triggering the issue is to plug in and un-plug an external monitor (DisplayPort) monitor into either USB-C jack on the machine that advertises HDMI audio support.

- I suspect that "options snd_hda_intel probe_mask=1" will prevent snd-hda-intel from enumerating the HDMI codec and thus perhaps sidestep the issue for now. No HDMI audio is more livable for me than random hangs and suspend failures...

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881

I made a few patches to i915 driver that are worth trying. They don't seem to be in v5.4-rc6 yet.

Please see:
- https://patchwork.freedesktop.org/series/67460/
- and full history in: https://bugs.freedesktop.org/show_bug.cgi?id=111214

I built a kernel based on drm-tip (41eb27f39e60d822edc75e6aaeb416b72bc1dcf2), which appears to contain the patches in question. In a quick experiment (plugging in and unplugging a bunch of displays), I wasn't able to reproduce the issue. Let's call this fixed, and I'll reopen in case the issue recurs.

Thanks for your work on the patch, and for pointing me towards it!

Excellent, thanks Andreas for testing! The patch is indeed already merged to drm tree.

I've just installed OpenSuse Tumbleweed(kernel: 5.6.4-1-default) on an ODYSSEY – X86J4105800 and I can see the error coming up continuosly in dmesg: 

[   20.961010] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100
[   21.973027] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100
[   22.981035] snd_hda_intel 0000:00:0e.0: No response from codec, resetting bus: last cmd=0x20bf8100


Shouldn't this issue been fixed ? 

I can't use HDMI audio at all, only way to avoid error is: options snd_hda_intel probe_mask=1 , but I would need to use my HDMI audio ...

(In reply to Alessio Pollero from comment #13)
> I've just installed OpenSuse Tumbleweed(kernel: 5.6.4-1-default) on an
> ODYSSEY – X86J4105800 and I can see the error coming up continuosly in
> dmesg: 

This has J4105 (Geminilake) CPU, so it is slightly different hardware generation than the original bug report (Icelake), so this may be a different issue although the messages are similar. 

You could try this patch that was recently merged to DRM-Intel tree:
"drm/i915: do AUD_FREQ_CNTRL state save on all gen9+ platforms"

Depending on system firmware settings, this may have an impact to enabling the HDA link between graphics and audio controller on your system.

I just very recently got the patch through reviews, so it is not yet in 5.7rc2 even.

I have an Ice Lake laptop (Dell 7390 2-in-one) which I am connecting to a TV over HDMI via a Novoo USB-C multiport adapter. This is not a Thunderbolt device, it is just USB-C.

It seemed like things used to work fine before I upgraded this system from Ubuntu 19.10 to 20.04, although I couldn't say for certain at this point. But I'm having a ton of difficulty getting audio output over HDMI. Getting it to work requires a lot of random plugging and unplugging of cables, and repeatedly messing around in the system settings to change output devices and volume levels. It does work sometimes, but my success rate is very low at this point.

For example, just now as I wrote this, I was briefly successful, but then I changed the output setting from 7.1 channel to 5.1, and it stopped again (without plugging or unplugging any cables or changing any video settings in the interim.)

The patch posted above by Kai Vehmanen is not relevant because this system is Ice Lake and the patch only enables logic for non-ICL, post gen9 platforms.

I'm also still seeing the same behavior (at least, it seems like the same behavior), on Dell 7390 2-in-1 running Manjaro.

$ uname -r
5.6.11-1-MANJARO

I have the issue of applications hanging in an unkillable state maybe 1 in 5 boots, making me force a shutdown and reboot until it works. (This is even without connecting any external displays etc!). Also, I don't have any HDMI audio out ever.

Greg, that's interesting. I do get HDMI audio if I fiddle enough (repeatedly suspending and resuming helps to eventually force it to initialize properly), it's just that there are intermittent problems with it. Sometimes I've found that the volume needs to be reset after changing output configuration, but that's not usually the problem.

Are you using the *XPS* 7390 2-in-1 or the *Latitude* 7390 2-in-1? Mine is the XPS.

Huh. I also have the XPS. By the way, I just checked and I'm running BIOS revision 1.3.1 (which is up-to-date according to the windows updater, at least).

I have tried a few times to fiddle, suspend and wake again, etc. to try to get things working, but never had any luck. Maybe I just didn't try hard enough!

I also have an issue when I do have an external display connected where often times after suspend the external display doesn't come back when I resume. not sure if it's related though.

Filed my issue at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1879401

I am suffering from exactly the same issue. 
It happens once every couple of boots and also after waking up from suspend, possibly also after waking up from hibernation to disk.

It's XPS 9300 laptop with i7-1065g7 CPU.

There is a partial workaround that I am using: 


# echo 1 > '/sys/bus/pci/devices/0000:00:1f.3/remove'
# sleep 1
# echo 1 > /sys/bus/pci/rescan

Sometimes I need to do it once, sometimes even 3 or more times. 

After that reloading pulseaudio is also needed 

$ pulseaudio -k

The dmesg output after successful attempts:

[  732.674997] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20bf0015
[  733.684996] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20bf0015
[  734.688317] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20b3b000
[  735.694968] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20b70740
[  736.704998] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20278103
[  736.705002] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11
[  737.708707] pci 0000:00:1f.3: [8086:34c8] type 00 class 0x040380
[  737.708797] pci 0000:00:1f.3: reg 0x10: [mem 0x4010004000-0x4010007fff 64bit]
[  737.708886] pci 0000:00:1f.3: reg 0x20: [mem 0x4010100000-0x40101fffff 64bit]
[  737.709083] pci 0000:00:1f.3: PME# supported from D3hot D3cold
[  743.668689] pci 0000:00:1f.3: BAR 4: assigned [mem 0x4010100000-0x40101fffff 64bit]
[  743.668730] pci 0000:00:1f.3: BAR 0: assigned [mem 0x4010004000-0x4010007fff 64bit]
[  743.668911] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[  743.669483] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])


[  743.687131] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC289: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[  743.687133] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[  743.687133] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[  743.687134] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[  743.687134] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[  743.687135] snd_hda_codec_realtek hdaudioC0D0:      Headset Mic=0x19
[  743.687136] snd_hda_codec_realtek hdaudioC0D0:      Headphone Mic=0x1b
[  743.687136] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x12
[  743.747233] input: HDA Intel PCH Headphone Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input40
[  743.747264] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input41
[  743.747299] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input42
[  743.747325] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input43
[  743.747373] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input44
[  743.747402] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input45
[  743.747424] input: HDA Intel PCH HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input46
[  743.747459] input: HDA Intel PCH HDMI/DP,pcm=12 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input47



I am on:  5.6.16-1-MANJARO

I've seen this once every week or two:

$ journalctl | grep 'No response from codec' | cut -f1,2 -d' ' | sort -u
Apr 07
Feb 12
Feb 14
Feb 15
Feb 18
Feb 21
Jun 02
Jun 12
Jun 22
Mar 08
Mar 13
Mar 19
Mar 26
May 25

Most of the time I don't see this, but I may have other audio problems (silent output noted above).

The only time I really noticed a problem and saw this message was the day before yesterday. When this happens, the whole system seems to slow down and wait for these retries, so I rebooted to fix it. I have been running various kernel versions, ranging from Ubuntu's 5.3, 5.4 and 5.6-oem trees to mainline 5.6. I'm not running mainline anymore because Ubuntu's tree is working better in general these days, so most recently I am on Ubuntu 5.4 as 5.6 is EOL upstream.

Nathan, Mateusz, Greg and others, if possible, you could give a try for this patch (in 5.8-rc2):

commit 1c664c15cf0a31784b217a84fa0128ce46f17a84
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Tue Mar 24 17:32:12 2020 +0200

    drm/i915: use forced codec wake on all gen9+ platforms


.. we are not seeing this error in SOF audio and Intel GFX CI systems. These both have had the above patch for many months, so that could possible explain. The above patch specifically affects platforms with gen10 display, so Icelake and Geminilake, so matches with the observations in this bug.

Kai, could you submit the commit to stable kernels?  Just tell Greg the commit id to cherry-pick.

Takashi, ack, I'll do that. I'm a bit surprised this didn't get cc'ed to stable by DRM maintainers (it was merged to DRM ages ago), nor picked up by Sasha's stable scripts. For sound subsystem patches, all of my patches with a bug link have been automatically picked up.

All right, I'll track 5.8-rcX for a while and see where we end up.

OK, right out of the gate with 5.8-rc2, there are still some negotiation issues with my Type-C multiport adapter, including the silent audio output I referenced in Comments 15 and 19, and, a lot of these, requiring a couple of hotplug retries to get them to go away:

[Jun24 16:05] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?

So far, no recurrence of the "No response from codec" issue, but I've only been testing for about 5 minutes and this issue happens just a handful of times per month.

Still seeing this on 5.8-rc2:

$ journalctl | egrep 'No response from codec|Linux version'
...
Jun 24 15:57:47 atlantis kernel: Linux version 5.8.0-050800-generic (kernel@kathleen) (gcc (Ubuntu 9.3.0-13ubuntu1) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #202006212330 SMP Sun Jun 21 23:35:17 UTC 2020
Jun 24 15:57:52 atlantis kernel: snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x021707c0
Jun 24 15:57:53 atlantis kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x021707c0

I don't know if this is relevant, but the above was preceded by this:

Jun 24 15:57:51 atlantis kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x021707c0

Thanks Nathan for testing! This indeed looks like a new case. Could you try the following experiment(this will increase power consumption, so to try rootcausing the issue). Put following in a .conf file in /etc/modprobe.d/ 

i915.disable_power_well=0 

If that doesn't help, next step would be to revert this patch from 5.8-rc2:

commit f4b18892dca8 drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

Jaroslav, should we reopen or file a new ticket for this? There was one bug that was fixed and verified (in Nov/2019), but now we have a new issue. Problem looks to the same, communication fails with display hw and audio probe fails.

Hi Kai,

I added i915.disable_power_well=0 to the kernel commandline in /etc/default/grub and rebooted into 5.8-rc2. I have graphical boot disabled and noticed this scroll by immediately on boot (HDMI was already plugged in)

[    6.334002] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x02336080
[    7.337894] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x02336080
[    8.341914] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x02336080

For completeness I'll note my full cmdline:

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-5.8.0-050800-generic root=UUID=caffa21a-82f2-4555-a416-67926241525a ro cma=128M pcie_aspm.policy=powersupersave drm.vblankoffdelay=1 video=1600x1200 mem_sleep_default=deep i915.disable_power_well=0

Speaking of power management: in the past, I've indeed noticed that ASPM seems related to some of these Type-C issues; sometimes, on some kernel versions, it's seemed that setting the ASPM policy to "performance" helps reduce the frequency of (but not entirely eliminate) silent output issues. (Also prevents the package from going deeper than C3 state according to powertop.)

I've built a kernel with f4b18892dca8 reverted.

So far so good on the "No response from codec" message. Still some intermittent issues with silent audio. Will run this for a few weeks and see if "No response from codec" comes back.

I'm still testing with f4b18892dca8 reverted, now based on 5.8-rc4. Something new happened. I saw the message "usb usb2-port3: Cannot enable. Maybe the USB cable is bad?" while booting (it was still on the console, but just moments away from initialiaing X), so I unplugged and replugged the USB-C multiport hub that I use for HDMI connectivity. (If I don't do that, I tend to get spammed with these messages for hours.)

The result was this:

[  +1.466435] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  +4.216123] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  +4.216168] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  +4.396011] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  +4.071978] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  +0.135820] usb 3-9: USB disconnect, device number 2
[  +6.735991] usb 3-9: new high-speed USB device number 4 using xhci_hcd
[  +0.107961] usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  +0.022402] usb 2-3: New USB device found, idVendor=2109, idProduct=0817, bcdDevice= 3.b4
[  +0.000003] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 2-3: Product: USB3.0 Hub
[  +0.000001] usb 2-3: Manufacturer: VIA Labs, Inc.
[  +0.002024] hub 2-3:1.0: USB hub found
[  +0.000527] hub 2-3:1.0: 4 ports detected
[  +0.020860] usb 3-9: New USB device found, idVendor=2109, idProduct=2817, bcdDevice= 3.b4
[  +0.000002] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000001] usb 3-9: Product: USB2.0 Hub
[  +0.000000] usb 3-9: Manufacturer: VIA Labs, Inc.
[  +0.001172] hub 3-9:1.0: USB hub found
[  +0.000254] hub 3-9:1.0: 4 ports detected
[Jul 7 08:33] rfkill: input handler disabled
[  +0.622063] ------------[ cut here ]------------
[  +0.000006] WARNING: CPU: 6 PID: 1100 at sound/pci/hda/patch_hdmi.c:1851 check_non_pcm_per_cvt+0x4f/0x70 [snd_hda_codec_hdmi]
[  +0.000001] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc msr ccm typec_displayport snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic cmac overlay algif_hash algif_skcipher af_alg bnep snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core x86_pkg_temp_thermal snd_compress intel_powerclamp ac97_bus snd_pcm_dmaengine coretemp snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm dell_laptop intel_rapl_msr snd_seq_midi kvm_intel kvm joydev snd_seq_midi_event ledtrig_audio mei_hdcp crct10dif_pclmul iwlmvm mousedev dell_smm_hwmon ghash_clmulni_intel dell_wmi snd_rawmidi nls_iso8859_1 mac80211 aesni_intel crypto_simd cryptd
[  +0.000017]  dell_smbios libarc4 glue_helper btusb snd_seq dcdbas btrtl btbcm rapl btintel iwlwifi intel_cstate bluetooth input_leds snd_seq_device i915 serio_raw efi_pstore snd_timer dell_wmi_descriptor intel_wmi_thunderbolt ecdh_generic ecc wmi_bmof drm_kms_helper snd hid_sensor_rotation hid_sensor_incl_3d ucsi_acpi hid_sensor_magn_3d soundcore mei_me hid_sensor_als hid_sensor_gyro_3d hid_sensor_accel_3d cec hid_sensor_trigger typec_ucsi industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common typec rc_core industrialio i2c_algo_bit cfg80211 hid_multitouch fb_sys_fops processor_thermal_device syscopyarea intel_rapl_common cros_ec_ishtp intel_soc_dts_iosf sysfillrect cros_ec sysimgblt mei mac_hid acpi_tad soc_button_array int3403_thermal acpi_pad intel_hid int340x_thermal_zone int3400_thermal acpi_thermal_rel sparse_keymap sch_fq_codel parport_pc ppdev lp parport drm ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub hid_generic intel_ishtp_loader intel_ishtp_hid
[  +0.000021]  i2c_designware_platform i2c_designware_core nvme crc32_pclmul psmouse intel_lpss_pci nvme_core intel_lpss i2c_i801 intel_ish_ipc idma64 xhci_pci virt_dma i2c_smbus intel_ishtp xhci_pci_renesas i2c_hid wmi hid video backlight pinctrl_icelake pinctrl_intel
[  +0.000008] CPU: 6 PID: 1100 Comm: gnome-shell Not tainted 5.8.0-050800-generic #202007052030
[  +0.000001] Hardware name: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.4.0 05/11/2020
[  +0.000001] RIP: 0010:check_non_pcm_per_cvt+0x4f/0x70 [snd_hda_codec_hdmi]
[  +0.000002] Code: 4c 89 e7 e8 e3 22 f9 ff 48 85 c0 74 1d 44 8b 60 04 4c 89 ef e8 02 b7 16 ee 5b 41 d1 ec 41 83 e4 01 44 89 e0 41 5c 41 5d 5d c3 <0f> 0b 41 bc 01 00 00 00 4c 89 ef e8 e1 b6 16 ee 44 89 e0 5b 41 5c
[  +0.000000] RSP: 0018:ffffb28a80d77820 EFLAGS: 00010246
[  +0.000001] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[  +0.000000] RDX: 0000000000000007 RSI: 0000000000000000 RDI: ffff938cac2e5000
[  +0.000000] RBP: ffffb28a80d77838 R08: ffff938cac396300 R09: 0000000000000000
[  +0.000001] R10: ffffffffafc6a380 R11: ffff938cac396000 R12: ffff938cac2e5000
[  +0.000000] R13: ffff938cac2e54c0 R14: ffffffffffffffff R15: 0000000000000000
[  +0.000001] FS:  00007f69321f1cc0(0000) GS:ffff938ccf580000(0000) knlGS:0000000000000000
[  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000001] CR2: 00007fca2ff8e008 CR3: 0000000448d78001 CR4: 0000000000760ee0
[  +0.000000] PKRU: 55555554
[  +0.000001] Call Trace:
[  +0.000003]  update_eld+0x314/0x750 [snd_hda_codec_hdmi]
[  +0.000002]  hdmi_present_sense+0x17b/0x1f0 [snd_hda_codec_hdmi]
[  +0.000001]  check_presence_and_report+0x88/0xa0 [snd_hda_codec_hdmi]
[  +0.000001]  intel_pin_eld_notify+0x58/0x60 [snd_hda_codec_hdmi]
[  +0.000029]  intel_audio_codec_enable+0x129/0x1a0 [i915]
[  +0.000021]  intel_enable_ddi+0x408/0x530 [i915]
[  +0.000012]  ? gen11_fwtable_write32+0xe8/0x220 [i915]
[  +0.000018]  intel_encoders_enable+0x88/0xb0 [i915]
[  +0.000017]  hsw_crtc_enable+0x1d4/0x590 [i915]
[  +0.000015]  intel_enable_crtc+0x52/0x70 [i915]
[  +0.000015]  skl_commit_modeset_enables+0x33c/0x530 [i915]
[  +0.000015]  intel_atomic_commit_tail+0x315/0xde0 [i915]
[  +0.000002]  ? flush_workqueue+0x196/0x430
[  +0.000014]  intel_atomic_commit+0x2a4/0x320 [i915]
[  +0.000013]  drm_atomic_commit+0x4a/0x50 [drm]
[  +0.000007]  drm_atomic_helper_set_config+0x7c/0xc0 [drm_kms_helper]
[  +0.000006]  drm_mode_setcrtc+0x1fb/0x790 [drm]
[  +0.000003]  ? sched_clock+0x9/0x10
[  +0.000006]  ? drm_mode_getcrtc+0x190/0x190 [drm]
[  +0.000005]  drm_ioctl_kernel+0xae/0xf0 [drm]
[  +0.000002]  ? psi_group_change+0x46/0x230
[  +0.000006]  drm_ioctl+0x234/0x3d0 [drm]
[  +0.000006]  ? drm_mode_getcrtc+0x190/0x190 [drm]
[  +0.000002]  ksys_ioctl+0x9d/0xd0
[  +0.000001]  __x64_sys_ioctl+0x1a/0x20
[  +0.000003]  do_syscall_64+0x49/0xc0
[  +0.000001]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  +0.000001] RIP: 0033:0x7f693764137b
[  +0.000001] Code: Bad RIP value.
[  +0.000000] RSP: 002b:00007ffe3ce93768 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  +0.000001] RAX: ffffffffffffffda RBX: 00007ffe3ce937a0 RCX: 00007f693764137b
[  +0.000000] RDX: 00007ffe3ce937a0 RSI: 00000000c06864a2 RDI: 0000000000000009
[  +0.000001] RBP: 00000000c06864a2 R08: 0000000000000000 R09: 000055f51e68ce20
[  +0.000000] R10: 0000000000000000 R11: 0000000000000246 R12: 000055f51e68cda0
[  +0.000000] R13: 0000000000000009 R14: 0000000000000009 R15: 000055f51e67f930
[  +0.000002] ---[ end trace c73c2ddbf5870dd1 ]---

For me, adding 'options snd_hda_intel power_save=0
' in '/etc/modprobe.d/audio_powersave.conf' fixed this issue.

Hi Kai,

It appears that the issue still occurs even with f4b18892dca8 reverted:

$ journalctl | egrep -i 'linux version|snd_hda_intel'
...
Jul 10 10:31:59 atlantis kernel: Linux version 5.8.0-050800-generic (nbryant@atlantis) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #202007052030 SMP Mon Jul 6 12:46:52 EDT 2020
Jul 10 10:31:59 atlantis kernel: snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
Jul 10 10:31:59 atlantis kernel: snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
Jul 10 10:32:00 atlantis kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Jul 10 10:32:03 atlantis kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x0083603f
Jul 10 10:32:04 atlantis kernel: snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x0083603f
Jul 10 10:32:05 atlantis kernel: snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x0083603f

Moreover (as I suspect you are already aware), reverting f4b18892dca8 causes bad flicker when not on HDMI, any time snd_hda_intel wakes up from sleep.

Thanks Nathan. There are now two possible sources of the problem:
 1. clocking issue when display clock (CDCLK) goes to its lowest setting
 2. hda controller issues when resuming from suspend

Reverting f4b18892dca8 indeed causes flicker as the CDCLK is ramped up higher whenever audio is used. I asked for the test, because if the errors would have disappeared, then a possible usable fix would be to bump the minimum CDCLK (in i915 driver) for your configuration. But it didn't help, so it is likely not this.

For the second issue type, it's unclear to me now why this impacts specifically the HDMI codec (and the Realtek codec probe does not fail). But it's definitely interesting that both "ItsMe" above, and reporter of https://bugzilla.kernel.org/show_bug.cgi?id=208511 , have given feedback that snd_hda_intel power_save=0 helps for a HDMI probe error (not exactly the same hw, but GLK and ICL are close enough to make this worth cross-checking). Does this help Nathan for you?

I'll keep looking for an occurrence of this case in our internal test benches.

This kernel message appears to manifest in two different ways:

(1) just the two messages, just one time, and then it stops, and I'm unclear whether it's connected to a user-visible functional issue.
(2) repeatedly in a loop, causing quite a bit of log spam and user-visible system sluggishness.

Case (1) happens with some regularity with many different kernel versions but I'm not sure if there's a real problem beyond the kernel message. I usually just find these after-the-fact, in the system logs.

Case (2) has happened to me a few times, but from my logs, the most recent times were Jun 22 (version_signature Ubuntu 5.4.0-38.42-generic 5.4.44) and Jun 24 (Ubuntu 5.6.0-1013.13-oem 5.6.14)

So there might be a couple slightly different issues, one of which has not recurred recently and in either case I couldn't even say with certainty that this is coming from the HDMI codec. The kernel logs don't look that specific to my eyes. So this may not be the highest-priority bug in the world, either, but  I will try with power_save=0 for a while and see what happens.

I guess it *is* HDMI. I'm also seeing this mixed in:

[  209.274407] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11

(In reply to ItsMe from comment #33)
> For me, adding 'options snd_hda_intel power_save=0
> ' in '/etc/modprobe.d/audio_powersave.conf' fixed this issue.

Unfortunately I am still seeing the same issue with this option set. :/

Confirmed this bug is still prevalent:
.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


Only solution I have found is to repeatedly hard power-off the laptop and turn it back on continuously until the error no longer appears. Unfortunately this corrupted the linux install for obvious reasons so I had to completely wipe the drive and revert to Windows. I have 0 interest in reinstalling Linux, just thought I would post this to inform the kernel team there are still major issues with the snd_hda_intel. Either fix it or drop Intel sound support. Buggy code like this should not be in the kernel tree.