<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><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> changed
<a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS]: igt@gem_mmap_gtt@hang - incomplete/timeout - i915 0000:00:02.0: i915_reset_device timed out, cancelling all in-flight rendering."
href="https://bugs.freedesktop.org/show_bug.cgi?id=109605">bug 109605</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>RESOLVED
</td>
<td>CLOSED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS]: igt@gem_mmap_gtt@hang - incomplete/timeout - i915 0000:00:02.0: i915_reset_device timed out, cancelling all in-flight rendering."
href="https://bugs.freedesktop.org/show_bug.cgi?id=109605#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS]: igt@gem_mmap_gtt@hang - incomplete/timeout - i915 0000:00:02.0: i915_reset_device timed out, cancelling all in-flight rendering."
href="https://bugs.freedesktop.org/show_bug.cgi?id=109605">bug 109605</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 Chris Wilson from <a href="show_bug.cgi?id=109605#c2">comment #2</a>)
<span class="quote">> commit aeaaa55c7368ea0e7c195baa35dea37b806efb11
> Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
> Date: Tue Feb 12 13:08:30 2019 +0000
>
> drm/i915: Recursive i915_reset_trylock() verboten
>
> We cannot nest i915_reset_trylock() as the inner may wait for the
> I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
> waiting for our outermost lock. As we take the reset srcu around the
> fence update, we have to defer taking it in i915_gem_fault() until after
> we acquire the pin on the fence to avoid nesting. This is a little ugly,
> but still works. If a reset occurs between i915_vma_pin_fence() and the
> second reset lock, the reset will restore the fence register back to the
> pinned value before the reset lock allows us to proceed (our mmap won't
> be revoked as we haven't yet marked it as being a userfault as that
> requires us to hold the reset lock), so the pagefault is still
> serialised with the revocation in reset.
>
> Bugzilla: <a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS]: igt@gem_mmap_gtt@hang - incomplete/timeout - i915 0000:00:02.0: i915_reset_device timed out, cancelling all in-flight rendering."
href="show_bug.cgi?id=109605">https://bugs.freedesktop.org/show_bug.cgi?id=109605</a>
> Fixes: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
> registers across reset")
> Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
> Cc: Mika Kuoppala <<a href="mailto:mika.kuoppala@intel.com">mika.kuoppala@intel.com</a>>
> Reviewed-by: Mika Kuoppala <<a href="mailto:mika.kuoppala@intel.com">mika.kuoppala@intel.com</a>>
> Link:
> <a href="https://patchwork.freedesktop.org/patch/msgid/20190212130831.14425-1">https://patchwork.freedesktop.org/patch/msgid/20190212130831.14425-1</a>-
> <a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a></span >
10 runs without any issues, as opposed to multiple failures per run. Seems like
it was the right fix! Thanks!</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>