Created attachment 99303 [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_ring_sync_copy fails Output: ./gem_ring_sync_copy IGT-Version: 1.6-g252d115 (x86_64) (Linux: 3.15.0-rc3_drm-intel-next-queued_d3b448_20140519+ x86_64) Test assertion failure function bo_check, file gem_ring_sync_copy.c:129: Last errno: 0, Success Failed assertion: data->linear[i] == val error: 11 == 10 Subtest sync-render-blitter-write-read: FAIL Test assertion failure function bo_check, file gem_ring_sync_copy.c:129: Last errno: 0, Success Failed assertion: data->linear[i] == val error: 11 == 10 Subtest sync-render-blitter-read-write: FAIL Subtest sync-render-blitter-write-write: SUCCESS Test assertion failure function bo_check, file gem_ring_sync_copy.c:129: Last errno: 0, Success Failed assertion: data->linear[i] == val error: 12 == 10 Subtest sync-blitter-render-write-read: FAIL Subtest sync-blitter-render-read-write: SUCCESS Test assertion failure function bo_check, file gem_ring_sync_copy.c:129: Last errno: 0, Success Failed assertion: data->linear[i] == val error: 10 == 12 Subtest sync-blitter-render-write-write: FAIL ==Reproduce steps== ---------------------------- 1. ./gem_ring_sync_copy
Bug is now closed. Please bisect.
b7bb243924e9284f605368e22c3aa4ca3c980d81 is the first bad commit commit b7bb243924e9284f605368e22c3aa4ca3c980d81 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> AuthorDate: Thu May 15 20:58:11 2014 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Thu May 15 23:15:54 2014 +0200 drm/i915: Enable rc6 with bdw Everything should be in place so enable rc6/rps for bdw. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just to confirm does disabling rc6 from the kernel commandline make the problem go away?
Created attachment 100128 [details] dmesg (In reply to comment #3) > Just to confirm does disabling rc6 from the kernel commandline make the > problem go away? Add parameter "i915.i915_enable_rc6=0" in kernel commandline and run this test, the result was passed. Output: ./gem_ring_sync_copy IGT-Version: 1.6-g532b7e6 (x86_64) (Linux: 3.15.0-rc7_drm-intel-nightly_d13557_20140529+ x86_64) Subtest sync-render-blitter-write-read: SUCCESS Subtest sync-render-blitter-read-write: SUCCESS Subtest sync-render-blitter-write-write: SUCCESS Subtest sync-blitter-render-write-read: SUCCESS Subtest sync-blitter-render-read-write: SUCCESS Subtest sync-blitter-render-write-write: SUCCESS
Please test: IGT patch http://patchwork.freedesktop.org/patch/27088/
(In reply to comment #5) > 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_ring_sync_copy IGT-Version: 1.6-g3c70e6a (x86_64) (Linux: 3.15.0-rc7_drm-intel-nightly_455a8f_20140603+ x86_64) Subtest sync-render-blitter-write-read: SUCCESS Subtest sync-render-blitter-read-write: SUCCESS Subtest sync-render-blitter-write-write: SUCCESS Subtest sync-blitter-render-write-read: SUCCESS Subtest sync-blitter-render-read-write: SUCCESS Subtest sync-blitter-render-write-write: SUCCESS
Verified on latest -nightly(8148006fc6cc97fea2b792c91c0968a038612355)
Closing old 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.