* [PATCH] drm/i915: Lock signaler timeline while navigating @ 2019-09-17 7:43 Chris Wilson 2019-09-17 8:15 ` ✓ Fi.CI.BAT: success for " Patchwork ` (6 more replies) 0 siblings, 7 replies; 14+ messages in thread From: Chris Wilson @ 2019-09-17 7:43 UTC (permalink / raw) To: intel-gfx As we need to take a walk back along the signaler timeline to find the fence before upon which we want to wait, we need to lock that timeline to prevent it being modified as we walk. Similarly, we also need to acquire a reference to the earlier fence while it still exists! Though we lack the correct locking today, we are saved by the overarching struct_mutex -- but that protection is being removed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index f12358150097..452ad7a8ff0c 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce) static int i915_request_await_start(struct i915_request *rq, struct i915_request *signal) { - if (list_is_first(&signal->link, &signal->timeline->requests)) + struct intel_timeline *tl = signal->timeline; + struct dma_fence *fence; + int err; + + if (list_is_first(&signal->link, &tl->requests)) return 0; - signal = list_prev_entry(signal, link); - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) + return -EINTR; + + if (list_is_first(&signal->link, &tl->requests)) { + fence = NULL; + } else { + signal = list_prev_entry(signal, link); + fence = dma_fence_get_rcu(&signal->fence); + } + mutex_unlock(&tl->mutex); + if (!fence) return 0; - return i915_sw_fence_await_dma_fence(&rq->submit, - &signal->fence, 0, - I915_FENCE_GFP); + err = 0; + if (!intel_timeline_sync_is_later(rq->timeline, fence)) + err = i915_sw_fence_await_dma_fence(&rq->submit, + fence, 0, + I915_FENCE_GFP); + dma_fence_put(fence); + + return err; } static intel_engine_mask_t -- 2.23.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson @ 2019-09-17 8:15 ` Patchwork 2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork ` (5 subsequent siblings) 6 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2019-09-17 8:15 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: drm/i915: Lock signaler timeline while navigating URL : https://patchwork.freedesktop.org/series/66799/ State : success == Summary == CI Bug Log - changes from CI_DRM_6906 -> Patchwork_14426 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/ Known issues ------------ Here are the changes found in Patchwork_14426 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_mmap_gtt@basic-write: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@gem_mmap_gtt@basic-write.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@gem_mmap_gtt@basic-write.html * igt@i915_module_load@reload: - fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-blb-e6850/igt@i915_module_load@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-blb-e6850/igt@i915_module_load@reload.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#111108]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html #### Possible fixes #### * igt@gem_ctx_create@basic-files: - fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-bxt-dsi/igt@gem_ctx_create@basic-files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-bxt-dsi/igt@gem_ctx_create@basic-files.html * igt@gem_exec_fence@nb-await-default: - {fi-tgl-u}: [FAIL][9] ([fdo#111562] / [fdo#111597]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-tgl-u/igt@gem_exec_fence@nb-await-default.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-tgl-u/igt@gem_exec_fence@nb-await-default.html * igt@gem_mmap_gtt@basic-read-write: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@gem_mmap_gtt@basic-read-write.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@gem_mmap_gtt@basic-read-write.html * igt@i915_module_load@reload: - {fi-icl-u4}: [DMESG-WARN][13] ([fdo#105602]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u4/igt@i915_module_load@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u4/igt@i915_module_load@reload.html - fi-icl-u3: [DMESG-WARN][15] ([fdo#107724] / [fdo#111214]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@i915_module_load@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@i915_module_load@reload.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107 [fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309 [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045 [fdo#111108]: https://bugs.freedesktop.org/show_bug.cgi?id=111108 [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214 [fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562 [fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597 Participating hosts (55 -> 47) ------------------------------ Missing (8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_6906 -> Patchwork_14426 CI-20190529: 20190529 CI_DRM_6906: 72e400c2b824ab108907631fcf896d3d2020e7d5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14426: e998f828be52c9860960a1e0bf01536d6670a293 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e998f828be52 drm/i915: Lock signaler timeline while navigating == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: Lock signaler timeline while navigating 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson 2019-09-17 8:15 ` ✓ Fi.CI.BAT: success for " Patchwork @ 2019-09-17 11:44 ` Patchwork 2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin ` (4 subsequent siblings) 6 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2019-09-17 11:44 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: drm/i915: Lock signaler timeline while navigating URL : https://patchwork.freedesktop.org/series/66799/ State : success == Summary == CI Bug Log - changes from CI_DRM_6906_full -> Patchwork_14426_full ==================================================== Summary ------- **SUCCESS** No regressions found. Known issues ------------ Here are the changes found in Patchwork_14426_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_schedule@preempt-contexts-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb7/igt@gem_exec_schedule@preempt-contexts-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb2/igt@gem_exec_schedule@preempt-contexts-bsd.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl3/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-snb6/igt@i915_pm_rc6_residency@rc6-accuracy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-snb6/igt@i915_pm_rc6_residency@rc6-accuracy.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl6/igt@i915_suspend@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl3/igt@i915_suspend@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-c-cursor-size-change: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl9/igt@kms_cursor_crc@pipe-c-cursor-size-change.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-size-change.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#100368]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb5/igt@kms_plane_lowres@pipe-a-tiling-x.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl1/igt@kms_setmode@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl2/igt@kms_setmode@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-kbl2/igt@kms_setmode@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-kbl2/igt@kms_setmode@basic.html * igt@perf_pmu@busy-double-start-vecs0: - shard-skl: [PASS][25] -> [FAIL][26] ([fdo#111438]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl10/igt@perf_pmu@busy-double-start-vecs0.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl5/igt@perf_pmu@busy-double-start-vecs0.html * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#109276]) +12 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb6/igt@prime_vgem@fence-wait-bsd2.html #### Possible fixes #### * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [SKIP][29] ([fdo#109276]) -> [PASS][30] +12 similar issues [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb7/igt@gem_exec_schedule@preempt-contexts-bsd2.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb1/igt@gem_exec_schedule@preempt-contexts-bsd2.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [SKIP][31] ([fdo#111325]) -> [PASS][32] +2 similar issues [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@gem_exec_schedule@wide-bsd.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb5/igt@gem_exec_schedule@wide-bsd.html * igt@gem_softpin@noreloc-s3: - shard-skl: [INCOMPLETE][33] ([fdo#104108]) -> [PASS][34] [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl2/igt@gem_softpin@noreloc-s3.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl9/igt@gem_softpin@noreloc-s3.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][35] ([fdo#108566]) -> [PASS][36] +4 similar issues [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl2/igt@i915_suspend@sysfs-reader.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl7/igt@i915_suspend@sysfs-reader.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-snb: [INCOMPLETE][37] ([fdo#105411]) -> [PASS][38] [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-snb1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-snb1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-skl: [FAIL][39] ([fdo#103184] / [fdo#103232] / [fdo#108472]) -> [PASS][40] [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl8/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [FAIL][41] ([fdo#105363]) -> [PASS][42] [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@plain-flip-ts-check: - shard-glk: [FAIL][43] ([fdo#100368]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-glk7/igt@kms_flip@plain-flip-ts-check.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-glk3/igt@kms_flip@plain-flip-ts-check.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [FAIL][45] ([fdo#103167]) -> [PASS][46] +3 similar issues [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [FAIL][47] ([fdo#108145]) -> [PASS][48] [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [SKIP][49] ([fdo#109441]) -> [PASS][50] +2 similar issues [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb1/igt@kms_psr@psr2_cursor_render.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb2/igt@kms_psr@psr2_cursor_render.html #### Warnings #### * igt@gem_mocs_settings@mocs-rc6-bsd2: - shard-iclb: [FAIL][51] ([fdo#111330]) -> [SKIP][52] ([fdo#109276]) [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@gem_mocs_settings@mocs-rc6-bsd2.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb3/igt@gem_mocs_settings@mocs-rc6-bsd2.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [DMESG-WARN][53] ([fdo#108566]) -> [INCOMPLETE][54] ([fdo#103927]) [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl7/igt@i915_suspend@fence-restore-untiled.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl1/igt@i915_suspend@fence-restore-untiled.html [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411 [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#108472]: https://bugs.freedesktop.org/show_bug.cgi?id=108472 [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403 [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325 [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330 [fdo#111438]: https://bugs.freedesktop.org/show_bug.cgi?id=111438 [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912 Participating hosts (9 -> 10) ------------------------------ Additional (1): pig-hsw-4770r Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_6906 -> Patchwork_14426 CI-20190529: 20190529 CI_DRM_6906: 72e400c2b824ab108907631fcf896d3d2020e7d5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14426: e998f828be52c9860960a1e0bf01536d6670a293 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm/i915: Lock signaler timeline while navigating 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson 2019-09-17 8:15 ` ✓ Fi.CI.BAT: success for " Patchwork 2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork @ 2019-09-17 14:51 ` Tvrtko Ursulin 2019-09-17 15:04 ` Chris Wilson 2019-09-17 15:09 ` [PATCH v2] " Chris Wilson ` (3 subsequent siblings) 6 siblings, 1 reply; 14+ messages in thread From: Tvrtko Ursulin @ 2019-09-17 14:51 UTC (permalink / raw) To: Chris Wilson, intel-gfx On 17/09/2019 08:43, Chris Wilson wrote: > As we need to take a walk back along the signaler timeline to find the > fence before upon which we want to wait, we need to lock that timeline > to prevent it being modified as we walk. Similarly, we also need to > acquire a reference to the earlier fence while it still exists! > > Though we lack the correct locking today, we are saved by the > overarching struct_mutex -- but that protection is being removed. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------ > 1 file changed, 24 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index f12358150097..452ad7a8ff0c 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce) > static int > i915_request_await_start(struct i915_request *rq, struct i915_request *signal) > { > - if (list_is_first(&signal->link, &signal->timeline->requests)) > + struct intel_timeline *tl = signal->timeline; > + struct dma_fence *fence; > + int err; > + > + if (list_is_first(&signal->link, &tl->requests)) > return 0; > > - signal = list_prev_entry(signal, link); > - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) > + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) We are getting more and more these nested ones and it will become unmanageable to remember which ones, why and on what paths. Perhaps we need a comment next to the member in the structure definition? > + return -EINTR; > + > + if (list_is_first(&signal->link, &tl->requests)) { > + fence = NULL; > + } else { > + signal = list_prev_entry(signal, link); > + fence = dma_fence_get_rcu(&signal->fence); > + } > + mutex_unlock(&tl->mutex); > + if (!fence) Can it be no fence when it was obtained under the mutex? > return 0; > > - return i915_sw_fence_await_dma_fence(&rq->submit, > - &signal->fence, 0, > - I915_FENCE_GFP); > + err = 0; > + if (!intel_timeline_sync_is_later(rq->timeline, fence)) > + err = i915_sw_fence_await_dma_fence(&rq->submit, > + fence, 0, > + I915_FENCE_GFP); > + dma_fence_put(fence); > + > + return err; > } > > static intel_engine_mask_t > Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm/i915: Lock signaler timeline while navigating 2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin @ 2019-09-17 15:04 ` Chris Wilson 2019-09-17 15:22 ` Tvrtko Ursulin 0 siblings, 1 reply; 14+ messages in thread From: Chris Wilson @ 2019-09-17 15:04 UTC (permalink / raw) To: Tvrtko Ursulin, intel-gfx Quoting Tvrtko Ursulin (2019-09-17 15:51:45) > > On 17/09/2019 08:43, Chris Wilson wrote: > > As we need to take a walk back along the signaler timeline to find the > > fence before upon which we want to wait, we need to lock that timeline > > to prevent it being modified as we walk. Similarly, we also need to > > acquire a reference to the earlier fence while it still exists! > > > > Though we lack the correct locking today, we are saved by the > > overarching struct_mutex -- but that protection is being removed. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > --- > > drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------ > > 1 file changed, 24 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > > index f12358150097..452ad7a8ff0c 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce) > > static int > > i915_request_await_start(struct i915_request *rq, struct i915_request *signal) > > { > > - if (list_is_first(&signal->link, &signal->timeline->requests)) > > + struct intel_timeline *tl = signal->timeline; > > + struct dma_fence *fence; > > + int err; > > + > > + if (list_is_first(&signal->link, &tl->requests)) > > return 0; > > > > - signal = list_prev_entry(signal, link); > > - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) > > + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) > > We are getting more and more these nested ones and it will become > unmanageable to remember which ones, why and on what paths. Perhaps we > need a comment next to the member in the structure definition? The timeline mutex is held for request construction and retire; entry and exit of the timeline->requests. Since we have a request, it should be holding its rq->timeline->mutex; is that what you wish documented? Similarly that signal->timeline != rq->timeline. GEM_BUG_ON(signal->timeline == rq->timeline); lockdep_assert_held(&rq->timeline->mutex); > > + return -EINTR; > > + > > + if (list_is_first(&signal->link, &tl->requests)) { > > + fence = NULL; > > + } else { > > + signal = list_prev_entry(signal, link); > > + fence = dma_fence_get_rcu(&signal->fence); > > + } > > + mutex_unlock(&tl->mutex); > > + if (!fence) > > Can it be no fence when it was obtained under the mutex? Yes. The previous fence may have been retired and so removed from the tl->requests before we acquire the mutex. It should not be freed while it is still in the list, i.e. dma_fence_get_rcu() should never return NULL. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm/i915: Lock signaler timeline while navigating 2019-09-17 15:04 ` Chris Wilson @ 2019-09-17 15:22 ` Tvrtko Ursulin 0 siblings, 0 replies; 14+ messages in thread From: Tvrtko Ursulin @ 2019-09-17 15:22 UTC (permalink / raw) To: Chris Wilson, intel-gfx On 17/09/2019 16:04, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2019-09-17 15:51:45) >> >> On 17/09/2019 08:43, Chris Wilson wrote: >>> As we need to take a walk back along the signaler timeline to find the >>> fence before upon which we want to wait, we need to lock that timeline >>> to prevent it being modified as we walk. Similarly, we also need to >>> acquire a reference to the earlier fence while it still exists! >>> >>> Though we lack the correct locking today, we are saved by the >>> overarching struct_mutex -- but that protection is being removed. >>> >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>> --- >>> drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------ >>> 1 file changed, 24 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c >>> index f12358150097..452ad7a8ff0c 100644 >>> --- a/drivers/gpu/drm/i915/i915_request.c >>> +++ b/drivers/gpu/drm/i915/i915_request.c >>> @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce) >>> static int >>> i915_request_await_start(struct i915_request *rq, struct i915_request *signal) >>> { >>> - if (list_is_first(&signal->link, &signal->timeline->requests)) >>> + struct intel_timeline *tl = signal->timeline; >>> + struct dma_fence *fence; >>> + int err; >>> + >>> + if (list_is_first(&signal->link, &tl->requests)) >>> return 0; >>> >>> - signal = list_prev_entry(signal, link); >>> - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) >>> + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) >> >> We are getting more and more these nested ones and it will become >> unmanageable to remember which ones, why and on what paths. Perhaps we >> need a comment next to the member in the structure definition? > > The timeline mutex is held for request construction and retire; entry > and exit of the timeline->requests. Since we have a request, it should > be holding its rq->timeline->mutex; is that what you wish documented? > > Similarly that signal->timeline != rq->timeline. > > GEM_BUG_ON(signal->timeline == rq->timeline); > lockdep_assert_held(&rq->timeline->mutex); Yeah that helps. >>> + return -EINTR; >>> + >>> + if (list_is_first(&signal->link, &tl->requests)) { >>> + fence = NULL; >>> + } else { >>> + signal = list_prev_entry(signal, link); >>> + fence = dma_fence_get_rcu(&signal->fence); >>> + } >>> + mutex_unlock(&tl->mutex); >>> + if (!fence) >> >> Can it be no fence when it was obtained under the mutex? > > Yes. The previous fence may have been retired and so removed from the > tl->requests before we acquire the mutex. It should not be freed while > it is still in the list, i.e. dma_fence_get_rcu() should never return > NULL. I did not worry about the list_is_first check, just about dma_fence_get_rcu. At least I'm happy that one is safe and v2 is even better in this respect. Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v2] drm/i915: Lock signaler timeline while navigating 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson ` (2 preceding siblings ...) 2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin @ 2019-09-17 15:09 ` Chris Wilson 2019-09-17 15:20 ` Tvrtko Ursulin 2019-09-17 15:39 ` [PATCH v3] " Chris Wilson ` (2 subsequent siblings) 6 siblings, 1 reply; 14+ messages in thread From: Chris Wilson @ 2019-09-17 15:09 UTC (permalink / raw) To: intel-gfx As we need to take a walk back along the signaler timeline to find the fence before upon which we want to wait, we need to lock that timeline to prevent it being modified as we walk. Similarly, we also need to acquire a reference to the earlier fence while it still exists! Though we lack the correct locking today, we are saved by the overarching struct_mutex -- but that protection is being removed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> --- Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines. --- drivers/gpu/drm/i915/i915_request.c | 31 +++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index f12358150097..3966b330b5de 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) static int i915_request_await_start(struct i915_request *rq, struct i915_request *signal) { - if (list_is_first(&signal->link, &signal->timeline->requests)) + struct intel_timeline *tl = signal->timeline; + struct dma_fence *fence; + int err; + + lockdep_assert_held(&rq->timeline->mutex); + GEM_BUG_ON(rq->timeline == signal->timeline); + + if (list_is_first(&signal->link, &tl->requests)) return 0; - signal = list_prev_entry(signal, link); - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) + return -EINTR; + + fence = NULL; + if (!list_is_first(&signal->link, &tl->requests)) + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); + + mutex_unlock(&tl->mutex); + if (!fence) return 0; - return i915_sw_fence_await_dma_fence(&rq->submit, - &signal->fence, 0, - I915_FENCE_GFP); + err = 0; + if (!intel_timeline_sync_is_later(rq->timeline, fence)) + err = i915_sw_fence_await_dma_fence(&rq->submit, + fence, 0, + I915_FENCE_GFP); + dma_fence_put(fence); + + return err; } static intel_engine_mask_t -- 2.23.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v2] drm/i915: Lock signaler timeline while navigating 2019-09-17 15:09 ` [PATCH v2] " Chris Wilson @ 2019-09-17 15:20 ` Tvrtko Ursulin 0 siblings, 0 replies; 14+ messages in thread From: Tvrtko Ursulin @ 2019-09-17 15:20 UTC (permalink / raw) To: Chris Wilson, intel-gfx On 17/09/2019 16:09, Chris Wilson wrote: > As we need to take a walk back along the signaler timeline to find the > fence before upon which we want to wait, we need to lock that timeline > to prevent it being modified as we walk. Similarly, we also need to > acquire a reference to the earlier fence while it still exists! > > Though we lack the correct locking today, we are saved by the > overarching struct_mutex -- but that protection is being removed. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> > --- > Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines. > --- > drivers/gpu/drm/i915/i915_request.c | 31 +++++++++++++++++++++++------ > 1 file changed, 25 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index f12358150097..3966b330b5de 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) > static int > i915_request_await_start(struct i915_request *rq, struct i915_request *signal) > { > - if (list_is_first(&signal->link, &signal->timeline->requests)) > + struct intel_timeline *tl = signal->timeline; > + struct dma_fence *fence; > + int err; > + > + lockdep_assert_held(&rq->timeline->mutex); > + GEM_BUG_ON(rq->timeline == signal->timeline); > + > + if (list_is_first(&signal->link, &tl->requests)) > return 0; > > - signal = list_prev_entry(signal, link); > - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) > + if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING)) > + return -EINTR; > + > + fence = NULL; > + if (!list_is_first(&signal->link, &tl->requests)) > + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); > + > + mutex_unlock(&tl->mutex); > + if (!fence) > return 0; > > - return i915_sw_fence_await_dma_fence(&rq->submit, > - &signal->fence, 0, > - I915_FENCE_GFP); > + err = 0; > + if (!intel_timeline_sync_is_later(rq->timeline, fence)) > + err = i915_sw_fence_await_dma_fence(&rq->submit, > + fence, 0, > + I915_FENCE_GFP); > + dma_fence_put(fence); > + > + return err; > } > > static intel_engine_mask_t > Yes the asserts make it obvious now why the nested annotation is needed. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v3] drm/i915: Lock signaler timeline while navigating 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson ` (3 preceding siblings ...) 2019-09-17 15:09 ` [PATCH v2] " Chris Wilson @ 2019-09-17 15:39 ` Chris Wilson 2019-09-18 13:38 ` Tvrtko Ursulin 2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork 2019-09-18 7:36 ` ✓ Fi.CI.IGT: " Patchwork 6 siblings, 1 reply; 14+ messages in thread From: Chris Wilson @ 2019-09-17 15:39 UTC (permalink / raw) To: intel-gfx As we need to take a walk back along the signaler timeline to find the fence before upon which we want to wait, we need to lock that timeline to prevent it being modified as we walk. Similarly, we also need to acquire a reference to the earlier fence while it still exists! Though we lack the correct locking today, we are saved by the overarching struct_mutex -- but that protection is being removed. v2: Tvrtko made me realise I was being lax and using annotations to ignore the AB-BA deadlock from the timeline overlap. As it would be possible to construct a second request that was using a semaphore from the same timeline as ourselves, we could quite easily end up in a situation where we deadlocked in our mutex waits. Avoid that by using a trylock and falling back to a normal dma-fence await if contended. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> --- drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++---------- 1 file changed, 37 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index f12358150097..4e861673fe5c 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) static int i915_request_await_start(struct i915_request *rq, struct i915_request *signal) { - if (list_is_first(&signal->link, &signal->timeline->requests)) + struct intel_timeline *tl = signal->timeline; + struct dma_fence *fence; + int err; + + lockdep_assert_held(&rq->timeline->mutex); + GEM_BUG_ON(rq->timeline == signal->timeline); + + if (list_is_first(&signal->link, &tl->requests)) return 0; - signal = list_prev_entry(signal, link); - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) + if (!mutex_trylock(&tl->mutex)) + return -EBUSY; + + fence = NULL; + if (!list_is_first(&signal->link, &tl->requests)) + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); + + mutex_unlock(&tl->mutex); + if (!fence) return 0; - return i915_sw_fence_await_dma_fence(&rq->submit, - &signal->fence, 0, - I915_FENCE_GFP); + err = 0; + if (!intel_timeline_sync_is_later(rq->timeline, fence)) + err = i915_sw_fence_await_dma_fence(&rq->submit, + fence, 0, + I915_FENCE_GFP); + dma_fence_put(fence); + + return err; } static intel_engine_mask_t @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to, { u32 hwsp_offset; u32 *cs; - int err; GEM_BUG_ON(!from->timeline->has_initial_breadcrumb); GEM_BUG_ON(INTEL_GEN(to->i915) < 8); /* Just emit the first semaphore we see as request space is limited. */ if (already_busywaiting(to) & from->engine->mask) - return i915_sw_fence_await_dma_fence(&to->submit, - &from->fence, 0, - I915_FENCE_GFP); + goto await_fence; - err = i915_request_await_start(to, from); - if (err < 0) - return err; + if (i915_request_await_start(to, from) < 0) + goto await_fence; /* Only submit our spinner after the signaler is running! */ - err = __i915_request_await_execution(to, from, NULL, gfp); - if (err) - return err; + if (__i915_request_await_execution(to, from, NULL, gfp)) + goto await_fence; /* We need to pin the signaler's HWSP until we are finished reading. */ - err = intel_timeline_read_hwsp(from, to, &hwsp_offset); - if (err) - return err; + if (intel_timeline_read_hwsp(from, to, &hwsp_offset)) + goto await_fence; cs = intel_ring_begin(to, 4); if (IS_ERR(cs)) @@ -853,6 +866,11 @@ emit_semaphore_wait(struct i915_request *to, to->sched.semaphores |= from->engine->mask; to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN; return 0; + +await_fence: + return i915_sw_fence_await_dma_fence(&to->submit, + &from->fence, 0, + I915_FENCE_GFP); } static int -- 2.23.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating 2019-09-17 15:39 ` [PATCH v3] " Chris Wilson @ 2019-09-18 13:38 ` Tvrtko Ursulin 2019-09-18 13:44 ` Chris Wilson 0 siblings, 1 reply; 14+ messages in thread From: Tvrtko Ursulin @ 2019-09-18 13:38 UTC (permalink / raw) To: Chris Wilson, intel-gfx On 17/09/2019 16:39, Chris Wilson wrote: > As we need to take a walk back along the signaler timeline to find the > fence before upon which we want to wait, we need to lock that timeline > to prevent it being modified as we walk. Similarly, we also need to > acquire a reference to the earlier fence while it still exists! > > Though we lack the correct locking today, we are saved by the > overarching struct_mutex -- but that protection is being removed. > > v2: Tvrtko made me realise I was being lax and using annotations to > ignore the AB-BA deadlock from the timeline overlap. As it would be > possible to construct a second request that was using a semaphore from the > same timeline as ourselves, we could quite easily end up in a situation > where we deadlocked in our mutex waits. Avoid that by using a trylock > and falling back to a normal dma-fence await if contended. I did not figure out the exact AB-BA, but even on a more basic level without the deadlock, using trylock would mean false positives ie. falling back to software signaling with random mutex contention on the same timeline. From a performance perspective this sounds not end of the world, just unfortunate, but from the design perspective it has me running away scared. I guess the AB-BA would be interdependent requests from two timelines where the direction of dependency switches over across two pairs of submissions. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> > --- > drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++---------- > 1 file changed, 37 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index f12358150097..4e861673fe5c 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) > static int > i915_request_await_start(struct i915_request *rq, struct i915_request *signal) > { > - if (list_is_first(&signal->link, &signal->timeline->requests)) > + struct intel_timeline *tl = signal->timeline; > + struct dma_fence *fence; > + int err; > + > + lockdep_assert_held(&rq->timeline->mutex); > + GEM_BUG_ON(rq->timeline == signal->timeline); > + > + if (list_is_first(&signal->link, &tl->requests)) > return 0; > > - signal = list_prev_entry(signal, link); > - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) > + if (!mutex_trylock(&tl->mutex)) > + return -EBUSY; > + > + fence = NULL; > + if (!list_is_first(&signal->link, &tl->requests)) > + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); > + > + mutex_unlock(&tl->mutex); > + if (!fence) > return 0; > > - return i915_sw_fence_await_dma_fence(&rq->submit, > - &signal->fence, 0, > - I915_FENCE_GFP); > + err = 0; > + if (!intel_timeline_sync_is_later(rq->timeline, fence)) > + err = i915_sw_fence_await_dma_fence(&rq->submit, > + fence, 0, > + I915_FENCE_GFP); > + dma_fence_put(fence); > + > + return err; > } > > static intel_engine_mask_t > @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to, > { > u32 hwsp_offset; > u32 *cs; > - int err; > > GEM_BUG_ON(!from->timeline->has_initial_breadcrumb); > GEM_BUG_ON(INTEL_GEN(to->i915) < 8); > > /* Just emit the first semaphore we see as request space is limited. */ > if (already_busywaiting(to) & from->engine->mask) > - return i915_sw_fence_await_dma_fence(&to->submit, > - &from->fence, 0, > - I915_FENCE_GFP); > + goto await_fence; > > - err = i915_request_await_start(to, from); > - if (err < 0) > - return err; > + if (i915_request_await_start(to, from) < 0) > + goto await_fence; Does this need to be explicitly only on -EBUSY? Otherwise if i915_sw_fence_await_dma_fence fails in i915_request_await_start code jump to do the same i915_sw_fence_await_dma_fence. > > /* Only submit our spinner after the signaler is running! */ > - err = __i915_request_await_execution(to, from, NULL, gfp); > - if (err) > - return err; > + if (__i915_request_await_execution(to, from, NULL, gfp)) > + goto await_fence; > > /* We need to pin the signaler's HWSP until we are finished reading. */ > - err = intel_timeline_read_hwsp(from, to, &hwsp_offset); > - if (err) > - return err; > + if (intel_timeline_read_hwsp(from, to, &hwsp_offset)) > + goto await_fence; > > cs = intel_ring_begin(to, 4); > if (IS_ERR(cs)) > @@ -853,6 +866,11 @@ emit_semaphore_wait(struct i915_request *to, > to->sched.semaphores |= from->engine->mask; > to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN; > return 0; > + > +await_fence: > + return i915_sw_fence_await_dma_fence(&to->submit, > + &from->fence, 0, > + I915_FENCE_GFP); > } > > static int > Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating 2019-09-18 13:38 ` Tvrtko Ursulin @ 2019-09-18 13:44 ` Chris Wilson 2019-09-18 13:58 ` Tvrtko Ursulin 0 siblings, 1 reply; 14+ messages in thread From: Chris Wilson @ 2019-09-18 13:44 UTC (permalink / raw) To: Tvrtko Ursulin, intel-gfx Quoting Tvrtko Ursulin (2019-09-18 14:38:06) > > On 17/09/2019 16:39, Chris Wilson wrote: > > As we need to take a walk back along the signaler timeline to find the > > fence before upon which we want to wait, we need to lock that timeline > > to prevent it being modified as we walk. Similarly, we also need to > > acquire a reference to the earlier fence while it still exists! > > > > Though we lack the correct locking today, we are saved by the > > overarching struct_mutex -- but that protection is being removed. > > > > v2: Tvrtko made me realise I was being lax and using annotations to > > ignore the AB-BA deadlock from the timeline overlap. As it would be > > possible to construct a second request that was using a semaphore from the > > same timeline as ourselves, we could quite easily end up in a situation > > where we deadlocked in our mutex waits. Avoid that by using a trylock > > and falling back to a normal dma-fence await if contended. > > I did not figure out the exact AB-BA, but even on a more basic level > without the deadlock, using trylock would mean false positives ie. > falling back to software signaling with random mutex contention on the > same timeline. From a performance perspective this sounds not end of the > world, just unfortunate, but from the design perspective it has me > running away scared. > > I guess the AB-BA would be interdependent requests from two timelines > where the direction of dependency switches over across two pairs of > submissions. Exactly. Oh, you haven't seen the worst of it yet. This is a wonderful mess that just keeps on getting worse as you dig in. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> > > --- > > drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++---------- > > 1 file changed, 37 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > > index f12358150097..4e861673fe5c 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) > > static int > > i915_request_await_start(struct i915_request *rq, struct i915_request *signal) > > { > > - if (list_is_first(&signal->link, &signal->timeline->requests)) > > + struct intel_timeline *tl = signal->timeline; > > + struct dma_fence *fence; > > + int err; > > + > > + lockdep_assert_held(&rq->timeline->mutex); > > + GEM_BUG_ON(rq->timeline == signal->timeline); > > + > > + if (list_is_first(&signal->link, &tl->requests)) > > return 0; > > > > - signal = list_prev_entry(signal, link); > > - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) > > + if (!mutex_trylock(&tl->mutex)) > > + return -EBUSY; > > + > > + fence = NULL; > > + if (!list_is_first(&signal->link, &tl->requests)) > > + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); > > + > > + mutex_unlock(&tl->mutex); > > + if (!fence) > > return 0; > > > > - return i915_sw_fence_await_dma_fence(&rq->submit, > > - &signal->fence, 0, > > - I915_FENCE_GFP); > > + err = 0; > > + if (!intel_timeline_sync_is_later(rq->timeline, fence)) > > + err = i915_sw_fence_await_dma_fence(&rq->submit, > > + fence, 0, > > + I915_FENCE_GFP); > > + dma_fence_put(fence); > > + > > + return err; > > } > > > > static intel_engine_mask_t > > @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to, > > { > > u32 hwsp_offset; > > u32 *cs; > > - int err; > > > > GEM_BUG_ON(!from->timeline->has_initial_breadcrumb); > > GEM_BUG_ON(INTEL_GEN(to->i915) < 8); > > > > /* Just emit the first semaphore we see as request space is limited. */ > > if (already_busywaiting(to) & from->engine->mask) > > - return i915_sw_fence_await_dma_fence(&to->submit, > > - &from->fence, 0, > > - I915_FENCE_GFP); > > + goto await_fence; > > > > - err = i915_request_await_start(to, from); > > - if (err < 0) > > - return err; > > + if (i915_request_await_start(to, from) < 0) > > + goto await_fence; > > Does this need to be explicitly only on -EBUSY? Otherwise if > i915_sw_fence_await_dma_fence fails in i915_request_await_start code > jump to do the same i915_sw_fence_await_dma_fence. The only one that concerned me is ignoring any potential EINTR. All the other errors are transient and so trying again with the basic await is a valid response (imo). Not bailing out due to a pending signal though is a trade-off between our latency and their latency. To be honest, I like the simpler code where we just pretend we never noticed the signal unless we block again. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating 2019-09-18 13:44 ` Chris Wilson @ 2019-09-18 13:58 ` Tvrtko Ursulin 0 siblings, 0 replies; 14+ messages in thread From: Tvrtko Ursulin @ 2019-09-18 13:58 UTC (permalink / raw) To: Chris Wilson, intel-gfx On 18/09/2019 14:44, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2019-09-18 14:38:06) >> >> On 17/09/2019 16:39, Chris Wilson wrote: >>> As we need to take a walk back along the signaler timeline to find the >>> fence before upon which we want to wait, we need to lock that timeline >>> to prevent it being modified as we walk. Similarly, we also need to >>> acquire a reference to the earlier fence while it still exists! >>> >>> Though we lack the correct locking today, we are saved by the >>> overarching struct_mutex -- but that protection is being removed. >>> >>> v2: Tvrtko made me realise I was being lax and using annotations to >>> ignore the AB-BA deadlock from the timeline overlap. As it would be >>> possible to construct a second request that was using a semaphore from the >>> same timeline as ourselves, we could quite easily end up in a situation >>> where we deadlocked in our mutex waits. Avoid that by using a trylock >>> and falling back to a normal dma-fence await if contended. >> >> I did not figure out the exact AB-BA, but even on a more basic level >> without the deadlock, using trylock would mean false positives ie. >> falling back to software signaling with random mutex contention on the >> same timeline. From a performance perspective this sounds not end of the >> world, just unfortunate, but from the design perspective it has me >> running away scared. >> >> I guess the AB-BA would be interdependent requests from two timelines >> where the direction of dependency switches over across two pairs of >> submissions. > > Exactly. > > Oh, you haven't seen the worst of it yet. This is a wonderful mess that > just keeps on getting worse as you dig in. > >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> >>> --- >>> drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++---------- >>> 1 file changed, 37 insertions(+), 19 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c >>> index f12358150097..4e861673fe5c 100644 >>> --- a/drivers/gpu/drm/i915/i915_request.c >>> +++ b/drivers/gpu/drm/i915/i915_request.c >>> @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce) >>> static int >>> i915_request_await_start(struct i915_request *rq, struct i915_request *signal) >>> { >>> - if (list_is_first(&signal->link, &signal->timeline->requests)) >>> + struct intel_timeline *tl = signal->timeline; >>> + struct dma_fence *fence; >>> + int err; >>> + >>> + lockdep_assert_held(&rq->timeline->mutex); >>> + GEM_BUG_ON(rq->timeline == signal->timeline); >>> + >>> + if (list_is_first(&signal->link, &tl->requests)) >>> return 0; >>> >>> - signal = list_prev_entry(signal, link); >>> - if (intel_timeline_sync_is_later(rq->timeline, &signal->fence)) >>> + if (!mutex_trylock(&tl->mutex)) >>> + return -EBUSY; >>> + >>> + fence = NULL; >>> + if (!list_is_first(&signal->link, &tl->requests)) >>> + fence = dma_fence_get(&list_prev_entry(signal, link)->fence); >>> + >>> + mutex_unlock(&tl->mutex); >>> + if (!fence) >>> return 0; >>> >>> - return i915_sw_fence_await_dma_fence(&rq->submit, >>> - &signal->fence, 0, >>> - I915_FENCE_GFP); >>> + err = 0; >>> + if (!intel_timeline_sync_is_later(rq->timeline, fence)) >>> + err = i915_sw_fence_await_dma_fence(&rq->submit, >>> + fence, 0, >>> + I915_FENCE_GFP); >>> + dma_fence_put(fence); >>> + >>> + return err; >>> } >>> >>> static intel_engine_mask_t >>> @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to, >>> { >>> u32 hwsp_offset; >>> u32 *cs; >>> - int err; >>> >>> GEM_BUG_ON(!from->timeline->has_initial_breadcrumb); >>> GEM_BUG_ON(INTEL_GEN(to->i915) < 8); >>> >>> /* Just emit the first semaphore we see as request space is limited. */ >>> if (already_busywaiting(to) & from->engine->mask) >>> - return i915_sw_fence_await_dma_fence(&to->submit, >>> - &from->fence, 0, >>> - I915_FENCE_GFP); >>> + goto await_fence; >>> >>> - err = i915_request_await_start(to, from); >>> - if (err < 0) >>> - return err; >>> + if (i915_request_await_start(to, from) < 0) >>> + goto await_fence; >> >> Does this need to be explicitly only on -EBUSY? Otherwise if >> i915_sw_fence_await_dma_fence fails in i915_request_await_start code >> jump to do the same i915_sw_fence_await_dma_fence. > > The only one that concerned me is ignoring any potential EINTR. All the > other errors are transient and so trying again with the basic await is a > valid response (imo). Not bailing out due to a pending signal though is a > trade-off between our latency and their latency. To be honest, I like > the simpler code where we just pretend we never noticed the signal > unless we block again. Okay, should be safe anyway. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson ` (4 preceding siblings ...) 2019-09-17 15:39 ` [PATCH v3] " Chris Wilson @ 2019-09-17 17:40 ` Patchwork 2019-09-18 7:36 ` ✓ Fi.CI.IGT: " Patchwork 6 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2019-09-17 17:40 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: drm/i915: Lock signaler timeline while navigating (rev3) URL : https://patchwork.freedesktop.org/series/66799/ State : success == Summary == CI Bug Log - changes from CI_DRM_6910 -> Patchwork_14434 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/ Known issues ------------ Here are the changes found in Patchwork_14434 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_ctx_create@basic-files: - fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#109100]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u2/igt@gem_ctx_create@basic-files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u2/igt@gem_ctx_create@basic-files.html * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html #### Possible fixes #### * igt@gem_exec_fence@nb-await-default: - {fi-tgl-u2}: [FAIL][5] ([fdo#111562] / [fdo#111597]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-tgl-u2/igt@gem_exec_fence@nb-await-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-tgl-u2/igt@gem_exec_fence@nb-await-default.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-apl-guc: [DMESG-WARN][7] ([fdo#103558]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-apl-guc/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-apl-guc/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html * igt@prime_busy@basic-wait-before-default: - fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u3/igt@prime_busy@basic-wait-before-default.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u3/igt@prime_busy@basic-wait-before-default.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [DMESG-WARN][11] ([fdo#106387]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045 [fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562 [fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597 Participating hosts (52 -> 46) ------------------------------ Additional (1): fi-kbl-soraka Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-kbl-7500u fi-icl-y fi-icl-dsi fi-bdw-samus Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_6910 -> Patchwork_14434 CI-20190529: 20190529 CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14434: 6677a773f1ea976bf4582de153d06eb271495327 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6677a773f1ea drm/i915: Lock signaler timeline while navigating == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: Lock signaler timeline while navigating (rev3) 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson ` (5 preceding siblings ...) 2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork @ 2019-09-18 7:36 ` Patchwork 6 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2019-09-18 7:36 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: drm/i915: Lock signaler timeline while navigating (rev3) URL : https://patchwork.freedesktop.org/series/66799/ State : success == Summary == CI Bug Log - changes from CI_DRM_6910_full -> Patchwork_14434_full ==================================================== Summary ------- **SUCCESS** No regressions found. Known issues ------------ Here are the changes found in Patchwork_14434_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb3/igt@gem_exec_schedule@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl6/igt@gem_softpin@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl3/igt@gem_softpin@noreloc-s3.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#105767]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-hsw5/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-blocking-wf-vblank: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl4/igt@kms_flip@flip-vs-blocking-wf-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl6/igt@kms_flip@flip-vs-blocking-wf-vblank.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk8/igt@kms_flip@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk7/igt@kms_flip@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#109507]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl1/igt@kms_flip@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl4/igt@kms_flip@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl9/igt@kms_setmode@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl10/igt@kms_setmode@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-kbl2/igt@kms_setmode@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-kbl7/igt@kms_setmode@basic.html * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-skl: [PASS][25] -> [INCOMPLETE][26] ([fdo#104108]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl7/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html * igt@perf@blocking: - shard-skl: [PASS][27] -> [FAIL][28] ([fdo#110728]) +1 similar issue [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@perf@blocking.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl7/igt@perf@blocking.html * igt@prime_busy@after-bsd2: - shard-iclb: [PASS][29] -> [SKIP][30] ([fdo#109276]) +18 similar issues [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb1/igt@prime_busy@after-bsd2.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb7/igt@prime_busy@after-bsd2.html #### Possible fixes #### * igt@gem_eio@reset-stress: - shard-glk: [FAIL][31] ([fdo#109661]) -> [PASS][32] [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk2/igt@gem_eio@reset-stress.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk9/igt@gem_eio@reset-stress.html * igt@gem_eio@unwedge-stress: - shard-snb: [FAIL][33] ([fdo#109661]) -> [PASS][34] [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-snb2/igt@gem_eio@unwedge-stress.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-snb4/igt@gem_eio@unwedge-stress.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [SKIP][35] ([fdo#111325]) -> [PASS][36] +6 similar issues [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb1/igt@gem_exec_schedule@in-order-bsd.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb8/igt@gem_exec_schedule@in-order-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [SKIP][37] ([fdo#109276]) -> [PASS][38] +16 similar issues [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd1.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@gem_exec_schedule@preempt-queue-bsd1.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [DMESG-WARN][39] ([fdo#108686]) -> [PASS][40] [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl3/igt@gem_tiled_swapping@non-threaded.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl6/igt@gem_tiled_swapping@non-threaded.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][41] ([fdo#108566]) -> [PASS][42] +7 similar issues [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl1/igt@i915_suspend@sysfs-reader.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl2/igt@i915_suspend@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [INCOMPLETE][43] ([fdo#110741]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl10/igt@kms_cursor_crc@pipe-a-cursor-suspend.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl5/igt@kms_cursor_crc@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled: - shard-skl: [FAIL][45] ([fdo#103184] / [fdo#103232] / [fdo#108222]) -> [PASS][46] [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl3/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl10/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [FAIL][47] ([fdo#105363]) -> [PASS][48] +1 similar issue [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@kms_flip@flip-vs-expired-vblank.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl1/igt@kms_flip@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [FAIL][49] ([fdo#105363]) -> [PASS][50] [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interruptible.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-snb: [INCOMPLETE][51] ([fdo#105411]) -> [PASS][52] [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-snb1/igt@kms_flip@flip-vs-suspend-interruptible.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-snb1/igt@kms_flip@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [FAIL][53] ([fdo#103167]) -> [PASS][54] +3 similar issues [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [SKIP][55] ([fdo#109441]) -> [PASS][56] +1 similar issue [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html #### Warnings #### * igt@gem_ctx_isolation@vcs1-nonpriv: - shard-iclb: [SKIP][57] ([fdo#109276]) -> [FAIL][58] ([fdo#111329]) [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html * igt@gem_mocs_settings@mocs-isolation-bsd2: - shard-iclb: [FAIL][59] ([fdo#111330]) -> [SKIP][60] ([fdo#109276]) [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@gem_mocs_settings@mocs-isolation-bsd2.html [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@gem_mocs_settings@mocs-isolation-bsd2.html * igt@gem_mocs_settings@mocs-settings-bsd2: - shard-iclb: [SKIP][61] ([fdo#109276]) -> [FAIL][62] ([fdo#111330]) [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@gem_mocs_settings@mocs-settings-bsd2.html [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@gem_mocs_settings@mocs-settings-bsd2.html [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411 [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767 [fdo#108222]: https://bugs.freedesktop.org/show_bug.cgi?id=108222 [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566 [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507 [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661 [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728 [fdo#110741]: https://bugs.freedesktop.org/show_bug.cgi?id=110741 [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841 [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325 [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329 [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330 [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912 Participating hosts (10 -> 10) ------------------------------ No changes in participating hosts Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_6910 -> Patchwork_14434 CI-20190529: 20190529 CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14434: 6677a773f1ea976bf4582de153d06eb271495327 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-09-18 13:58 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-17 7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson 2019-09-17 8:15 ` ✓ Fi.CI.BAT: success for " Patchwork 2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork 2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin 2019-09-17 15:04 ` Chris Wilson 2019-09-17 15:22 ` Tvrtko Ursulin 2019-09-17 15:09 ` [PATCH v2] " Chris Wilson 2019-09-17 15:20 ` Tvrtko Ursulin 2019-09-17 15:39 ` [PATCH v3] " Chris Wilson 2019-09-18 13:38 ` Tvrtko Ursulin 2019-09-18 13:44 ` Chris Wilson 2019-09-18 13:58 ` Tvrtko Ursulin 2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork 2019-09-18 7:36 ` ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.