Created attachment 104200 [details] dmesg ==System Environment== -------------------------- Regression: Yes. Good commit on -next-queued: 27b6c122512ca30399bb1b39cc42eda83901f304(the result was skip) Non-working platforms: PNV ==kernel== -------------------------- origin/drm-intel-nightly: 5a299a5a794999ddcc44578c0cfd58da83bac62b(timeout) drm-intel-nightly: 2014y-08m-06d-22h-47m-43s integration manifest origin/drm-intel-next-queued: 290a60e8b9bc9174abef251ca5498ba725c61859(timeout) drm/i915: Round-up clock and limit drain latency origin/drm-intel-fixes: 96d56d71a3bcd0a0015034a8f3decc46cb9ec855(timeout) drm/i915: Fix crash when failing to parse MIPI VBT ==Bug detailed description== igt/kms_universal_plane/universal-plane-pipe-A-functional tests timeout Output: [root@x-pnv2 tests]# ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.7-gac31f19 (i686) (Linux: 3.16.0_drm-intel-next-queued_290a60_20140807+ i686) Testing connector LVDS-1 using pipe A Subtest universal-plane-pipe-A-functional: TIMEOUT ==Reproduce steps== ---------------------------- 1. ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional
This bug is able to reproduce on latest -nightly() on HSW [root@x-hsw24 tests]# ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.7-g50166d2 (x86_64) (Linux: 3.17.0-rc2_drm-intel-nightly_e91331_20140828+ x86_64) Testing connector VGA-1 using pipe A Subtest universal-plane-pipe-A-functional: TIMEOUT
This failure is able to reproduce on BSW on latest -nightly(4144c90b76dfe6eaa2205ac947090786b5091cff) [root@x-bsw01 tests]# time ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.7-g0818875 (x86_64) (Linux: 3.17.0-rc2_drm-intel-nightly_4144c9_20140904+ x86_64) Testing connector eDP-1 using pipe A Subtest universal-plane-pipe-A-functional: TIMEOUT
ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a is the first bad commit. It is a mergence commit. it's parents c7dbc6c fails(not timeout), it's another parents 3488229 skips commit ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a Merge: c7dbc6c 3488229 Author: Dave Airlie <airlied@redhat.com> AuthorDate: Wed Jul 9 10:38:42 2014 +1000 Commit: Dave Airlie <airlied@redhat.com> CommitDate: Wed Jul 9 10:38:42 2014 +1000 Merge tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel into drm-next - Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and flip events. This is prep work for proper PSR support and should also be useful for DRRS&fbc. - Runtime suspend hardware on system suspend to support the new SOix sleep states, from Jesse. - PSR updates for broadwell (Rodrigo) - Universal plane support for cursors (Matt Roper), including core drm patches. - Prefault gtt mappings (Chris) - baytrail write-enable pte bit support (Akash Goel) - mmio based flips (Sourab Gupta) instead of blitter ring flips - interrupt handling race fixes (Oscar Mateo) And old, not yet merged features from the previous round: - rps/turbo support for chv (Deepak) - some other straggling chv patches (Ville) - proper universal plane conversion for the primary plane (Matt Roper) - ppgtt on vlv from Jesse - pile of cleanups, little fixes for insane corner cases and improved debug support all over * tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits) drm/i915: Update DRIVER_DATE to 20140620 drivers/i915: Fix unnoticed failure of init_ring_common() drm/i915: Track frontbuffer invalidation/flushing drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: don't take runtime PM reference around freeze/thaw drm/i915: use runtime irq suspend/resume in freeze/thaw drm/i915: Properly track domain of the fbcon fb drm/i915: Print obj->frontbuffer_bits in debugfs output drm/i915: Introduce accurate frontbuffer tracking drm/i915: Drop schedule_back from psr_exit drm/i915: Ditch intel_edp_psr_update drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Remove ctx->last_ring drm/i915/chv: Ack interrupts before handling them (CHV) drm/i915/bdw: Ack interrupts before handling them (GEN8) drm/i915/vlv: Ack interrupts before handling them (VLV) drm/i915: Ack interrupts before handling them (GEN5 - GEN7) drm/i915: Don't BUG_ON in i915_gem_obj_offset drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info drm/i915: Add some L3 registers to the parser whitelist ... Conflicts: drivers/gpu/drm/i915/i915_drv.c [root@x-pnv2 tests]# ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.8-ga973aab (i686) (Linux: 3.16.0-rc4_glody_c7dbc6_20141106+ i686) Test assertion failure function igt_display_init, file igt_kms.c:995: Failed assertion: pipe->planes[IGT_PLANE_PRIMARY].drm_plane && pipe->planes[IGT_PLANE_CURSOR].drm_plane Subtest universal-plane-pipe-A-functional: FAIL [root@x-pnv2 tests]# ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.8-ga973aab (i686) (Linux: 3.15.0-rc8_glody_348822_20141106+ i686) Test requirement not met in function __real_main556, file kms_universal_plane.c:570: Test requirement: data.display.has_universal_planes Last errno: 22, Invalid argument Subtest universal-plane-pipe-A-functional: SKIP
Guo, can you please retest? We've merged a few patches meanwhile. Matt, can you please point Guo at a branch with your latest pile of universal plane fixes if -nightly is still broken?
(In reply to Daniel Vetter from comment #4) > Guo, can you please retest? We've merged a few patches meanwhile. > > Matt, can you please point Guo at a branch with your latest pile of > universal plane fixes if -nightly is still broken? Yeah, I don't see any obvious red flags in the dmesg (aside from 5 seconds between starting and stopping CRC collection), so I'm not sure if this will be helped by any of the patches I've recently written or not. If it does still occur with latest di-nightly, you can also try using branch "forupstream/display-refactor-v3" from the repo at https://github.com/mattrope/kernel.git , although I'm not sure whether anything in there will help or not.
(In reply to Matt Roper from comment #5) > (In reply to Daniel Vetter from comment #4) > > Guo, can you please retest? We've merged a few patches meanwhile. > > > > Matt, can you please point Guo at a branch with your latest pile of > > universal plane fixes if -nightly is still broken? > > Yeah, I don't see any obvious red flags in the dmesg (aside from 5 seconds > between starting and stopping CRC collection), so I'm not sure if this will > be helped by any of the patches I've recently written or not. > > If it does still occur with latest di-nightly, you can also try using branch > "forupstream/display-refactor-v3" from the repo at > https://github.com/mattrope/kernel.git , although I'm not sure whether > anything in there will help or not. Test still timeout on this tree [root@x-pnv2 tests]# ./kms_universal_plane --run-subtest universal-plane-pipe-A-functional IGT-Version: 1.8-gd807891 (i686) (Linux: 3.18.0-rc6_glody_7d9306_20141125+ i686) Testing connector LVDS-1 using pipe A Subtest universal-plane-pipe-A-functional: TIMEOUT (5.084s) commit: commit 7d93064ed0238483385721930df71c3561f43fd5 Author: Matt Roper <matthew.d.roper@intel.com> Date: Fri Nov 21 15:52:28 2014 -0800 drm/i915: Make all plane disables use 'update_plane' If we extend the commit_plane handlers for each plane type to be able to handle fb=0, then we can easily implement plane disable via the update_plane handler. The cursor plane already works this way, and this is the direction we need to go to integrate with the atomic plane handler. We can now kill off the type-specific disable functions, as well as the redundant intel_plane_disable() (not to be confused with intel_disable_plane()). Note that prepare_plane_fb() only gets called as part of update_plane when fb!=NULL (by design, to match the semantics of the atomic plane helpers); this means that our commit_plane handlers need to handle the frontbuffer tracking for the disable case, even though they don't handle it for normal updates. Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Does this bug still occur? A lot of the relevant display code has been ripped out and replaced since this bug was first reported, so I'm hoping that it's been magically fixed (I've never been able to reproduce this myself).
(In reply to Matt Roper from comment #7) > Does this bug still occur? A lot of the relevant display code has been > ripped out and replaced since this bug was first reported, so I'm hoping > that it's been magically fixed (I've never been able to reproduce this > myself). This case no longer time out, but it will fail. I had already add bug 89331 to track the new issue. Change this bug state to verified.
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.