Bug 109509

Summary: Loss of i915 (Gemini Lake) HDMI audio after turning off and on AVR
Product: DRI Reporter: memphiz
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: NEEDINFO --- QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: amadeuszx.slawinski, filip.kaczmarski, intel-gfx-bugs
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: Triaged, ReadyForDev
i915 platform: GLK i915 features: display/audio
Description Flags
no audio after avr power on none

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.

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.