Created attachment 90289 [details] dmesg System Environment: -------------------------- Platform: BYT kernel: (drm-intel-nightly)ddd0a9e2da6087c7aac74aca34fcdc90645cbdb4 Bug detailed description: ------------------------- It fails on BYT with -nightly and -fixes kernel, It works well on -queued kernel. igt/drv_suspend/fence-restore-untiled also fails. The latest known bad commit: 5ae68b413214e847a2b5c6d3c65778482542bc1 The latest known good commit: 1fbc0d789d12fec313c91912fc11733fdfbab863 output: rtcwake: wakeup from "mem" using /dev/rtc0 at Mon Jan 1 03:57:15 2001 checking the first canary object Test assertion failure function test_fence_restore, file drv_suspend.c:83: Failed assertion: ptr1[i] == i Subtest fence-restore-tiled2untiled: FAIL Reproduce steps: ---------------------------- 1. ./drv_suspend --run-subtest fence-restore-tiled2untiled
Can you please try to bisect where this regression has been introduced?
I will bisect it.
Bisect shows:f69e515699d8e9b1c25dcfe1c4c6f435087495d2 is the first bad commit commit f69e515699d8e9b1c25dcfe1c4c6f435087495d2 Author: Duncan Laurie <dlaurie@chromium.org> Date: Wed Nov 13 17:59:43 2013 -0800 i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7 We had been using a DMI table workaround to select the right frequency for devices, but this is fragile and must be updated with every new platform. Instead the default case when VBT is missing is changed to use 120MHz clock for LVDS SSC for these generations. The docs for 2010-Core, SandyBridge, and IvyBridge all indicate that the reference frequency for LVDS is 120MHz: "2010 Core" http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf page 38 Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. "2011 SandyBridge" http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf page 33 Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. "2012 IvyBridge" http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf page 27 Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> [olof: Fixup for recent base, switched from if/else to single call] Signed-off-by: Olof Johansson <olof@lixom.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can you please double-check this bisect by reverting the offending commit on top of latest -nightly? There shouldn't be any way that this commit can affect suspend/resume on byt.
I bisect it again, bisect shows:7bd40c16ccb2cb6877dd00b0e66249c171e6fa43 is the first bad commit. Revert this commit, It still fails. commit 7bd40c16ccb2cb6877dd00b0e66249c171e6fa43 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Nov 12 10:17:39 2013 -0800 x86/early quirk: use gen6 stolen detection for VLV We've always been able to use either method on VLV, but it appears more recent BIOSes only support the gen6 method, so switch over to that. References: https://bugs.freedesktop.org/show_bug.cgi?id=71370 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same bisect, it just looks like we have corruption elseplaces, not just in the scanout. *** This bug has been marked as a duplicate of bug 71908 ***
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.