Bug 109509 - Loss of i915 (Gemini Lake) HDMI audio after turning off and on AVR
Summary: Loss of i915 (Gemini Lake) HDMI audio after turning off and on AVR
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: Triaged, ReadyForDev
Depends on:
Reported: 2019-01-30 20:36 UTC by memphiz
Modified: 2019-11-29 18:06 UTC (History)
3 users (show)

See Also:
i915 platform: GLK
i915 features: display/audio

no audio after avr power on (3.85 MB, text/x-log)
2019-02-03 19:03 UTC, memphiz
no flags Details

Description memphiz 2019-01-30 20:36:29 UTC
Basically my issue reads very very similar to the one from bug id 104952.

I am running Ubuntu 18.04.1 LTS on an Gigabyte Prix GB-BLPD-5005 (Intel Pentium J5005 Gemini Lake). Running mainline kernel:

Linux brix 4.20.5-042005-generic #201901260434 SMP Sat Jan 26 09:36:17 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I have attached a Yamaha AVR via HDMI and after that a Samsung TV:

Whenever I switch off the AVR and turn it back on after some longer time (> 60 seconds or a couple of minutes - not tested that much yet) - I loos HDMI audio and have the following messages in dmesg:

[52092.976001] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100
[52093.983688] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100
[52094.988008] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100
[52095.272444] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5

For getting HDMI audio restored I need to shutdown X and unload/reload snd-hda-intel.

Please advice what kind of debug logs are needed for investigation and I will happily provide them.
Comment 1 Lakshmi 2019-01-31 09:30:20 UTC
Can you try to reproduce the issue using latest drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 2 memphiz 2019-01-31 20:12:50 UTC
I tried drm-tip from here:


hope this is the right place.

Linux brix 5.0.0-994-generic #201901310201 SMP Thu Jan 31 02:03:36 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Seems the issue is not happening with that version. At least I was not able to reproduce it now. So very nice :)

Question is how this drm state will hit a stable mainline kernel? Will it be automagically in Kernel 5.0? Or does it make sense (or is it even possible) to apply drm-tip to my former used 4.20.5 kernel by self compiling?
Comment 3 memphiz 2019-02-02 19:10:43 UTC
I spoke to soon. Had the issue again. I will switch on debugging again and will post a log once I can reproduce again.
Comment 4 memphiz 2019-02-03 19:03:59 UTC
Created attachment 143281 [details]
no audio after avr power on

Here you go. Was able to reproduce it. Hope the dmesg shows something useful. Let me know what else you need from me.
Comment 5 Danijel 2019-04-10 08:11:21 UTC
Hi, I had the exact same problem (J5005 NUC) and I _think_ I fixed it by accident just the other day by swapping HDMI cables. It has not happened for two days so far, so fingers crossed. It it happens again, I will try to recreate the issue with drm-tip.

Otherwise the procedure to get it up and running was the same as you describe,  
- shutdown xorg
- unload module
- load module
- restart xorg

No idea on why the HDMI cable would be an issue though. 

My setup is kinda similar to yours:

NUC --> HDMI splitter (4 inputs, 1 output) -+---> HDMI Projector
                                            +---> S/PDIF Speakers
Comment 6 Lakshmi 2019-07-13 17:29:01 UTC
Contacted audio team to respond on this issue. If there is any feedback from the audio team I will post the details here.
Comment 7 Amadeusz Sławiński 2019-07-15 10:39:42 UTC
Can you try with latest upstream kernel, 5.2 or git?
Comment 8 Lakshmi 2019-08-23 07:15:36 UTC
Reporter, as Amadeusz requested, can you please verify the issue with drmtip? (https://cgit.freedesktop.org/drm-tip)

Please attach dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M if the problem persists.
Comment 9 Jani Saarinen 2019-11-14 07:58:18 UTC
Reporter, have you been able to test issue on latest drm-tip, if no response we are going to close as works for me.
Comment 10 Martin Peres 2019-11-29 18:06:19 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/222.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.