Created attachment 99304 [details] dmesg ==System Environment== -------------------------- Regression: Yes. Good commit on -next-queued(b7c0d9df97c10ec5693a838df2fd53058f8e9e96) The test was blocked by Bug 78274, unable to bisect. Non-working platforms: BDW ==kernel== -------------------------- -nightly: f79ba79cf037eea9ee757ad37730b00f43d5ef80 (fails) -queued: d3b448d9917a3d6531e499d88bfb13ea5e31e4ad (fails) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 16 18:59:00 2014 +0100 drm/i915: Only unpin the default ctx object if it exists Since commit 691e6415c891b8b2b082a120b896b443531c4d45 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 9 09:07:36 2014 +0100 drm/i915: Always use kref tracking for all contexts. we have contexts everywhere, and so we must be careful to distinguish fake contexts, which do not have an associated bo, and real ones, which do. In particular, we now need to be careful not to dereference NULL pointers. This is one such example, as the commit highlighted above failed to move the unpinning of the default ctx object into the real-context-only branch. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78792 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> -fixes: e95a2f7509f5219177d6821a0a8754f93892ca56 (works) Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 8 15:09:19 2014 +0300 drm/i915: Increase WM memory latency values on SNB On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <crshman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 Tested-by: Robert Navarro <crshman@gmail.com> Tested-by: Vitaly Minko <vitaly.minko@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> ==Bug detailed description== ----------------------------- igt/gem_seqno_wrap fails Output: ./gem_seqno_wrap IGT-Version: 1.6-g252d115 (x86_64) (Linux: 3.15.0-rc3_drm-intel-next-queued_d3b448_20140519+ x86_64) Test assertion failure function cmp_bo, file gem_seqno_wrap.c:115: Last errno: 0, Success Failed assertion: *vaddr++ == val 2: 0xfffffffe differs from assumed 0x0 seqno_before_test 0x1, approximated seqno on test fail 0x1 ==Reproduce steps== ---------------------------- 1. ./gem_seqno_wrap
Can you please make sure that this is not a regression in igt, but really a kernel regression? I.e. please downgrade igt to an older version which was known to work and retest.
This is due to rendercopy failing straight from init. And gem_seqno_wrap is leaning on that. So i expect gem_render_copy to fail also. I noticed that if I force gpu to reset itself, then after successful reset the rendercopy works as expected.
(In reply to comment #2) > This is due to rendercopy failing straight from init. And gem_seqno_wrap > is leaning on that. So i expect gem_render_copy to fail also. > > I noticed that if I force gpu to reset itself, then after successful reset > the rendercopy works as expected. Please test gem_render_copy after this gem_seqno_wrap failing. The gpu reset doesn't always fix the situation. It seems that PDPs get left sometimes to zero after init/reset.
Created attachment 99460 [details] dmesg (In reply to comment #3) > (In reply to comment #2) > > This is due to rendercopy failing straight from init. And gem_seqno_wrap > > is leaning on that. So i expect gem_render_copy to fail also. > > > > I noticed that if I force gpu to reset itself, then after successful reset > > the rendercopy works as expected. > > Please test gem_render_copy after this gem_seqno_wrap failing. > > The gpu reset doesn't always fix the situation. It seems that PDPs get left > sometimes to zero after init/reset. [root@x-bdw09 tests]# ./gem_seqno_wrap IGT-Version: 1.6-g737d248 (x86_64) (Linux: 3.15.0-rc3_drm-intel-nightly_0791a3_20140520+ x86_64) Test assertion failure function cmp_bo, file gem_seqno_wrap.c:115: Last errno: 0, Success Failed assertion: *vaddr++ == val 1: 0xfffffffc differs from assumed 0x0 seqno_before_test 0x1, approximated seqno on test fail 0x1 [root@x-bdw09 tests]# ./gem_render_copy IGT-Version: 1.6-g737d248 (x86_64) (Linux: 3.15.0-rc3_drm-intel-nightly_0791a3_20140520+ x86_64) Test assertion failure function scratch_buf_check, file gem_render_copy.c:117: Last errno: 0, Success Failed assertion: val == color Expected 0xffff00ff, found 0xfff0ff00 at (502,502) [root@x-bdw09 tests]# cat /proc/cmdline
Please test: http://patchwork.freedesktop.org/patch/26784/
Please ignore. The test stopped passing for me at some point.
Please test: IGT patch http://patchwork.freedesktop.org/patch/27088/
(In reply to comment #7) > Please test: IGT patch http://patchwork.freedesktop.org/patch/27088/ Test on latest -nightly(455a8fc4304af51a913e33763b72dd2849c11d0c) use igt with this patch. the result was pass. Output: ./gem_seqno_wrap IGT-Version: 1.6-g3c70e6a (x86_64) (Linux: 3.15.0-rc7_drm-intel-nightly_455a8f_20140603+ x86_64)
Verified on latest -nightly(8148006fc6cc97fea2b792c91c0968a038612355)
Created attachment 103570 [details] dmesg Test still failed on latest -nightly(e967a525207bd40ab446e2f809907039f88e66f3) [root@x-bdw01 tests]# ./gem_seqno_wrap IGT-Version: 1.7-gfcbc502 (x86_64) (Linux: 3.16.0-rc6_drm-intel-nightly_e967a5_20140727+ x86_64) Test assertion failure function cmp_bo, file gem_seqno_wrap.c:112: Failed assertion: *vaddr++ == val 1: 0xfffffffe differs from assumed 0x0 seqno_before_test 0x1, approximated seqno on test fail 0x1
Closing this old report in favour of the new bug 81831 so that we don't confuse the new issue with the old.
(In reply to comment #11) > Closing this old report in favour of the new bug 81831 so that we don't > confuse the new issue with the old. Verified. Thanks.
Closing verified+fixed.
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.