Bug 103723 - GPU HANG: ecode 3:0:0x01c40081, in Xorg [1677], reason: Hang on rcs0, action: reset
Summary: GPU HANG: ecode 3:0:0x01c40081, in Xorg [1677], reason: Hang on rcs0, action:...
Status: CLOSED DUPLICATE of bug 103502
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-13 17:44 UTC by Sitsofe Wheeler
Modified: 2018-01-04 18:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
/sys/class/drm/card0/error (1.83 KB, application/x-bzip)
2017-11-13 17:44 UTC, Sitsofe Wheeler
no flags Details

Description Sitsofe Wheeler 2017-11-13 17:44:17 UTC
Created attachment 135439 [details]
/sys/class/drm/card0/error

Description of the problem:
While using XUbuntu 16.04 with a custom kernel the screen briefly froze before going black and coming back.

Steps to reproduce:
1. Use XUbuntu with a compositor?

Expected result:
GPU not to hang?

Actual result:
Once in a while a GPU hang.

How reproducible is the problem?
Unknown, somewhat rare but it's happened on two different boots.

Version information:
libdrm-intel1 2.4.76-1~ubuntu16.04.1
xorg 1:7.7+13ubuntu3
xserver-xorg-video-intel-hwe-16.04 2:2.99.917+git20170309-0ubuntu1~16.04.1
Linux eeepc 4.14.0-rc4 #7 PREEMPT Sat Nov 11 13:19:40 UTC 2017 i686 i686 i686 GNU/Linux
XUbuntu 16.04
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
EeePC 900
Comment 1 Chris Wilson 2017-11-13 19:08:49 UTC
commit 1d033beb20d6d5885587a02a393b6598d766a382
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Oct 31 10:36:07 2017 +0000

    drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
    
    In case the object has changed tiling between calls to execbuf, we need
    to check if the existing offset inside the GTT matches the new tiling
    constraint. We even need to do this for "unfenced" tiled objects, where
    the 3D commands use an implied fence and so the object still needs to
    match the physical fence restrictions on alignment (only required for
    gen2 and early gen3).
    
    In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
    the execobjects array"), the idea was to remove the second guessing and
    only set the NEEDS_MAP flag when required. However, the entire check
    for an unusable offset for fencing was removed and not just the
    secondary check. I.e.
    
            /* avoid costly ping-pong once a batch bo ended up non-mappable */
            if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
                !i915_vma_is_map_and_fenceable(vma))
                    return !only_mappable_for_reloc(entry->flags);
    
    was entirely removed as the ping-pong between execbuf passes was fixed,
    but its primary purpose in forcing unaligned unfenced access to be
    rebound was forgotten.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
    Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171031103607.17836-1-chris@chris-wilson.co.uk
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

*** This bug has been marked as a duplicate of bug 103502 ***


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.