<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - [BAT][BSW] igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b hung in CI"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100989#c11">Comment # 11</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - [BAT][BSW] igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b hung in CI"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100989">bug 100989</a>
from <span class="vcard"><a class="email" href="mailto:martin.peres@free.fr" title="Martin Peres <martin.peres@free.fr>"> <span class="fn">Martin Peres</span></a>
</span></b>
<pre>(In reply to krisman from <a href="show_bug.cgi?id=100989#c10">comment #10</a>)
<span class="quote">> (In reply to Petri Latvala from <a href="show_bug.cgi?id=100989#c9">comment #9</a>)
> > The test is doing some suboptimal things. It first does the suspend/resume
> > cycle, and then checks if the tested pipe has valid connectors, so it will
> > suspend anyway even when it will skip.
>
> For the record, I submitted a patch to address the issue with the test
> suspending before skipping. Petri already reviewed and pushed to igt.
>
> 31f71d62d5ff ("igt/kms_pipe_crc_basic: Skip test before system suspend")</span >
Thanks for this! Reducing the noise and the execution time is a Yay from me :)
<span class="quote">>
> > In the case of CI_DRM_2699, there were about 3 successful suspend/resumes
> > before suspend-read-crc-pipe-b came along where the DUT never recovered from
> > the suspend. The point being here that it's the suspend/resume that jams,
> > not this particular subtest.
>
> Agreed. The issue is more related to the recovery of the suspend than the
> read_crc itself. Just need to mention, though, that bsw-n3050 has
> connectors attached, as well as VGA, meaning that it's not a case where my
> patch will make igt skip.</span >
Right, I will still close the bug as the issue is somewhere else than our
driver...
<span class="quote">>
> We are also discussing on the list a way to reduce the overhead provoked by
> the thousands of dp_aux_ch timeout messages below:
>
> [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x71450064</span >
Right, any success on that?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>