| Summary: | [SKL] [drm] GPU HANG: ecode 9:0:0x85dffffb, in X [447], reason: Hang on render ring, action: reset | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Mads <mads> |
| Component: | Drivers/DRI/i915 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs, mads |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | SKL | i915 features: | GPU hang |
| Attachments: |
/sys/class/drm/card0/error
another /sys/class/drm/card0/error |
||
|
Description
Mads
2016-10-18 14:11:27 UTC
Created attachment 127377 [details]
/sys/class/drm/card0/error
Recent? 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). Kernel: 4.9.0-rc1+ 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: commit a4622305e67dbb3ed224fa966160616688e43ee8 Author: Emil Velikov <emil.velikov@collabora.com> Date: Wed Oct 12 16:06:47 2016 +0100 swr: automake: add ar_eventhandlerfile_h.template to the tarball Signed-off-by: Emil Velikov <emil.velikov@collabora.com> It hasn't crashed yet when I booted with intel_iommu=igfx_off. Created attachment 127382 [details]
another /sys/class/drm/card0/error
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 Extremely nice! 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 *** |
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.