Created attachment 113706 [details]
Apparently Adobe's Flash Player is still not yet ready for Modern OSes, as it led to this "crash":
--- From Xorg.0.log:
[1344934.804] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[1344934.986] (EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg.
--- From dmesg (filtered only firewall stuff)
[9934868.808046] [drm] stuck on render ring
[9934868.809017] [drm] GPU HANG: ecode 0:0x9f47f9fd, in chromium , reason: Ring hung, action: reset
[9934868.809020] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[9934868.809021] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[9934868.809023] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[9934868.809024] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[9934868.809026] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[9934868.809154] [drm:i915_reset] *ERROR* Failed to reset chip: -19
[9934873.197136] chromium: segfault at 1f8 ip 00007f70c8e66def sp 00007fff654bf3a0 error 4 in i965_dri.so[7f70c8b11000+51e000]
Attaching the /sys/class/drm/card0/error file, as suggested by the log.
Please note that I am not running the latest version of Xorg/driver/kernel:
X.Org X Server 1.16.1 (Debian: 1:7.7+7)
Kernel 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (Debian: 3.16.5-1)
Driver: ? (Debian: 2:2.21.15-2+b2)
Card: GMA X3100 (not sure), reported as GM965/GL960
Having a quick look at the kernel's sources, it seems that at least the ENODEV code for the chip reset should be fixed in the "mainline" branch (3.19), but not before (3.18.7).
I suspect this may be another duplicate of the bug 80568, fixed (worked-around) by this commit:
Author: Kenneth Graunke <email@example.com>
Date: Sat Jan 17 23:21:15 2015 -0800
i965: Work around mysterious Gen4 GPU hangs with minimal state changes.
Gen4 hardware appears to GPU hang frequently when using Chromium, and
also when running 'glmark2 -b ideas'. Most of the error states contain
3DPRIMITIVE commands in quick succession, with very few state packets
between them - usually VERTEX_BUFFERS/ELEMENTS and CONSTANT_BUFFER.
I trimmed an apitrace of the glmark2 hang down to two draw calls with a
glUniformMatrix4fv call between the two. Either draw by itself works
fine, but together, they hang the GPU. Removing the glUniform call
makes the hangs disappear. In the hardware state, this translates to
removing the CONSTANT_BUFFER packet between the two 3DPRIMITIVE packets.
Flushing before emitting CONSTANT_BUFFER packets also appears to make
the hangs disappear. I observed a slowdown in glxgears by doing it all
the time, so I've chosen to only do it when BRW_NEW_BATCH and
BRW_NEW_PSP are unset (i.e. we haven't done a CS_URB_STATE change or
already flushed the whole pipeline).
I'd much rather understand the problem, but at this point, I don't see
how we'd ever be able to track it down further. We have no real tools,
and the hardware people moved on years ago. I've analyzed 20+ error
states and read every scrap of documentation I could find.
Signed-off-by: Kenneth Graunke <firstname.lastname@example.org>
Acked-by: Matt Turner <email@example.com>
Cc: "10.4 10.3" <firstname.lastname@example.org>
It's in git, and backports are in Mesa 10.4.x for x > 3. Please try upgrading to >10.4.3. If it's resolved by such an upgrade, please mark as a duplicate of bug 80568.
No reply. Marking as duplicate.
*** This bug has been marked as a duplicate of bug 80568 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.