Created attachment 96830 [details] dmesg about some subcase of kms_flip timeout System Environment: -------------------------- Platform: BYT kernel: (drm-intel-nightly)b2f42c87ceb21108f04b17b651ad1f7c6e808f79 Bug detailed description: ---------------------------- Some subcases of igt/kms_flip timeout, and Call trace in dmesg. Subcase list: igt/kms_flip/bcs-flip-vs-panning igt/kms_flip/bcs-wf_vblank-vs-modeset-interruptible igt/kms_flip/flip-vs-modeset-interruptible igt/kms_flip/flip-vs-panning igt/kms_flip/nonexisting-fb-interruptible igt/kms_flip/rcs-wf_vblank-vs-modeset output on -nightly kernel: [root@x-byt06 tests]# ./kms_flip --run-subtest flip-vs-modeset-interruptible IGT-Version: 1.6-gb8afe98 (x86_64) (Linux: 3.14.0_drm-intel-nightly_b2f42c_20140403+ x86_64) Using monotonic timestamps Beginning flip-vs-modeset-interruptible on crtc 5, connector 23 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 . ............ Call Trace: ---------------------------- [ 301.219888] WARNING: CPU: 0 PID: 4 at drivers/gpu/drm/i915/intel_dp.c:488 intel_dp_aux_ch+0x54f/0x5ae [i915]() [ 301.219891] dp_aux_ch not started status 0xffffffff [ 301.219893] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables ipv6 dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic pcspkr serio_raw snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore battery ac acpi_cpufreq i915 video button drm_kms_helper drm [ 301.219921] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 3.14.0_drm-intel-nightly_b2f42c_20140403+ #1294 [ 301.219940] Workqueue: events i915_hotplug_work_func [i915] [ 301.219943] 0000000000000000 0000000000000009 ffffffff81717233 ffff8800767afb68 [ 301.219948] ffffffff81035052 ffffffff831bf0c0 ffffffffa00b47d1 ffffffff831bf0c0 [ 301.219953] ffff880002b798d0 ffff88000299c000 0000000000000000 00000000ffffffff [ 301.219958] Call Trace: [ 301.219965] [<ffffffff81717233>] ? dump_stack+0x41/0x51 [ 301.219970] [<ffffffff81035052>] ? warn_slowpath_common+0x73/0x8b [ 301.219990] [<ffffffffa00b47d1>] ? intel_dp_aux_ch+0x54f/0x5ae [i915] [ 301.219996] [<ffffffff81035102>] ? warn_slowpath_fmt+0x45/0x4a [ 301.220016] [<ffffffffa008f233>] ? vlv_read32+0xe3/0xee [i915] [ 301.220036] [<ffffffffa00b47d1>] ? intel_dp_aux_ch+0x54f/0x5ae [i915] [ 301.220041] [<ffffffff81713f40>] ? printk+0x4f/0x54 [ 301.220047] [<ffffffff8103cd2e>] ? lock_timer_base.isra.28+0x22/0x46 [ 301.220066] [<ffffffffa00b4933>] ? intel_dp_aux_transfer+0x103/0x10f [i915] [ 301.220071] [<ffffffff8103d0a6>] ? del_timer_sync+0x21/0x3e [ 301.220077] [<ffffffff817196b9>] ? schedule_timeout+0x151/0x16d [ 301.220084] [<ffffffffa0048a60>] ? drm_dp_dpcd_access+0x4f/0xc7 [drm_kms_helper] [ 301.220091] [<ffffffffa0048b55>] ? drm_dp_dpcd_read+0x14/0x19 [drm_kms_helper] [ 301.220111] [<ffffffffa00b2e93>] ? intel_dp_dpcd_read_wake+0x2e/0x58 [i915] [ 301.220131] [<ffffffffa00b4f70>] ? intel_dp_detect+0x183/0x280 [i915] [ 301.220150] [<ffffffffa00868e2>] ? i915_hotplug_work_func+0x209/0x2b2 [i915] [ 301.220155] [<ffffffff81046660>] ? process_one_work+0x1bc/0x2ed [ 301.220160] [<ffffffff81046bce>] ? worker_thread+0x1c7/0x2bc [ 301.220165] [<ffffffff81046a07>] ? rescuer_thread+0x251/0x251 [ 301.220170] [<ffffffff8104b53e>] ? kthread+0xc5/0xcd [ 301.220176] [<ffffffff8104b479>] ? kthread_freezable_should_stop+0x40/0x40 [ 301.220181] [<ffffffff817217fc>] ? ret_from_fork+0x7c/0xb0 [ 301.220187] [<ffffffff8104b479>] ? kthread_freezable_should_stop+0x40/0x40 [ 301.220190] ---[ end trace 49b28aaaac806e4a ]--- Reproduce steps: ---------------------------- 1. ./kms_flip --run-subtest flip-vs-modeset-interruptible
Hm, that warning is fairly old, so no idea why stuff started to go boom here. Can you please try to bisect where this regression has been introduced? Adding Jani in case it turns out to be the dp aux rework, but the only open issue we know of should result in this kind of warning.
(In reply to comment #1) > Hm, that warning is fairly old, so no idea why stuff started to go boom here. > > Can you please try to bisect where this regression has been introduced? > > Adding Jani in case it turns out to be the dp aux rework, but the only open > issue we know of should result in this kind of warning. dp_aux_ch not started status 0xffffffff and a bunch of WARNING: CPU: 0 PID: 4 at drivers/gpu/drm/i915/intel_pm.c:5652 intel_display_power_put+0x39/0xf8 [i915]() make me think this is a power domain refcounting issue. One idea for the reason is the unbalanced vdd_on/off calls we discussed and the fix would be (based on your suggestion): diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index e48d47c..c7a52d1 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -313,8 +313,12 @@ static bool edp_have_panel_vdd(struct intel_dp *intel_dp) { struct drm_device *dev = intel_dp_to_dev(intel_dp); struct drm_i915_private *dev_priv = dev->dev_private; + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + struct intel_encoder *intel_encoder = &intel_dig_port->base; + enum intel_display_power_domain power_domain; - return !dev_priv->pm.suspended && + power_domain = intel_display_port_power_domain(intel_encoder); + return intel_display_power_enabled(dev_priv, power_domain) && (I915_READ(_pp_ctrl_reg(intel_dp)) & EDP_FORCE_VDD) != 0; }
Created attachment 97125 [details] kms_flip with patch dmesg With the patch from Imre Deak, the cases are able to finished. Thanks.
Is this fixed in current drm-intel-nightly? Specifically by commit 636352173a0dd127636fe331c97b117a8004bf50 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Apr 22 19:55:42 2014 -0300 drm/i915: get power domain in case the BIOS enabled eDP VDD
(In reply to comment #4) > Is this fixed in current drm-intel-nightly? > > Specifically by > commit 636352173a0dd127636fe331c97b117a8004bf50 > Author: Paulo Zanoni <paulo.r.zanoni@intel.com> > Date: Tue Apr 22 19:55:42 2014 -0300 > > drm/i915: get power domain in case the BIOS enabled eDP VDD The test is success on latest -nightly(6c398a53417fd96d9e58bdb618e395163c81e1c4). Thanks.
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.