Bug 205229 - [Intel Ice Lake, snd-hda-intel, HDMI] "No response from codec" (after display hotplug?)
Summary: [Intel Ice Lake, snd-hda-intel, HDMI] "No response from codec" (after display...
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-17 18:34 UTC by Andreas Kloeckner
Modified: 2021-01-24 19:28 UTC (History)
10 users (show)

See Also:
Kernel Version: 5.4-rc5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Call traces during suspend (3.84 KB, text/plain)
2019-11-02 09:26 UTC, Arek Burdach
Details

Description Andreas Kloeckner 2019-10-17 18:34:17 UTC
I have brand-new Dell XPS 13 7390 2-in-1, based on Intel's 10th-generation hardware. I built kernel 5.4rc3 following instructions here [1]. After I put the machine to sleep (s2idle, not ACPI S3), and wake it up, any attempt to access /dev/snd/pcmC0D3p will hard-hang the associated process. In addition, any attempt to play sound after that point (on the built-in or the HDMI codecs) will hang for a while and then time out. Here's the strace of a process trying to access /dev/snd/pcmC0D3p:

ioctl(11, SNDRV_CTL_IOCTL_PVERSION, 0x7ffe01520b84) = 0
ioctl(11, SNDRV_CTL_IOCTL_PCM_PREFER_SUBDEVICE, 0x7ffe01520bec) = 0
openat(AT_FDCWD, "/dev/snd/pcmC0D3p", O_RDWR|O_NONBLOCK|O_CLOEXEC

After that, it just sits there and cannot be killed. /dev/snd/pcmC0D3p is an HDMI audio output as far as I can tell. I have an external screen with audio output attached most of the time, but the issue occurs even without any such hardware attached. In the "hang" situation, the following is shown in the kernel log:

[ 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

dmesg | grep snd
[ 1596.130902] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 1596.131110] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 1596.148212] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC289: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[ 1596.148214] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 1596.148215] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[ 1596.148215] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[ 1596.148216] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[ 1596.148217] snd_hda_codec_realtek hdaudioC0D0:      Headset Mic=0x19
[ 1596.148217] snd_hda_codec_realtek hdaudioC0D0:      Headphone Mic=0x1b
[ 1596.148218] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x12

[1] https://gitlab.com/emrose/xps13-7390_debian

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

$ lspci
00:00.0 Host bridge: Intel Corporation Device 8a12 (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Device 8a52 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Device 8a03 (rev 03)
00:05.0 Multimedia controller: Intel Corporation Device 8a19 (rev 03)
00:07.0 PCI bridge: Intel Corporation Device 8a1d (rev 03)
00:07.2 PCI bridge: Intel Corporation Device 8a21 (rev 03)
00:0d.0 USB controller: Intel Corporation Device 8a13 (rev 03)
00:0d.2 System peripheral: Intel Corporation Device 8a17 (rev 03)
00:0d.3 System peripheral: Intel Corporation Device 8a0d (rev 03)
00:12.0 Serial controller: Intel Corporation Device 34fc (rev 30)
00:14.0 USB controller: Intel Corporation Ice Lake-LP USB 3.1 xHCI Host Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Device 34ef (rev 30)
00:14.3 Network controller: Intel Corporation Device 34f0 (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #0 (rev 30)
00:15.1 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #1 (rev 30)
00:15.3 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #3 (rev 30)
00:16.0 Communication controller: Intel Corporation Device 34e0 (rev 30)
00:1d.0 PCI bridge: Intel Corporation Ice Lake-LP PCI Express Root Port #9 (rev 30)
00:1d.7 PCI bridge: Intel Corporation Device 34b7 (rev 30)
00:1f.0 ISA bridge: Intel Corporation Ice Lake-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Device 34c8 (rev 30)
00:1f.4 SMBus: Intel Corporation Ice Lake-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP SPI Controller (rev 30)
57:00.0 Non-Volatile memory controller: Device 1e0f:0001
58:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)
Comment 1 Andreas Kloeckner 2019-10-21 02:41:48 UTC
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
Comment 2 Andreas Kloeckner 2019-10-31 21:01:17 UTC
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!
Comment 3 Arek Burdach 2019-11-01 11:33:15 UTC
I have the same issue.

hardware: xps 13 7390 2-in-1
bios version: 1.0.13
kernel: 5.4-rc5
Comment 4 Arek Burdach 2019-11-02 09:26:36 UTC
Created attachment 285743 [details]
Call traces during suspend

I've attached call traces from dmesg during suspend which causes suspend exit.
Comment 5 Takashi Iwai 2019-11-02 10:08:43 UTC
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.
Comment 6 Arek Burdach 2019-11-02 10:18:18 UTC
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.
Comment 7 Andreas Kloeckner 2019-11-04 23:23:15 UTC
> 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.
Comment 8 Andreas Kloeckner 2019-11-04 23:26:29 UTC
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
Comment 9 Andreas Kloeckner 2019-11-04 23:50:24 UTC
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
Comment 10 Kai Vehmanen 2019-11-07 15:58:07 UTC
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
Comment 11 Andreas Kloeckner 2019-11-07 19:45:59 UTC
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!
Comment 12 Kai Vehmanen 2019-11-08 14:14:26 UTC
Excellent, thanks Andreas for testing! The patch is indeed already merged to drm tree.
Comment 13 Alessio Pollero 2020-04-21 13:50:54 UTC
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 ...
Comment 14 Kai Vehmanen 2020-04-21 16:34:47 UTC
(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.
Comment 15 Nathan Bryant 2020-05-01 20:42:02 UTC
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.
Comment 16 Greg Meyer 2020-05-18 17:55:28 UTC
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.
Comment 17 Nathan Bryant 2020-05-18 19:08:27 UTC
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.
Comment 18 Greg Meyer 2020-05-18 19:55:54 UTC
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.
Comment 19 Nathan Bryant 2020-05-18 21:49:08 UTC
Filed my issue at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1879401
Comment 20 Mateusz Tracz 2020-06-24 12:23:15 UTC
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
Comment 21 Nathan Bryant 2020-06-24 12:51:53 UTC
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.
Comment 22 Kai Vehmanen 2020-06-24 14:27:59 UTC
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.
Comment 23 Takashi Iwai 2020-06-24 14:55:46 UTC
Kai, could you submit the commit to stable kernels?  Just tell Greg the commit id to cherry-pick.
Comment 24 Kai Vehmanen 2020-06-24 18:34:00 UTC
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.
Comment 25 Nathan Bryant 2020-06-24 19:52:12 UTC
All right, I'll track 5.8-rcX for a while and see where we end up.
Comment 26 Nathan Bryant 2020-06-24 20:10:29 UTC
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.
Comment 27 Nathan Bryant 2020-06-29 02:11:21 UTC
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
Comment 28 Kai Vehmanen 2020-07-02 10:32:33 UTC
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.
Comment 29 Nathan Bryant 2020-07-03 14:40:30 UTC
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
Comment 30 Nathan Bryant 2020-07-03 14:46:07 UTC
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.)
Comment 31 Nathan Bryant 2020-07-03 19:08:23 UTC
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.
Comment 32 Nathan Bryant 2020-07-07 12:45:48 UTC
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 ]---
Comment 33 ItsMe 2020-07-08 01:21:19 UTC
For me, adding 'options snd_hda_intel power_save=0
' in '/etc/modprobe.d/audio_powersave.conf' fixed this issue.
Comment 34 Nathan Bryant 2020-07-12 15:09:32 UTC
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.
Comment 35 Kai Vehmanen 2020-07-15 13:54:48 UTC
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.
Comment 36 Nathan Bryant 2020-07-15 17:40:06 UTC
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.
Comment 37 Nathan Bryant 2020-07-16 15:28:58 UTC
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
Comment 38 Greg Meyer 2020-07-20 20:51:53 UTC
(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. :/
Comment 39 LordKow 2020-08-25 16:37:53 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.