<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:arkadiusz.hiler@intel.com" title="Arek Hiler <arkadiusz.hiler@intel.com>"> <span class="fn">Arek Hiler</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@i915_pm_sseu@full-enable - Fail - Failed assertion: stat->info.eu_total <= stat->hw.eu_total"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110584">bug 110584</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;">Priority</td>
<td>high
</td>
<td>low
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@i915_pm_sseu@full-enable - Fail - Failed assertion: stat->info.eu_total <= stat->hw.eu_total"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110584#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@i915_pm_sseu@full-enable - Fail - Failed assertion: stat->info.eu_total <= stat->hw.eu_total"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110584">bug 110584</a>
from <span class="vcard"><a class="email" href="mailto:arkadiusz.hiler@intel.com" title="Arek Hiler <arkadiusz.hiler@intel.com>"> <span class="fn">Arek Hiler</span></a>
</span></b>
<pre>pm_sseu@full-enable makes sure that all the slices/subslices/EUs are "fully
enabled" (i.e. not power gated) while graphics is busy.
To make the execution units busy media_spin workload is used, and after waiting
for 2ms for a (supposedly) 10ms workload to be fully spun up we are reading the
current state from i915_sseu_status debugfs.
We have seen this failure once on shard-skl8 over 2 months ago. media_spin was
working correctly as the asserts both on function exit and verification of the
number of 'spins' performed were successful.
My guess is that the GPU managed to spin down because the batch ended already -
the numbers of spins is established in a experimental way and prone to
scheduling noise. Either that or we have read some trash from debugfs.
Volatility is not that bad if it happened once in forever.
Due to negligible impact and being cosmic-ray-flipping-a-bit-class of an event
I am lowering the priority to low.</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>