Created attachment 111965 [details] i915_error_state Jan 8 16:31:37 t44 kernel: [53157.198509] [drm] stuck on render ring Jan 8 16:31:37 t44 kernel: [53157.200517] [drm] GPU HANG: ecode 0:0x84dfbffe, in cubestorm [28178], reason: Ring hung, action: reset Jan 8 16:31:37 t44 kernel: [53157.200525] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Jan 8 16:31:37 t44 kernel: [53157.200530] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Jan 8 16:31:37 t44 kernel: [53157.200535] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Jan 8 16:31:37 t44 kernel: [53157.200540] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Jan 8 16:31:37 t44 kernel: [53157.200546] [drm] GPU crash dump saved to /sys/class/drm/card0/error Jan 8 16:31:43 t44 kernel: [53163.197060] [drm] stuck on render ring Jan 8 16:31:43 t44 kernel: [53163.198133] [drm] GPU HANG: ecode 0:0x84dfbffe, in cubestorm [28178], reason: Ring hung, action: reset
What's cubestorm and is this 100% reproducible?
(In reply to Chris Wilson from comment #1) > What's cubestorm and is this 100% reproducible? It is a shiny new T440s setup in December - it is the 2nd crash, the 1st I ignored. The executable belogs to : tfoerste@t44 ~/devel/linux $ equery b /usr/share/kde4/services/ScreenSavers/cubestorm.desktop * Searching for /usr/share/kde4/services/ScreenSavers/cubestorm.desktop ... kde-base/kdeartwork-kscreensaver-4.14.3 (/usr/share/kde4/services/ScreenSavers/cubestorm.desktop)
The bug is already fixed on master. I bisected, and it got solved with this commit: commit 02ca66fbc3e2b272afcb9bae66348d3b1900e2c3 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Thu Aug 21 14:41:17 2014 -0700 i965: Use unsynchronized maps for the program cache on LLC platforms. There's no reason to stall on pwrite - the CPU always appends to the buffer and never modifies existing contents, and the GPU never writes it. Further, the CPU always appends new data before submitting a batch that requires it. This code predates the unsynchronized mapping feature, so we simply didn't have the option when it was written. Ideally, we would do this for non-LLC platforms too, but unsynchronized mapping support only exists for LLC systems. Saves a bunch of stall avoidance copies when uploading shaders. v2: Rebase on changes to previous patch. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> [v1] Should I close the bug?
(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #3) > The bug is already fixed on master. The master usually don't help a common user, so why not wait till a released version contains the fix ?
(In reply to Toralf Förster from comment #4) > (In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #3) > > The bug is already fixed on master. > > The master usually don't help a common user, so why not wait till a released > version contains the fix ? That's not how this works... we (developers) need to see which bugs we should work on. If we leave bugs open that are actually fixed, we'll waste a bunch of time. But more to the point, this has been fixed since 10.4.0, released December 14 2014.
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.