Created attachment 95298 [details] GPU crash dump Mär 07 12:37:01 Kai-X230 kernel: [drm:i915_context_is_banned] *ERROR* context hanging too fast, declaring banned! Mär 07 12:37:01 Kai-X230 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0xa591000 ctx 1) at 0xa591e14 Mär 07 12:37:01 Kai-X230 kernel: [drm] stuck on render ring Mär 07 12:36:54 Kai-X230 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x3976a000 ctx 1) at 0x3976e800 Mär 07 12:36:54 Kai-X230 kernel: [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Mär 07 12:36:54 Kai-X230 kernel: [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Mär 07 12:36:54 Kai-X230 kernel: [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Mär 07 12:36:54 Kai-X230 kernel: [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Mär 07 12:36:54 Kai-X230 kernel: [drm] GPU crash dump saved to /sys/class/drm/card0/error Mär 07 12:36:54 Kai-X230 kernel: [drm] stuck on render ring
Context got banned on the first hang according to this log snippet which is odd. Please upload the whole dmesg
(In reply to comment #1) > Context got banned on the first hang according to this log snippet which is > odd. Ah the lines are in reverse order. Should have looked at the timestamps more closely.
Created attachment 95301 [details] Whole dmesg output
This looks really strange. These look like Mesa (3D driver) batchbuffers (based on the binding/sampler/constant/unit state sequences), but the sequence before the hanging flush is: 1. VS related state. 2. GS disable state. 3. PS related state. 4. 3DSTATE_VERTEX_BUFFERS 5. 3DPRIMITIVE. But, as far as I can tell, Mesa /always/ emits 3DSTATE_VERTEX_ELEMENTS after 3DSTATE_VERTEX_BUFFERS. It's always done in the same function, directly one after the next. So, I'm not sure what to make of this. What version of Mesa are you using? It's clearly not 10.1, but I'm not sure how far back it is.
Created attachment 95343 [details] glxinfo
(In reply to comment #4) > This looks really strange. These look like Mesa (3D driver) batchbuffers > (based on the binding/sampler/constant/unit state sequences), but the > sequence before the hanging flush is: > > 1. VS related state. > 2. GS disable state. > 3. PS related state. > 4. 3DSTATE_VERTEX_BUFFERS > 5. 3DPRIMITIVE. > > But, as far as I can tell, Mesa /always/ emits 3DSTATE_VERTEX_ELEMENTS after > 3DSTATE_VERTEX_BUFFERS. It's always done in the same function, directly one > after the next. So, I'm not sure what to make of this. > > What version of Mesa are you using? It's clearly not 10.1, but I'm not sure > how far back it is. glxinfo tell me its 10.0.3
I upgraded to Mesa 10.1. In 10.1 all works fine so far. I will report if the error happend again.
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.