lkml.org 
[lkml]   [2017]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Intel-gfx] GPU hang with kernel 4.10rc3
From
Date
On 11/01/17 18:08, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
>>
>> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
>> [1431], reason: Hang on render ring, action: reset
>> [ 49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
>> gfx stack, including userspace.
>> [ 49.213700] [drm] Please file a _new_ bug report on
>> bugs.freedesktop.org against DRI -> DRM/Intel
>> [ 49.213700] [drm] drm/i915 developers can then reassign to the right
>> component if it's not a kernel issue.
>> [ 49.213700] [drm] The gpu crash dump is required to analyze gpu
>> hangs, so please always attach it.
>> [ 49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
>> [ 49.213755] drm/i915: Resetting chip after gpu hang
>> [ 60.213769] drm/i915: Resetting chip after gpu hang
>> [ 71.189737] drm/i915: Resetting chip after gpu hang
>> [ 82.165747] drm/i915: Resetting chip after gpu hang
>> [ 93.205727] drm/i915: Resetting chip after gpu hang
>>
>> The dump is attached.
>
> That's a nasty one. The first couple of pages of the batchbuffer appear
> to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
> may be a concurrent write by either the GPU or CPU, or we may have
> incorrected mapped a set of pages. That it doesn't recovered suggests
> that the corruption occurs frequently, probably on every request/batch.

I hoped someone would have an idea already.

> Is this a new bug? Bisection would be the fastest way to triage it.

Commit 7453c549f was still okay. Starting bisect now (2882 commits, 12
steps) ...


Juergen

\
 
 \ /
  Last update: 2017-01-12 07:04    [W:0.103 / U:4.688 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site