Created attachment 80931 [details] dmesg System Environment: -------------------------- Platform: Pineview/GM45 Kernel: (drm-intel-next-queued)cab8b5862acd55019fbeede6940d1a601912d6b8 Bug detailed description: ------------------------- It segfault on Pineview and GM45 with drm-intel-next-queued kernel.It works well on drm-intel-fixes kernel. Bisect shows:a89cdd3cfcd66d932d4ae2617c5e89279515f14d is the first bad commit. commit a89cdd3cfcd66d932d4ae2617c5e89279515f14d Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> AuthorDate: Wed Jun 12 12:35:34 2013 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Thu Jun 13 17:42:18 2013 +0200 drm/i915: refuse to submit more batchbuffers from guilty context If context has recently submitted a faulty batchbuffers guilty of gpu hang and decides to keep submitting more crap, ban it permanently. Note: This is just a refinment of the existing policy to declare the gpu wedged when it's hanging too often. We have that in place to increase the odds of a system surviving gpu hang storms (and so getting a useful bug report with the error state). With this patch here we reduce the risk to take down unrelated applications, since especially modern compositors tend to die when mesa can't submit batches any more. So for the somewhat common case of a specific gl workload causing a gpu hang flurry we should now have less grumpy users since we don't take down their entire deskopt enviroment any more. v2: Store guilty ban status bool in gpu_error instead of pointers that might become danling before hang is declared. v3: Use return value for banned status instead of stashing state into gpu_error (Chris Wilson) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added note to commit message to explain why we want this, which addresses a concern Ben raised.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> output: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. Segmentation fault (core dumped) Reproduce steps: ---------------- 1. xinit 2. glxgears
Created attachment 80932 [details] gles2_shaders_for_33 case Following piglit_gles2 cases also segfault with same bisect commit: gles2_shaders_18_else_case gles2_shaders_for_33 gles2_shaders_for_if_break gles2_shaders_for_if_continue gles2_shaders_if_builtin_discard gles2_shaders_prog_only gles2_shaders_prog_vertex build the attachment gles2_shaders_for_33 and run it.
It also happens on Ironlake. Many Piglit cases and all Ogles2conform cases fail with same bisect commit.
Created attachment 80955 [details] [review] Patch to fix context ban on architectures where there are no hw_contexts
Created attachment 80958 [details] [review] Fix retrieval of hangcheck stats
(In reply to comment #4) > Created attachment 80958 [details] [review] [review] > Fix retrieval of hangcheck stats Fixed by this patch.
Offending patch was dropped from drm-intel-next-queued
Verified. Fixed.
Closing old verified.
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.