Bug 70570 - [BYT] igt/kms_flip/wf_vblank-vs-modeset: WARNING: intel_dp.c: vlv_wait_port_ready(): timed out waiting for port C
Summary: [BYT] igt/kms_flip/wf_vblank-vs-modeset: WARNING: intel_dp.c: vlv_wait_port_r...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Imre Deak
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on: 73477
Blocks:
  Show dependency tree / graph
 
Reported: 2013-10-17 10:02 UTC by Guo Jinxian
Modified: 2017-10-06 14:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
dmesg (125.74 KB, text/plain)
2013-10-17 10:02 UTC, Guo Jinxian 		no flags Details
don't disable DP port during hot unplug (966 bytes, patch)
2014-01-14 09:15 UTC, Imre Deak 		no flags Details | Splinter Review
Call trace with patch (58.90 KB, text/plain)
2014-01-16 03:13 UTC, Guo Jinxian 		no flags Details
dmesg with drm.debug=0xe (124.23 KB, text/plain)
2014-01-17 04:43 UTC, Guo Jinxian 		no flags Details
dmesg with drm.debug=14 log_buf_len=16M (561.79 KB, text/plain)
2014-01-20 05:40 UTC, Guo Jinxian 		no flags Details
View All

Description Guo Jinxian 2013-10-17 10:02:47 UTC 
Created attachment 87788 [details]
dmesg

System Environment:
--------------------------
Platform: BayTrail
kernel   (drm-intel-next-queued)4cdb83ec9a72f741c75e20c8e412c505fc037f5f


Bug detailed description:
-----------------------------
Call Trace while running test igt/kms_flip/wf_vblank-vs-modeset

[  352.383853] WARNING: CPU: 0 PID: 3716 at drivers/gpu/drm/i915/intel_dp.c:2653 intel_dp_link_down+0x5b/0x18d [i915]()
[  352.383901] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables bnep bluetooth rfkill ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core ipv6 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm pcspkr snd_page_alloc serio_raw snd_timer snd soundcore battery ac acpi_cpufreq freq_table kvm_intel kvm uinput i915 drm_kms_helper drm video button dm_mirror dm_region_hash dm_log dm_mod
[  352.383905] CPU: 0 PID: 3716 Comm: kms_flip Not tainted 3.12.0-rc3_drm-intel-next-queued_4cdb83_debug_20131015_+ #941
[  352.383908] Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS BBAYCRB1.86C.0061.R22.1309171818 BBAY_IA32_R_V6122-MCU312 09/17/2013
[  352.383918]  00000000 00000000 f0dfda20 c1738317 00000000 f0dfda38 c1030b48 f8df3ba2
[  352.383927]  f71f4000 f4f1b878 f55a7800 f0dfda48 c1030b73 00000009 00000000 f0dfda68
[  352.383936]  f8df3ba2 f72b0000 00000002 300c0004 f4f1b878 00000001 00000006 f0dfda94

[  352.383938] Call Trace:
[  352.383946]  [<c1738317>] dump_stack+0x41/0x52
[  352.383954]  [<c1030b48>] warn_slowpath_common+0x66/0x7d
[  352.383988]  [<f8df3ba2>] ? intel_dp_link_down+0x5b/0x18d [i915]
[  352.383993]  [<c1030b73>] warn_slowpath_null+0x14/0x18
[  352.384027]  [<f8df3ba2>] intel_dp_link_down+0x5b/0x18d [i915]
[  352.384063]  [<f8df6945>] intel_dp_complete_link_train+0xd4/0x22e [i915]
[  352.384113]  [<f8df6b1b>] intel_enable_dp+0x68/0x73 [i915]
[  352.384148]  [<f8df6c34>] vlv_pre_enable_dp+0xf3/0x107 [i915]
[  352.384181]  [<f8de6031>] valleyview_crtc_enable+0x251/0x30f [i915]
[  352.384215]  [<f8de844e>] __intel_set_mode+0xe35/0xf1f [i915]
[  352.384221]  [<c106b6cf>] ? vprintk_emit+0x426/0x467
[  352.384227]  [<c107e69f>] ? trace_hardirqs_on_caller+0x127/0x17b
[  352.384260]  [<f8de9c6d>] intel_set_mode+0x17/0x2f [i915]
[  352.384294]  [<f8dea1ee>] intel_crtc_set_config+0x569/0x729 [i915]
[  352.384298]  [<c107e69f>] ? trace_hardirqs_on_caller+0x127/0x17b
[  352.384322]  [<f8cbcc89>] drm_mode_set_config_internal+0x3e/0x95 [drm]
[  352.384330]  [<f8d0142e>] drm_fb_helper_set_par+0x51/0x8d [drm_kms_helper]
[  352.384336]  [<c1319e09>] fb_set_var+0x29b/0x393
[  352.384343]  [<c132340a>] fbcon_blank+0x89/0x2a7
[  352.384350]  [<c136dbc2>] do_unblank_screen+0xe8/0x15c
[  352.384354]  [<c1366975>] vt_ioctl+0x4c1/0xedf
[  352.384359]  [<c13664b4>] ? complete_change_console+0xb5/0xb5
[  352.384363]  [<c135ecfc>] tty_ioctl+0x896/0x8e2
[  352.384368]  [<c135e466>] ? no_tty+0x21/0x21
[  352.384373]  [<c10fdd7c>] vfs_ioctl+0x20/0x2a
[  352.384377]  [<c10fe752>] do_vfs_ioctl+0x424/0x467
[  352.384382]  [<c107e69f>] ? trace_hardirqs_on_caller+0x127/0x17b
[  352.384386]  [<c107e6fe>] ? trace_hardirqs_on+0xb/0xd
[  352.384390]  [<c10f90ac>] ? final_putname+0x32/0x35
[  352.384394]  [<c10f90ac>] ? final_putname+0x32/0x35
[  352.384398]  [<c10f9212>] ? putname+0x23/0x2c
[  352.384402]  [<c10f0550>] ? do_sys_open+0x1b2/0x1bc
[  352.384407]  [<c10fe7e1>] SyS_ioctl+0x4c/0x73
[  352.384412]  [<c174439a>] sysenter_do_call+0x12/0x32


Reproduce steps:
----------------------------
1. ./mks_flip --run-subtest wf_vblank-vs-modeset
Comment 1 Imre Deak 2014-01-14 09:15:19 UTC 
Created attachment 92023 [details] [review]
don't disable DP port during hot unplug

I hit the same WARN by first unplugging the DP cable and then doing an xrandr --off. The problem is that that during the modeset the driver tries to disable the already disabled DP port. One solution would be to leave the port enabled during the unplug event handling and only disable it during the subsequent modeset.

The attach patch does this, could you try it?
Comment 2 Guo Jinxian 2014-01-16 03:13:35 UTC 
Created attachment 92203 [details]
Call trace with patch
Comment 3 Guo Jinxian 2014-01-16 03:14:58 UTC 
(In reply to comment #1)
> Created attachment 92023 [details] [review] [review]
> don't disable DP port during hot unplug
> 
> I hit the same WARN by first unplugging the DP cable and then doing an
> xrandr --off. The problem is that that during the modeset the driver tries
> to disable the already disabled DP port. One solution would be to leave the
> port enabled during the unplug event handling and only disable it during the
> subsequent modeset.
> 
> The attach patch does this, could you try it?

This bug still can be reproduce with the patch, please check the dmesg "Call trace with patch" for details, thanks.
Comment 4 Imre Deak 2014-01-16 15:51:49 UTC 
(In reply to comment #3)
> (In reply to comment #1)
> > Created attachment 92023 [details] [review] [review] [review]
> > don't disable DP port during hot unplug
> > 
> > I hit the same WARN by first unplugging the DP cable and then doing an
> > xrandr --off. The problem is that that during the modeset the driver tries
> > to disable the already disabled DP port. One solution would be to leave the
> > port enabled during the unplug event handling and only disable it during the
> > subsequent modeset.
> > 
> > The attach patch does this, could you try it?
> 
> This bug still can be reproduce with the patch, please check the dmesg "Call
> trace with patch" for details, thanks.

This looks like a separate issue, could you provide a dmesg with drm.debug=0xe set?
Comment 5 Guo Jinxian 2014-01-17 04:43:50 UTC 
Created attachment 92257 [details]
dmesg with drm.debug=0xe
Comment 6 Guo Jinxian 2014-01-17 04:44:24 UTC 
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Created attachment 92023 [details] [review] [review] [review] [review]
> > > don't disable DP port during hot unplug
> > > 
> > > I hit the same WARN by first unplugging the DP cable and then doing an
> > > xrandr --off. The problem is that that during the modeset the driver tries
> > > to disable the already disabled DP port. One solution would be to leave the
> > > port enabled during the unplug event handling and only disable it during the
> > > subsequent modeset.
> > > 
> > > The attach patch does this, could you try it?
> > 
> > This bug still can be reproduce with the patch, please check the dmesg "Call
> > trace with patch" for details, thanks.
> 
> This looks like a separate issue, could you provide a dmesg with
> drm.debug=0xe set?

Please check "dmesg with drm.debug=0xe" in attachment, thanks.
Comment 7 Imre Deak 2014-01-17 10:58:59 UTC 
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #1)
> > > > Created attachment 92023 [details] [review] [review] [review] [review] [review]
> > > > don't disable DP port during hot unplug
> > > > 
> > > > I hit the same WARN by first unplugging the DP cable and then doing an
> > > > xrandr --off. The problem is that that during the modeset the driver tries
> > > > to disable the already disabled DP port. One solution would be to leave the
> > > > port enabled during the unplug event handling and only disable it during the
> > > > subsequent modeset.
> > > > 
> > > > The attach patch does this, could you try it?
> > > 
> > > This bug still can be reproduce with the patch, please check the dmesg "Call
> > > trace with patch" for details, thanks.
> > 
> > This looks like a separate issue, could you provide a dmesg with
> > drm.debug=0xe set?
> 
> Please check "dmesg with drm.debug=0xe" in attachment, thanks.

Do you run the test on an external monitor or is it an embedded panel?

The beginning of the log is missing, could you boot with drm.debug=14 log_buf_len=16M and send a log including the bootup messages too?
Comment 8 Guo Jinxian 2014-01-20 05:40:38 UTC 
Created attachment 92422 [details]
dmesg with drm.debug=14 log_buf_len=16M
Comment 9 Guo Jinxian 2014-01-20 05:42:33 UTC 
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > (In reply to comment #1)
> > > > > Created attachment 92023 [details] [review] [review] [review] [review] [review] [review]
> > > > > don't disable DP port during hot unplug
> > > > > 
> > > > > I hit the same WARN by first unplugging the DP cable and then doing an
> > > > > xrandr --off. The problem is that that during the modeset the driver tries
> > > > > to disable the already disabled DP port. One solution would be to leave the
> > > > > port enabled during the unplug event handling and only disable it during the
> > > > > subsequent modeset.
> > > > > 
> > > > > The attach patch does this, could you try it?
> > > > 
> > > > This bug still can be reproduce with the patch, please check the dmesg "Call
> > > > trace with patch" for details, thanks.
> > > 
> > > This looks like a separate issue, could you provide a dmesg with
> > > drm.debug=0xe set?
> > 
> > Please check "dmesg with drm.debug=0xe" in attachment, thanks.
> 
> Do you run the test on an external monitor or is it an embedded panel?
> 
> The beginning of the log is missing, could you boot with drm.debug=14
> log_buf_len=16M and send a log including the bootup messages too?

It's an embedded panel.
Please check "dmesg with drm.debug=14 log_buf_len=16M" in attachment. Thanks.
Comment 10 Imre Deak 2014-01-20 09:50:28 UTC 
Ok, so the issue originally reported is gone now and the new warning seems to be something that got revealed. It looks similar to bug 73477, but the way to reproduce it is different, so setting that as a dependency.
Comment 11 Imre Deak 2014-02-12 12:44:12 UTC 
Could you test with the latest -nightly if this is fixed?
Comment 12 Guo Jinxian 2014-02-14 03:17:21 UTC 
(In reply to comment #11)
> Could you test with the latest -nightly if this is fixed?

Retest on latest -nightly(64fcdb139972db2663469d8799968260fb43a26d), this bug unable to reproduce.

[root@x-byt05 tests]# ./kms_flip --run-subtest wf_vblank-vs-modeset
IGT-Version: 1.5-gec3b133 (x86_64) (Linux: 3.13.0_drm-intel-nightly_64fcdb_20140214+ x86_64)
Using monotonic timestamps
Beginning wf_vblank-vs-modeset on crtc 3, connector 9
  1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
....................................................................................................................................
wf_vblank-vs-modeset on crtc 3, connector 9: PASSED

Beginning wf_vblank-vs-modeset on crtc 6, connector 9
  1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
....................................................................................................................
wf_vblank-vs-modeset on crtc 6, connector 9: PASSED

Beginning wf_vblank-vs-modeset on crtc 3, connector 20
  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x48 148500
........................................................
wf_vblank-vs-modeset on crtc 3, connector 20: PASSED

Beginning wf_vblank-vs-modeset on crtc 6, connector 20
  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x48 148500
.....................................................
wf_vblank-vs-modeset on crtc 6, connector 20: PASSED

Subtest wf_vblank-vs-modeset: SUCCESS
Comment 13 Imre Deak 2014-02-14 05:39:41 UTC 
(In reply to comment #12)
> (In reply to comment #11)
> > Could you test with the latest -nightly if this is fixed?
> 
> Retest on latest -nightly(64fcdb139972db2663469d8799968260fb43a26d), this
> bug unable to reproduce.

Thanks, closing it.
Comment 14 Guo Jinxian 2014-02-14 06:16:21 UTC 
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Could you test with the latest -nightly if this is fixed?
> > 
> > Retest on latest -nightly(64fcdb139972db2663469d8799968260fb43a26d), this
> > bug unable to reproduce.
> 
> Thanks, closing it.

Verified, thanks.
Comment 15 Elizabeth 2017-10-06 14:42:35 UTC 
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.