<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104952">104952</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>XOrg git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>simon501098c@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=137170" name="attach_137170" title="Dmesg output from drm-tip (2e76a2952923eba64c4f9baf461613bc42ee997a) kernel booted with drm.debug=0x1e log_buf_len=1M">attachment 137170</a> <a href="attachment.cgi?id=137170&action=edit" title="Dmesg output from drm-tip (2e76a2952923eba64c4f9baf461613bc42ee997a) kernel booted with drm.debug=0x1e log_buf_len=1M">[details]</a></span>
Dmesg output from drm-tip (2e76a2952923eba64c4f9baf461613bc42ee997a) kernel
booted with drm.debug=0x1e log_buf_len=1M
Starting with kernel 4.14.0, when DPMS turns the screen off, there is about a
50% chance that HDMI audio will break. This can be fixed by shutting down Xorg,
removing and reloading module snd_hda_intel and then restarting Xorg.
When the loss occurs, the following appears in a non-debug demsg a few seconds
after the DPMS off command is issued.
snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling
mode: last cmd=0x208f8100
snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last
cmd=0x208f8100
snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd
mode: last cmd=0x208f8100
snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
Confirmed to happen in 4.14.0, 4.15.0 as well as the latest drm-tip (commit
2e76a2952923eba64c4f9baf461613bc42ee997a).
Using git bisect, it seems to have started with commit
e8a3a2a3d7f7a194e0f0ad92c5dd636f908e7601 "drm/i915/gen9+: Don't remove
secondary power well requests"
The previous commit 42d9366d41a992631abaa15f5a881ae1235a8203 does not exhibit
this issue.
I've booted the same HDD in a Haswell (i5-4570T) system and could not reproduce
the issue.
So far I only see this issue when running Xorg and Kodi (I don't have a regular
desktop on this system but can install one if requested for testing). I've
tried plain Xorg with no window manager, then starting either xterm or Google
Chrome and haven't managed to reproduce the issue in that situation.
Timing seems to have some effect; sleeping after 60 seconds (60 seconds from
Xorg starting, or 60 seconds from the last DPMS on command) never exhibited the
issue after several tries. 90 seconds or more seems to be needed.
In the attached dmesg output, the following was performed (Kodi & Xorg started
at boot, around T=8).
T=144
xset -display :0 dpms force off
This did not cause the issue.
T=174
xset -display :0 dpms force on
HDMI audio OK
T=294
xset -display :0 dpms force off
Here this issue appears, with the regular dmesg error (azx_get_response
timeout) appearing at T=297.
T=349
xset -display :0 dpms force on
HDMI audio no longer functional.
System details:
Asrock J4205-ITX (pentium J4205)
Onboard LSPCON converting DP 2.0 to HDMI output. HDMI connection to Denon AVR
X3100W
# uname -m
x86_64
# uname -r
4.15.0+
OS: Gentoo Linux with profile default/linux/amd64/17.0</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>