Bug 88207 - [hsw] GPU HANG: ecode 0:0x84dfbffe, in cubestorm [28178], reason: Ring hung, action: reset
Summary: [hsw] GPU HANG: ecode 0:0x84dfbffe, in cubestorm [28178], reason: Ring hung, ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-08 17:17 UTC by Toralf Förster
Modified: 2015-03-12 21:15 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
i915_error_state (479.45 KB, text/plain)
2015-01-08 17:17 UTC, Toralf Förster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster 2015-01-08 17:17:23 UTC
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
Comment 1 Chris Wilson 2015-01-08 20:56:36 UTC
What's cubestorm and is this 100% reproducible?
Comment 2 Toralf Förster 2015-01-08 23:15:25 UTC
(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)
Comment 3 Alejandro Piñeiro (freenode IRC: apinheiro) 2015-03-12 20:00:17 UTC
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?
Comment 4 Toralf Förster 2015-03-12 20:32:55 UTC
(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 ?
Comment 5 Matt Turner 2015-03-12 21:15:25 UTC
(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.