Author: Chris Wilson <email@example.com>
Date: Tue Oct 18 14:27:24 2016 +0100
drm-intel-nightly: 2016y-10m-18d-13h-24m-11s UTC integration manifest
[ 66.622400] [drm] GPU HANG: ecode 9:0:0x85dffffb, in X , reason: Hang on render ring, action: reset
[ 66.622402] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 66.622403] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 66.622404] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 66.622405] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[ 66.622406] [drm] GPU crash dump saved to /sys/class/drm/card0/error
Happens all the time after starting X (after a minute or so). Virtualbox is installed so that taints the kernel I guess, but I post the /sys/class/drm/card0/error anyway.
This is on a Dell XPS 9550.
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
Created attachment 127377 [details]
Can you please try with intel_iommu=igfx_off
Mads, please retry as Chris is advising: with intel_iommu=igfx_off on your boot command line.
There were also improvements pushed in Mesa that will benefit to your system, so please re-test with latest Mesa to see if this issue is still occurring.
In parallel, assigning to Mesa product (please let me know if I am mistaken with this GPU Hang).
Platform: Skylake (pci id: 0x191b; PCI Revision: 0x06; PCI Subsystem: 1028:06e4)
Mesa: [Please confirm your mesa version]
From this error dump, hung is happening in render ring batch with active head at 0xc7ffe38c, with 0x7a000004 (PIPE_CONTROL) as IPEHR.
Batch extract (around 0xc7ffe38c):
0xc7ffe358: 0x7b000005: 3DPRIMITIVE: fail sequential
0xc7ffe35c: 0x00000006: vertex count
0xc7ffe360: 0x00000004: start vertex
0xc7ffe364: 0x00000000: instance count
0xc7ffe368: 0x00000001: start instance
0xc7ffe36c: 0x00000000: index bias
0xc7ffe370: 0x00000000: MI_NOOP
Bad count in PIPE_CONTROL
0xc7ffe374: 0x7a000004: PIPE_CONTROL: no write, no depth stall, no RC write flush, no inst flush
0xc7ffe378: 0x00101001: destination address
0xc7ffe37c: 0x00000000: immediate dword low
0xc7ffe380: 0x00000000: immediate dword high
Bad count in PIPE_CONTROL
0xc7ffe38c: 0x7a000004: PIPE_CONTROL: no write, no depth stall, no RC write flush, no inst flush
0xc7ffe390: 0x00000408: destination address
0xc7ffe394: 0x00000000: immediate dword low
0xc7ffe398: 0x00000000: immediate dword high
0xc7ffe3a4: 0x78230000: 3D UNKNOWN: 3d_965 opcode = 0x7823
0xc7ffe3a8: 0x00007e00: MI_NOOP
My mesa version:
Author: Emil Velikov <firstname.lastname@example.org>
Date: Wed Oct 12 16:06:47 2016 +0100
swr: automake: add ar_eventhandlerfile_h.template to the tarball
Signed-off-by: Emil Velikov <email@example.com>
It hasn't crashed yet when I booted with intel_iommu=igfx_off.
Created attachment 127382 [details]
Crash when using chromium, this time without any connected monitors/docking stations.
This is _not_ with intel_iommu=igfx_off, I thought I should upload one more crash with less hw connected.
> It hasn't crashed yet when I booted with intel_iommu=igfx_off.
By the way, is this a fix or workaround? :) Does this have any caveats other than not being able to use the graphics controller inside of a VM?
I guess I also must mention that your tip with intel_iommu=igfx_off also solved another bug I reported: https://bugs.freedesktop.org/show_bug.cgi?id=97211
Now the only issue I have left with my XPS 15 is https://bugs.freedesktop.org/show_bug.cgi?id=93578
intel_iommu=igfx_off is not fix of this defect, it is just avoiding it
btw dup of bug 89360?
I saw the same kind of messages in dmesg, so I would guess this is a duplicate of bug 89360 yes...
*** This bug has been marked as a duplicate of bug 89360 ***