<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:matthew.d.roper@intel.com" title="Matt Roper <matthew.d.roper@intel.com>"> <span class="fn">Matt Roper</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Random tests - Failed assertion: ret == 0, error: -22 != 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111779">bug 111779</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Severity</td>
<td>not set
</td>
<td>minor
</td>
</tr>
<tr>
<td style="text-align:right;">Priority</td>
<td>not set
</td>
<td>low
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Random tests - Failed assertion: ret == 0, error: -22 != 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111779#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Random tests - Failed assertion: ret == 0, error: -22 != 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111779">bug 111779</a>
from <span class="vcard"><a class="email" href="mailto:matthew.d.roper@intel.com" title="Matt Roper <matthew.d.roper@intel.com>"> <span class="fn">Matt Roper</span></a>
</span></b>
<pre>This is basically the same problem as <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Frequent link training failures on fi-icl-u4 cause sporadic modeset failures in random CI tests"
href="show_bug.cgi?id=111185">bug 111185</a> but on fi-cml-h's DP-3
connector rather than fi-icl-u4's DP-4 connector.
Specifically, we have link training failures when attempting 2 lanes at data
rate 270000
<7> [237.429108] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:123:DP-3]
Link Training failed at link rate = 270000, lane count = 2
which forces us to downgrade to 2 lanes at data rate 162000:
<7> [239.250661] [drm:intel_dp_compute_config [i915]] DP link computation with
max lane count 2 max rate 162000 max bpp 36 pixel clock 148500KHz
<7> [239.250697] [drm:intel_dp_compute_config [i915]] Force DSC en = 0
<7> [239.250733] [drm:intel_atomic_check [i915]] Encoder config failure: -22
and this fails because the 148500 clock * a minimum RGB bpp of 18 means that we
require a minimum bandwidth of 2673000/8 = 334125 to drive this mode. Since
334125 > 270000 the modeset fails.
Since this bug and <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Frequent link training failures on fi-icl-u4 cause sporadic modeset failures in random CI tests"
href="show_bug.cgi?id=111185">bug 111185</a> are caused by flaky hardware (either the board,
the cable, or any dongles/adapters that are part of the link), I think it makes
sense to keep a separate bug for each platform; I'm not going to mark this one
as a duplicate of <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Frequent link training failures on fi-icl-u4 cause sporadic modeset failures in random CI tests"
href="show_bug.cgi?id=111185">bug 111185</a>, even though conceptually it's the same problem,
since really the only "fix" is replacing hardware on those two separate
machines.
Impact-wise, this is a CI-specific problem; it reduces the value of CI on this
board, but won't impact end users (rejecting these modesets and forcing the
userspace display server to pick a smaller mode is exactly what's supposed to
happen). Given that we should be able to write a bit more precise CIbuglog
filters that look for "Link Training failed at link rate = XXX, lane count = X"
followed later by a "Encoder config failure: -22" I think we can do a pretty
good job of recognizing and filtering these failures without causing lots of
false positives or false negatives, so I'm setting the importance to "low."
It's also worth noting that the hardware here doesn't seem to be as flaky as
the ICL hardware in <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][DRMTIP] Frequent link training failures on fi-icl-u4 cause sporadic modeset failures in random CI tests"
href="show_bug.cgi?id=111185">bug 111185</a>'s case, although it's possible that may change
over time.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>