<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GEN9] random/rare GPU hangs in tessellation tests"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110131#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GEN9] random/rare GPU hangs in tessellation tests"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110131">bug 110131</a>
from <span class="vcard"><a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> <span class="fn">Lionel Landwerlin</span></a>
</span></b>
<pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=110131#c0">comment #0</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=143679" name="attach_143679" title="SKL GT4e SynMark OglTerrainFlyTess hang error state">attachment 143679</a> <a href="attachment.cgi?id=143679&action=edit" title="SKL GT4e SynMark OglTerrainFlyTess hang error state">[details]</a></span>
> SKL GT4e SynMark OglTerrainFlyTess hang error state
>
> Setup:
> * Ubuntu 18.04
> * v5.0+ drm-tip kernel & git version of Xserver
> * Mesa git version
>
> In last few days I've seen couple of random GPU hangs in tessellation
> related tests:
>
> - on SKL GT4e, recoverable one once in SynMark2 v7 OglTerrainFlyTess, and
> once in GfxBench v5 GL Aztec Ruins normal (does also lot of other things
> besides tessellation)
> - one system hang in GfxBench tessellation test on KBL GT2 day before
>
> It's possible that first item is related to starting to use Weston/XWayland
> instead of normal X:
> ----------------------------------------------------
> [ 8231.866172] i915 0000:00:02.0: GPU HANG: ecode 9:1:0xfffffffe, in [0],
> hang on rcs0
> [ 8231.866174] [drm] GPU hangs can indicate a bug anywhere in the entire gfx
> stack, including userspace.
> [ 8231.866174] [drm] Please file a _new_ bug report on bugs.freedesktop.org
> against DRI -> DRM/Intel
> [ 8231.866175] [drm] drm/i915 developers can then reassign to the right
> component if it's not a kernel issue.
> [ 8231.866175] [drm] The gpu crash dump is required to analyze gpu hangs, so
> please always attach it.
> [ 8231.866175] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> [ 8231.867183] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
> [ 8239.858844] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
> [ 8243.313841] Asynchronous wait on fence i915:weston[643]/1:5eb9e timed out
> (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
> [ 8247.858844] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
> ----------------------------------------------------
>
> See attachement for error state.
>
> (Another possibility could be that those started (to be more visible?) after
> the "intel/nir: Vectorize all IO" fix to <a class="bz_bug_link
bz_status_VERIFIED bz_closed"
title="VERIFIED FIXED - [GEN8+] up to 10% perf drop on several 3D benchmarks"
href="show_bug.cgi?id=107510">bug 107510</a>, as that improved
> tessellation tests.)
>
> Note: I don't actively read dmesg output, so I may have missed most of the
> recoverable GPU hangs unless they've been serious enough to hang the system,
> fail the test, or at least slow it down enough to significantly impact
> performance. I'll add some better tracking for that.
>
> No idea whether these are related to compute hangs <a class="bz_bug_link
bz_status_NEW "
title="NEW - [SKL]Â (recoverable) GPU hangs in benchmarks using compute shaders"
href="show_bug.cgi?id=108820">bug 108820</a>, or Heaven
> hang <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - [SKL]Â Unigine Heaven 4.0 fails to GPU hangs"
href="show_bug.cgi?id=103556">bug 103556</a>.</span >
This error state has consistent HS/TE/DS stage programming so it would seem to
be a different issue from the unigine bug.</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 the QA Contact for the bug.</li>
</ul>
</body>
</html>