<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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 <a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> Lionel Landwerlin</a> <pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=110131#c0">comment #0</a>) > Created <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> > 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>. 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> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>