System Environment: -------------------------- Platform: Baytrail kernel: (drm-intel-nightly)5f7867f14f8b3688584f4bf589fe4b8aa8c718b3 Bug detailed description: --------------------------- It fails on baytrail with -nightly, -queued, -fixes kernel. It also fails on earlier igt commit and earlier queued commit. output: IGT-Version: 1.5-g72fe2b6 (x86_64) (Linux: 3.13.0-rc4_drm-intel-nightly_5f7867_20131226+ x86_64) Using monotonic timestamps kms_flip: drmtest.c:1124: igt_exit: Assertion `skipped_one || succeeded_one || failed_one' failed. Aborted (core dumped) Reproduce steps: ------------------------- 1. ./kms_flip --run-subtest --run-subtest wf_vblank-vs-dpms-interruptible
Created attachment 91317 [details] dmesg Sorry, It fails with "*ERROR* failed to train DP, aborting" not "core dumped". It randomly causes *ERROR* failed to train DP, aborting. It happens 1 in 15 runs. output: IGT-Version: 1.5-g72fe2b6 (x86_64) (Linux: 3.13.0-rc4_drm-intel-nightly_5f7867_20131230+ x86_64) Using monotonic timestamps Beginning wf_vblank-vs-dpms-interruptible on crtc 3, connector 20 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ................... wf_vblank-vs-dpms-interruptible on crtc 3, connector 20: PASSED Beginning wf_vblank-vs-dpms-interruptible on crtc 6, connector 20 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ..... wf_vblank-vs-dpms-interruptible on crtc 6, connector 20: PASSED Subtest wf_vblank-vs-dpms-interruptible: SUCCESS Call trace [ 324.889970] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 324.889976] [drm:intel_dp_link_down], [ 324.941966] [drm:g4x_wait_for_vblank], vblank wait timed out [ 324.993102] [drm:valleyview_irq_handler], hotplug event received, stat 0x10000020 [ 326.005962] ------------[ cut here ]------------ [ 326.005992] WARNING: CPU: 0 PID: 3924 at drivers/gpu/drm/i915/intel_display.c:1535 vlv_pre_enable_dp+0x109/0x118 [i915]() [ 326.005996] timed out waiting for port C ready: 0x000000ff [ 326.005998] Modules linked in: ip6table_filter ip6_tables ipv6 iptable_filter ip_tables ebtable_nat ebtables x_tables dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek pcspkr s nd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore battery ac acpi_cpufreq i915 video button drm_kms_helper drm [ 326.006026] CPU: 0 PID: 3924 Comm: kms_flip Tainted: G W 3.13.0-rc4_drm-intel-nightly_5f7867_20131230+ #42 [ 326.006029] 0000000000000000 0000000000000009 ffffffff81711fd2 ffff8800025e7c08 [ 326.006034] ffffffff8103312a 0000000000000286 ffffffffa009977b dead000000200200 [ 326.006039] ffff880002a0c000 0000000000000001 ffff880002949800 0000000000000200 [ 326.006044] Call Trace: [ 326.006061] [<ffffffff81711fd2>] ? dump_stack+0x41/0x51 [ 326.006069] [<ffffffff8103312a>] ? warn_slowpath_common+0x73/0x8b [ 326.006091] [<ffffffffa009977b>] ? vlv_pre_enable_dp+0x109/0x118 [i915] [ 326.006096] [<ffffffff810331da>] ? warn_slowpath_fmt+0x45/0x4a [ 326.006114] [<ffffffffa00821c3>] ? vlv_wait_port_ready+0xcb/0x104 [i915] [ 326.006132] [<ffffffffa009977b>] ? vlv_pre_enable_dp+0x109/0x118 [i915] [ 326.006150] [<ffffffffa00861bb>] ? valleyview_crtc_enable+0x298/0x375 [i915] [ 326.006167] [<ffffffffa00878dd>] ? intel_crtc_update_dpms+0x4f/0x66 [i915] [ 326.006193] [<ffffffffa008b3c1>] ? intel_connector_dpms+0x3f/0x4a [i915] [ 326.006205] [<ffffffffa000fbcb>] ? drm_mode_obj_set_property_ioctl+0x15c/0x1e6 [drm] [ 326.006216] [<ffffffffa000fc81>] ? drm_mode_connector_property_set_ioctl+0x2c/0x31 [drm] [ 326.006226] [<ffffffffa0002f37>] ? drm_ioctl+0x263/0x385 [drm] [ 326.006236] [<ffffffffa000fc55>] ? drm_mode_obj_set_property_ioctl+0x1e6/0x1e6 [drm] [ 326.006243] [<ffffffff8108ec07>] ? __audit_syscall_exit+0x209/0x225 [ 326.006248] [<ffffffff810360fd>] ? timespec_add_safe+0x1e/0x4d [ 326.006254] [<ffffffff810e90e8>] ? do_vfs_ioctl+0x3f1/0x43a [ 326.006258] [<ffffffff810e917f>] ? SyS_ioctl+0x4e/0x7b [ 326.006264] [<ffffffff8171c5e2>] ? system_call_fastpath+0x16/0x1b [ 326.006267] ---[ end trace e75f891d266e7a18 ]--- Reproduce steps: ------------------------- 1. ./kms_flip --run-subtest wf_vblank-vs-dpms-interruptible
Many kms_flip subcases randomly fail with *ERROR* failed to train DP, aborting" not "core dumped on Baytrail.
this bug need to be triaged.
Could you try the patch at http://lists.freedesktop.org/archives/intel-gfx/2014-January/039252.html ?
(In reply to comment #4) > Could you try the patch at > http://lists.freedesktop.org/archives/intel-gfx/2014-January/039252.html ? Sorry you have an eDP panel, so it's a separate issue.
Does this still occur with current bits? Quite a few changes to the DP code have landed recently...
(In reply to comment #6) > Does this still occur with current bits? Quite a few changes to the DP code > have landed recently... Test on latest igt and -nightly kernel. It works well. Close it.
Verified.Fixed.
Sorry, Reopen it. run ./kms_flip --run-subtest wf_vblank-vs-dpms-interruptible, this error goes away. run ./kms_flip --run-subtest absolute-wf_vblank-interruptible, it still has this issue. output: IGT-Version: 1.5-g81ade89 (x86_64) (Linux: 3.13.0_drm-intel-nightly_1be8f2_20140226+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 3, connector 20 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 3, connector 20: PASSED Beginning absolute-wf_vblank-interruptible on crtc 6, connector 20 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 6, connector 20: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS dmesg -r | egrep "<[1-3]>" |grep drm <3>[ 346.945826] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training <3>[ 348.046878] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting <3>[ 349.065782] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun <3>[ 349.068277] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0)
Created attachment 94745 [details] dmesg
I think Todd has been buried in this area recently. Maybe applying some of the mode set sequence changes will help here...
Todd, can you reproduce this?
Sure, I'll see what I can do.
From the log on 2/26, it looks like the AUX write is failing at the beginning of link training. So the sink device wouldn't be aware that the source device was attempting to train it. >>[ 346.929303] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x70150064 It's unclear why we try to continue link training when clearly the sink device hasn't responded. I'll see if I can track this down on a ByT here in Oregon since mine doesn't have the eDP display on it. -T
Up the priority because almost every subcase of Kms_flip will have this issue randomly, caused lots of failure in nightly and hard for us to analysis the result. If the randomly failure occur one day and disappear the next day, then occur again. Our guys feel so confused for such a ugly behavior.
On my ByT system I can't reproduce this with an external display. I just acquired a ByT system with an eDP panel on it, so when that arrives, I'll see if I can reproduce it. It looks like the call trace is the result of intel_dp_set_link_train() failing. I'll be able to figure out more when I can reproduce this issue on the inbound ByT system.
I can unreliably reproduce this problem as well on the ByT system I received last week (It occurred once in approximately runs). It looks like something is going wrong in the panel power up sequence such that the sink is unresponsive. I'll dig into it more and see if I can figure out what's going wrong.
(In reply to comment #17) > I can unreliably reproduce this problem as well on the ByT system I received > last week (It occurred once in approximately runs). It looks like something > is going wrong in the panel power up sequence such that the sink is > unresponsive. I'll dig into it more and see if I can figure out what's going > wrong. Good news, Todd, this issue blocked QA hardly, so if you have any updates or fixed patch, feel free to ping QA and add comments to this bug.
phy reset might help, please retest with latest drm-intel-nightly.
Run ./kms_flip --run-subtest absolute-wf_vblank-interruptible 15 cycles on latest -nightly kernel, It works well. I will check all kms_flip subcases, If they all work well, I will close it.
Created attachment 101717 [details] dmesg It still happens on latest -nightly kernel. # ./kms_flip IGT-Version: 1.7-gfedb9b6 (x86_64) (Linux: 3.16.0-rc2_drm-intel-nightly_891f8a_20140625+ x86_64) Using monotonic timestamps Beginning wf_vblank on crtc 6, connector 25 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 .......................................................................................... wf_vblank on crtc 6, connector 25: PASSED Beginning wf_vblank on crtc 11, connector 25 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ......................................................................^C # dmesg -r | egrep "<[1-3]>" |grep drm <3>[ 94.616157] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training <3>[ 95.504899] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting <3>[ 95.507159] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 95.507835] [drm:i9xx_set_fifo_underrun_reporting] *ERROR* pipe B underrun <3>[ 95.507839] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe B underrun <3>[ 107.666500] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training <3>[ 108.789734] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting <3>[ 109.794928] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 109.795557] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun
So this: [ 94.380058] [drm:_edp_panel_vdd_on] PP_STATUS: 0x00000000 PP_CONTROL: 0xabcd0008 [ 94.380061] [drm:_edp_panel_vdd_on] eDP was not running [ 94.584341] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.588878] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.592886] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.596936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.599478] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.613493] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 94.616148] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 [ 94.616157] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training shows that we're trying to train the link when the sink isn't ready. The timeout status for the AUX transactions is expected in this case. Further down in the log is this: [ 94.904063] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 94.904882] ------------[ cut here ]------------ [ 94.904914] WARNING: CPU: 0 PID: 4020 at drivers/gpu/drm/i915/intel_dp.c:3170 intel_dp_complete_link_train+0x100/0x27f [i915]() caused by calling intel_dp_complete_link_train() when DP has not been enabled in the first place. Which makes sense considering the previous failure to begin link training. I believe the root cause of this is that we're continuing the training process even though previous, required steps have failed. I think I can clean this up with a little bit of rework to the link training functions and how they're called.
In plenty of cases we go on regardless of errors because sometimes it will work anyway, and we can avoid a black screen.
Created attachment 102179 [details] dmesg(patch) Applay Todd's patch. root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./kms_flip --run-subtest absolute-wf_vblank-interruptible IGT-Version: 1.7-g67e29a3 (x86_64) (Linux: 3.16.0-rc2_kcloud_dc05ed_20140703+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 6, connector 25 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 6, connector 25: PASSED Beginning absolute-wf_vblank-interruptible on crtc 11, connector 25 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ................................................................................................................................................................................ absolute-wf_vblank-interruptible on crtc 11, connector 25: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# dmesg -r | egrep "<[1-3]>" |grep drm <3>[ 66.649840] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 66.657152] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe B underrun <3>[ 83.791251] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 83.791896] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun
Created attachment 102863 [details] Patch for link training
Created attachment 102864 [details] Patch for check_link_status()
Interesting. That's similar behavior to what I saw when the PHYs weren't coming up on VLV. I'd like to see the results of the two patches I've attached. The first one is an updated, cleaned up version of the patch I sent previously. The second one changes check_link_status() such that we don't try and configure the link when it's in a disconnected state. Please apply, test and post the results. -T
(In reply to comment #27) > Interesting. That's similar behavior to what I saw when the PHYs weren't > coming up on VLV. I'd like to see the results of the two patches I've > attached. The first one is an updated, cleaned up version of the patch I > sent previously. The second one changes check_link_status() such that we > don't try and configure the link when it's in a disconnected state. > > Please apply, test and post the results. > > -T Apply these 2 patches, run ./kms_flip --run-subtest absolute-wf_vblank-interruptible crash due to bug 81320. ./kms_flip --run-subtest absolute-wf_vblank-interruptible output: IGT-Version: 1.7-g428060c (x86_64) (Linux: 3.16.0-rc5_kcloud_1f014f_20140717+ x86_64) Using monotonic timestamps Test assertion failure function igt_install_exit_handler, file igt_core.c:1086: Failed assertion: exit_handler_count < MAX_EXIT_HANDLERS kms_flip: igt_core.c:657: igt_fail: Assertion `!test_with_subtests || in_fixture' failed. Aborted
Created attachment 102963 [details] dmesg Apply these 2 patches and test it on igt commit b6ed9fb0d9a68. Run 4 cycles, "*ERROR* failed to train DP, aborting" doesn't appear. But reports "*ERROR* mismatch in has_dp_encoder (expected 1, found 0)". root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools# dmesg -r | egrep "<[1-3]>" |grep drm <3>[ 182.656611] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 182.663755] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun <3>[ 221.645594] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 221.652742] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun output root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./kms_flip --run-subtest absolute-wf_vblank-interruptible IGT-Version: 1.7-gb6ed9fb (x86_64) (Linux: 3.16.0-rc5_kcloud_1f014f_20140717+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 7, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 7, connector 27: PASSED Beginning absolute-wf_vblank-interruptible on crtc 12, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 12, connector 27: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./kms_flip --run-subtest absolute-wf_vblank-interruptible IGT-Version: 1.7-gb6ed9fb (x86_64) (Linux: 3.16.0-rc5_kcloud_1f014f_20140717+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 7, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ................................................................................................................................................................................ absolute-wf_vblank-interruptible on crtc 7, connector 27: PASSED Beginning absolute-wf_vblank-interruptible on crtc 12, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 12, connector 27: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./kms_flip --run-subtest absolute-wf_vblank-interruptible IGT-Version: 1.7-gb6ed9fb (x86_64) (Linux: 3.16.0-rc5_kcloud_1f014f_20140717+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 7, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ................................................................................................................................................................................ absolute-wf_vblank-interruptible on crtc 7, connector 27: PASSED Beginning absolute-wf_vblank-interruptible on crtc 12, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 12, connector 27: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS root@x-byt06:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./kms_flip --run-subtest absolute-wf_vblank-interruptible IGT-Version: 1.7-gb6ed9fb (x86_64) (Linux: 3.16.0-rc5_kcloud_1f014f_20140717+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 7, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ................................................................................................................................................................................ absolute-wf_vblank-interruptible on crtc 7, connector 27: PASSED Beginning absolute-wf_vblank-interruptible on crtc 12, connector 27 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 ........................................................................................... absolute-wf_vblank-interruptible on crtc 12, connector 27: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS
From the update here, it appears that the tests are passing but there are still errors in the log. Looking over the log, it seems like the eDP panel isn't coming up fast enough and the driver is trying to train the panel before it's ready. That seems to be what causes the out-of-sync issues between the driver and the hardware. That might be fixable by preventing the start of link training until the panel is fully running and putting some checks in the code to verify the responses received. -T
I think I need some clarification here. According to the log posted 17JULY, the tests appear to be passing. Yet this bug is still flagged as a highest priority, blocking bug. That does not seem accurate to me. The WARNs and errors that are presenting now are quite different and arguably less severe than those of the original problem (which was "*ERROR* failed to train DP, aborting"). How is this still highest priority and blocking?
(In reply to comment #31) > I think I need some clarification here. According to the log posted 17JULY, > the tests appear to be passing. Yet this bug is still flagged as a highest > priority, blocking bug. That does not seem accurate to me. The WARNs and > errors that are presenting now are quite different and arguably less severe > than those of the original problem (which was "*ERROR* failed to train DP, > aborting"). How is this still highest priority and blocking? Comment 29's result is from testing patches, are they merged into nightly? Bug 81662 blocks testing on latest nightly kernel. If "*ERROR* failed to train DP, aborting" goes away, we will close this bug.
Sounds good. No they are not integrated yet. Review feedback from the mailing list indicates some work is necessary to get those patches cleaned up and ready for submission outside of their original context.
It still happens on latest -nightly kernel. run ./kms_flip --run-subtest absolute-wf_vblank-interruptible output: IGT-Version: 1.7-gd0a41b4 (x86_64) (Linux: 3.17.0-rc2_drm-intel-nightly_519a43_20140829+ x86_64) Using monotonic timestamps Beginning absolute-wf_vblank-interruptible on crtc 8, connector 28 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 .............................................. absolute-wf_vblank-interruptible on crtc 8, connector 28: PASSED Beginning absolute-wf_vblank-interruptible on crtc 13, connector 28 1920x1080 60 1920 1966 1996 2080 1080 1082 1086 1112 0xa 0x48 138780 .............................................. absolute-wf_vblank-interruptible on crtc 13, connector 28: PASSED Beginning absolute-wf_vblank-interruptible on crtc 8, connector 16 1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000 .............................................. absolute-wf_vblank-interruptible on crtc 8, connector 16: PASSED Beginning absolute-wf_vblank-interruptible on crtc 13, connector 16 1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000 .............................................. absolute-wf_vblank-interruptible on crtc 13, connector 16: PASSED Subtest absolute-wf_vblank-interruptible: SUCCESS # dmesg -r|egrep "<[1-3]>"|grep drm <3>[ 235.727747] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training <3>[ 236.630574] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting <3>[ 236.632712] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 236.633414] [drm:i9xx_set_fifo_underrun_reporting] *ERROR* pipe B underrun <3>[ 236.633418] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe B underrun <3>[ 261.291479] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training <3>[ 262.176234] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting <3>[ 263.181448] [drm:intel_pipe_config_compare] *ERROR* mismatch in has_dp_encoder (expected 1, found 0) <3>[ 263.182083] [drm:i9xx_set_fifo_underrun_reporting] *ERROR* pipe A underrun <3>[ 263.182085] [drm:valleyview_pipestat_irq_handler] *ERROR* pipe A underrun
*** Bug 80701 has been marked as a duplicate of this bug. ***
Test on latest -nightly kernel, many kms_flip sub cases randomly has this issue: igt/kms_flip/bcs-flip-vs-modeset igt/kms_flip/bcs-flip-vs-modeset-interruptible igt/kms_flip/bcs-wf_vblank-vs-dpms igt/kms_flip/bcs-wf_vblank-vs-dpms-interruptible igt/kms_flip/bcs-wf_vblank-vs-modeset igt/kms_flip/bcs-wf_vblank-vs-modeset-interruptible igt/kms_flip/bo-too-big igt/kms_flip/bo-too-big-interruptible igt/kms_flip/flip-vs-dpms-off-vs-modeset igt/kms_flip/flip-vs-dpms-off-vs-modeset-interruptible igt/kms_flip/flip-vs-expired-vblank igt/kms_flip/rcs-flip-vs-dpms igt/kms_flip/rcs-flip-vs-dpms-interruptible igt/kms_flip/rcs-flip-vs-modeset igt/kms_flip/rcs-flip-vs-modeset-interruptible igt/kms_flip/rcs-flip-vs-panning igt/kms_flip/rcs-flip-vs-panning-interruptible igt/kms_flip/rcs-wf_vblank-vs-dpms igt/kms_flip/rcs-wf_vblank-vs-dpms-interruptible igt/kms_flip/rcs-wf_vblank-vs-modeset igt/kms_flip/rcs-wf_vblank-vs-modeset-interruptible run ./kms_flip --run-subtest bcs-flip-vs-modeset dmesg: [ 1275.022998] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 1276.056699] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off [ 1276.056707] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd0003 [ 1276.073848] ------------[ cut here ]------------ [ 1276.073887] WARNING: CPU: 1 PID: 5003 at drivers/gpu/drm/i915/intel_display.c:1748 valleyview_crtc_enable+0x9cb/0xad2 [i915]() [ 1276.073891] timed out waiting for port C ready: 0x0000201f [ 1276.073893] Modules linked in: dm_mod snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_codec_generic pcspkr r8169 snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 snd_hwdep lpc_ich snd_pcm mfd_core snd_timer snd soundcore iosf_mbi battery wmi ac acpi_cpufreq uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev i915 button video drm_kms_helper drm cfbfillrect cfbimgblt cfbcopyarea [ 1276.073933] CPU: 1 PID: 5003 Comm: kms_flip Not tainted 3.17.0_drm-intel-nightly_ea4bec_20141009+ #326 [ 1276.073937] 0000000000000000 0000000000000009 ffffffff8178032c ffff880002bbbab8 [ 1276.073942] ffffffff8103a8ec dead000000200200 ffffffffa00c9725 0000000000000246 [ 1276.073948] ffff8800791a8000 0000000000186018 ffff88017a45db30 00000000f0006000 [ 1276.073953] Call Trace: [ 1276.073964] [<ffffffff8178032c>] ? dump_stack+0x41/0x51 [ 1276.073972] [<ffffffff8103a8ec>] ? warn_slowpath_common+0x78/0x90 [ 1276.073999] [<ffffffffa00c9725>] ? valleyview_crtc_enable+0x9cb/0xad2 [i915] [ 1276.074005] [<ffffffff8103a99c>] ? warn_slowpath_fmt+0x45/0x4a [ 1276.074032] [<ffffffffa00c4af0>] ? vlv_wait_port_ready+0xdc/0x114 [i915] [ 1276.074059] [<ffffffffa00c9725>] ? valleyview_crtc_enable+0x9cb/0xad2 [i915] [ 1276.074086] [<ffffffffa00cc182>] ? __intel_set_mode+0x1115/0x121d [i915] [ 1276.074092] [<ffffffff8177d404>] ? printk+0x4f/0x54 [ 1276.074119] [<ffffffffa00ce448>] ? intel_set_mode+0xd/0x27 [i915] [ 1276.074147] [<ffffffffa00cf05b>] ? intel_crtc_set_config+0x757/0xa99 [i915] [ 1276.074163] [<ffffffffa0017fe9>] ? drm_mode_set_config_internal+0x48/0xbd [drm] [ 1276.074176] [<ffffffffa001ba12>] ? drm_mode_setcrtc+0x3e6/0x48b [drm] [ 1276.074188] [<ffffffffa0010760>] ? drm_ioctl+0x279/0x3bc [drm] [ 1276.074202] [<ffffffffa001b62c>] ? drm_mode_setplane+0x1ce/0x1ce [drm] [ 1276.074208] [<ffffffff81108374>] ? kmem_cache_free+0xf7/0x135 [ 1276.074215] [<ffffffff8111cda3>] ? do_vfs_ioctl+0x3ec/0x435 [ 1276.074221] [<ffffffff8104e66d>] ? task_work_run+0x78/0x87 [ 1276.074226] [<ffffffff8111ce35>] ? SyS_ioctl+0x49/0x78 [ 1276.074232] [<ffffffff8178601a>] ? int_signal+0x12/0x17 [ 1276.074237] [<ffffffff81785d92>] ? system_call_fastpath+0x16/0x1b [ 1276.074241] ---[ end trace d5b4ab87e33aca0d ]--- Increasing priority, It impacts so many sub cases and the result is unstable.
Test on latest -nightly kernel, kms_flip, kms_mmio_vs_cs_flip, kms_flip_event_leak, kms_plane and kms_rotation_crc subcases randomly have this issue, it impacts 100+ sub cases. It's difficult to track test result.
Can you retest with the latest nightly now that all the pps fixes have gone in? In addition you may want to test this patch: http://patchwork.freedesktop.org/patch/37945/ It should eliminate all self inflicted link training failures, but it may make some tests fail outright since the kernel will reject the invalid connector combination instead of pretending that it's supported.
(In reply to Ville Syrjala from comment #38) > Can you retest with the latest nightly now that all the pps fixes have gone > in? > > In addition you may want to test this patch: > http://patchwork.freedesktop.org/patch/37945/ > It should eliminate all self inflicted link training failures, but it may > make some tests fail outright since the kernel will reject the invalid > connector combination instead of pretending that it's supported. Run kms_flip on latest -nightly kernel, execute about 80 subcases. I don't meet this error, some subcases have "[ 5086.662683] [drm:__vlv_force_wake_get [i915]] *ERROR* Timed out: waiting for Render to ack." Run kms_plane 5 cycles, this error doesn't exist.
Run on cycle full igt, this issue goes away. Close it.
Closing 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.