Created attachment 121246 [details] xz'ed crash dump On a Thinkpad W520 using the Intel GPU, playing Zandronum (gzdoom) with the (graphically intensive) Brutal Doom mod, every 5-15 minutes, a GPU hang occurs. Usually, the GPU gets reset properly. Sometimes, however, it freezes the entire system. Linux Kernel 4.4.0, 64bit, mesa-11.0.6, xorg-server-1.17.4, xf86-video-intel-2.99.917. No i915 cmdline parameters are in use. TearFree is used. The hang was also observed on kernel 4.1.12. [drm] stuck on render ring [drm] GPU HANG: ecode 6:0:0x91beffb8, in zandronum [3531], reason: Ring hung, action: reset [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [drm] GPU crash dump saved to /sys/class/drm/card0/error drm/i915: Resetting chip after gpu hang ... [drm] stuck on render ring [drm] GPU HANG: ecode 6:0:0x85fffffc, in zandronum [3531], reason: Ring hung, action: reset drm/i915: Resetting chip after gpu hang I am capable of testing kernel and userspace patches.
I can confirm that TearFree is not the culprit.
Created attachment 124455 [details] gpu crash dump (xz) Still happening on kernel 4.5.7
4.6.3, no change.
For testing purposes, I checked modesetting instead of xf86-video-intel. This issue still appears! This leads me to conclude that this is indeed a kernel bug.
We suspect a Mesa problem is the culprit. Do you know of a version that didn't exhibit this problem, and if so can you try to bisect the commit?
(In reply to Matt Turner from comment #5) > We suspect a Mesa problem is the culprit. Do you know of a version that > didn't exhibit this problem, and if so can you try to bisect the commit? Thanks, this seems correct! I can (mostly) confirm that mesa-10.3.7 is good and 11.0.6 bad. I've been bisecting for a week now, but I'm not making much progress. It's hard to trigger the bug deliberately, as it's a statistical event. All I can do is play a game and hope it shows up (or play for a few hours when it doesn't, to make sure it's *really* not present)
35a77a148f8b7ef03fe3b31d63719e0bfdf4b783 may be a possible culprit, but this may be incorrect. Due to the difficulty in triggering the bug, I may have inadvertently marked a bad bisect as good.
(In reply to main.haarp from comment #7) > 35a77a148f8b7ef03fe3b31d63719e0bfdf4b783 may be a possible culprit, but this > may be incorrect. > > Due to the difficulty in triggering the bug, I may have inadvertently marked > a bad bisect as good. If that bisect is correct (I have some doubts), setting INTEL_DEBUG=nocompact should avoid the issue. If it does, then we should be able to debug it quite easily from there.
(In reply to Matt Turner from comment #8) > If that bisect is correct (I have some doubts), setting > INTEL_DEBUG=nocompact should avoid the issue. If it does, then we should be > able to debug it quite easily from there. Hm. I see I only added that environment variable in time for 11.1. Try putting an unconditional return at the top of the brw_compact_instructions() function in src/mesa/drivers/dri/i965/brw_eu_compact.c. That will have the same effect (disabling instruction compaction) as the environment variable would have.
Presumably this is still a problem with mesa-13.0.0?
Sorry for the radio silence. I do not have any SNB hardware anymore, so I'm able to test this further. I cannot find 'abandonded' as an option for this bug report, so please close at your discretion. Thank you for your time!
Was no able to reproduce with: Zandronum 3.0 Brutal Doom v21 Mesa 18.1.1, 11.0.6 Kernel 4.14 Sandy Bridge cpu Played several levels of Doom2 and deathmatch, 18.1.1 works perfectly, in 11.0.6 there are terrible flickering but no hangs.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1510.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.