<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [CI][SHARDS] igt@prime_busy@wait-hang-vebox|igt@gem_eio@in-flight-suspend - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111256">bug 111256</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;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [CI][SHARDS] igt@prime_busy@wait-hang-vebox|igt@gem_eio@in-flight-suspend - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111256#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [CI][SHARDS] igt@prime_busy@wait-hang-vebox|igt@gem_eio@in-flight-suspend - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111256">bug 111256</a>
from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
<pre>commit c7302f204490f3eb4ef839bec228315bcd3ba43f (drm-intel/for-linux-next,
drm-intel/drm-intel-next-queued)
Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Date: Thu Aug 8 21:27:58 2019 +0100
drm/i915: Defer final intel_wakeref_put to process context
As we need to acquire a mutex to serialise the final
intel_wakeref_put, we need to ensure that we are in process context at
that time. However, we want to allow operation on the intel_wakeref from
inside timer and other hardirq context, which means that need to defer
that final put to a workqueue.
Inside the final wakeref puts, we are safe to operate in any context, as
we are simply marking up the HW and state tracking for the potential
sleep. It's only the serialisation with the potential sleeping getting
that requires careful wait avoidance. This allows us to retain the
immediate processing as before (we only need to sleep over the same
races as the current mutex_lock).
v2: Add a selftest to ensure we exercise the code while lockdep watches.
v3: That test was extremely loud and complained about many things!
v4: Not a whale!
Bugzilla: <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@perf_pmu@* - dmesg-warn - WARNING: inconsistent lock state"
href="show_bug.cgi?id=111295">https://bugs.freedesktop.org/show_bug.cgi?id=111295</a>
References: <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@perf_pmu@busy-hang-bcs0 - fail - Failed assertion: (double)(val) <= (1.0 + (tolerance)) * (double)(0) && (double)(val) >= (1.0 - (tolerance)) * (double)(0)"
href="show_bug.cgi?id=111245">https://bugs.freedesktop.org/show_bug.cgi?id=111245</a>
References: <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [CI][SHARDS] igt@prime_busy@wait-hang-vebox|igt@gem_eio@in-flight-suspend - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!"
href="show_bug.cgi?id=111256">https://bugs.freedesktop.org/show_bug.cgi?id=111256</a>
Fixes: 18398904ca9e ("drm/i915: Only recover active engines")
Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Cc: Tvrtko Ursulin <<a href="mailto:tvrtko.ursulin@intel.com">tvrtko.ursulin@intel.com</a>>
Cc: Mika Kuoppala <<a href="mailto:mika.kuoppala@linux.intel.com">mika.kuoppala@linux.intel.com</a>>
Reviewed-by: Mika Kuoppala <<a href="mailto:mika.kuoppala@linux.intel.com">mika.kuoppala@linux.intel.com</a>>
Link:
<a href="https://patchwork.freedesktop.org/patch/msgid/20190808202758.10453-1-chris@chris-wilson.co.uk">https://patchwork.freedesktop.org/patch/msgid/20190808202758.10453-1-chris@chris-wilson.co.uk</a>
Probably.</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 assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>