Bug 89865 - [snb 3.18.6] GPU hang in X
Summary: [snb 3.18.6] GPU hang in X
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-01 20:59 UTC by Florian Bruhin
Modified: 2017-07-24 22:47 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
/sys/class/drm/card0/error (2.13 MB, text/plain)
2015-04-01 20:59 UTC, Florian Bruhin
no flags Details

Description Florian Bruhin 2015-04-01 20:59:51 UTC
Created attachment 114822 [details]
/sys/class/drm/card0/error

A Qt application suddently hung and stopped redrawing, a few seconds later my screen was black quickly and I got this in my dmesg:

kern  :info  : [Apr 1 21:34] [drm] stuck on render ring
kern  :info  : [  +0.001517] [drm] GPU HANG: ecode 0:0x95fdfffd, in systemd-logind [424], reason: Ring hung, action: reset
kern  :info  : [  +0.000005] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
kern  :info  : [  +0.000003] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
kern  :info  : [  +0.000003] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
kern  :info  : [  +0.000002] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
kern  :info  : [  +0.000003] [drm] GPU crash dump saved to /sys/class/drm/card0/error
kern  :info  : [  +5.990725] [drm] stuck on render ring
kern  :info  : [  +0.002213] [drm] GPU HANG: ecode 0:0x85effffd, in systemd-logind [424], reason: Ring hung, action: reset
kern  :err   : [  +0.000138] [drm:i915_context_is_banned] *ERROR* gpu hanging too fast, banning!

This is on Archlinux, Linux 3.18.6-1-ARCH, X.org 1.17.1-3, xf86-video-intel 2.99.917-4.
Comment 1 Chris Wilson 2015-04-01 21:27:24 UTC
That's puzzling. The hang was just in some standard sub-pixel text rendering, all the surfaces are valid and the state looks intact. Then once the GPU died, it died for good. Can you reproduce this? (Is the Qt application a good test case?) Could you then try a few different kernels just to see if it a regression there?
Comment 2 Florian Bruhin 2015-04-01 21:34:11 UTC
I can't reproduce it, no. I'm using that application (qutebrowser) for months (I'm the developer, heh :D), but this is the first time I've seen this.

Could this be somehow related to the system being low on (or out of) memory? qutebrowser/QtWebKit has a bug where it uses gigabytes of memory on a certain page - the OOM killer got invoked 12 minutes before that bug, and it's possible I was on that page again when it happened (though I don't remember, and there was no OOM killer this time).... So yeah, seems unlikely, but that's the only thing coming to mind.
Comment 3 Ander Conselvan de Oliveira 2015-06-02 09:03:22 UTC
Seems unlikely we'll be able to fix the bug if it is impossible to reproduce. Please reopen if you can reproduce it again.
Comment 4 Florian Bruhin 2015-06-02 09:05:17 UTC
I've never seen it again either - so I understand.

Thanks for your effort!


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.