Bug 91383 - [snb] GPU HANG: ecode 6:0:0xf288fff8, in eduke32
Summary: [snb] GPU HANG: ecode 6:0:0xf288fff8, in eduke32
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-18 14:42 UTC by org.freedesktop
Modified: 2017-03-22 15:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Crash dump (315.39 KB, application/octet-stream)
2015-07-18 14:42 UTC, org.freedesktop
Details
dmesg (61.62 KB, text/plain)
2015-07-18 14:42 UTC, org.freedesktop
Details

Description org.freedesktop 2015-07-18 14:42:17 UTC
Created attachment 117230 [details]
Crash dump

Hello!

A few minutes ago, I experienced a momentary stuttering, my video player crashed, and the game I was playing (Eduke32) stopped for a second. I checked dmesg and saw:

[ 4678.947120] [drm] GPU HANG: ecode 6:0:0xf288fff8, in eduke32 [1828], reason: Ring hung, action: reset
[ 4678.947123] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 4678.947123] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 4678.947124] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 4678.947125] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[ 4678.947126] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[ 4678.953044] drm/i915: Resetting chip after gpu hang

... so here I am.

The operating system is an up-to-date version of Arch Linux. The specific package versions of everything I believe to be relevant:

linux 4.0.7-2
linux-firmware 20150527.3161bfa-1
xf86-video-intel 1:2.99.917+364+gb24e758-1
xorg-server 1.17.2-2
mesa-libgl 10.6.2-1

The crash dump is attached along with the dmesg of the machine.
Comment 1 org.freedesktop 2015-07-18 14:42:40 UTC
Created attachment 117231 [details]
dmesg
Comment 2 org.freedesktop 2015-07-18 14:43:21 UTC
Please let me know if you need more information.
Comment 3 Chris Wilson 2015-07-18 14:52:03 UTC
That looks like a bad shader. Is it reproducible? If so could you capture an apitrace of the gpu hang?
Comment 4 org.freedesktop 2015-07-18 15:45:42 UTC
The problem hasn't happened again.

I took a look into eduke32, and it seems that it actually relies entirely on the fixed-function pipeline.

I've published a trace of about ten seconds of gameplay, I don't see any calls to glUseProgram in that time:

http://waste.io7m.com/2015/07/18/eduke32.trace.xz
Comment 5 org.freedesktop 2015-07-18 15:50:25 UTC
To clarify, given that the game essentially recreates a software renderer from the 90s, I'd expect that the OpenGL calls made in the first frame are essentially the same calls that would be made in any frame.
Comment 6 Matt Turner 2017-03-22 03:24:10 UTC
Please reopen if you can still reproduce with Mesa 17.0.
Comment 7 org.freedesktop 2017-03-22 09:32:09 UTC
Will do!

Apologies for the scarcity of information, but it was an issue triggered by software that I didn't write with no obvious way to reproduce it. I've not seen it happen since, so let's assume that it's fixed for now.


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.