Summary: | [hsw] GPU HANG: ecode 0:0x84dfbffe, in cubestorm [28178], reason: Ring hung, action: reset | ||
---|---|---|---|
Product: | Mesa | Reporter: | Toralf Förster <toralf.foerster> |
Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | intel-gfx-bugs |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | i915_error_state |
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.
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