* [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
@ 2022-01-04 23:30 ` Matthew Brost
0 siblings, 0 replies; 12+ messages in thread
From: Matthew Brost @ 2022-01-04 23:30 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: daniele.ceraolospurio, john.c.harrison
Don't use the interruptable version of the timeline mutex lock in the
error path of eb_pin_timeline as the cleanup must always happen.
v2:
(John Harrison)
- Don't check for interrupt during mutex lock
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9541244027a..e96e133cbb1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
timeout) < 0) {
i915_request_put(rq);
- tl = intel_context_timeline_lock(ce);
+ mutex_lock(&ce->timeline->mutex);
intel_context_exit(ce);
- intel_context_timeline_unlock(tl);
+ mutex_unlock(&ce->timeline->mutex);
if (nonblock)
return -EWOULDBLOCK;
--
2.34.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
@ 2022-01-04 23:30 ` Matthew Brost
0 siblings, 0 replies; 12+ messages in thread
From: Matthew Brost @ 2022-01-04 23:30 UTC (permalink / raw)
To: intel-gfx, dri-devel
Don't use the interruptable version of the timeline mutex lock in the
error path of eb_pin_timeline as the cleanup must always happen.
v2:
(John Harrison)
- Don't check for interrupt during mutex lock
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9541244027a..e96e133cbb1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
timeout) < 0) {
i915_request_put(rq);
- tl = intel_context_timeline_lock(ce);
+ mutex_lock(&ce->timeline->mutex);
intel_context_exit(ce);
- intel_context_timeline_unlock(tl);
+ mutex_unlock(&ce->timeline->mutex);
if (nonblock)
return -EWOULDBLOCK;
--
2.34.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-04 23:30 ` [Intel-gfx] " Matthew Brost
(?)
@ 2022-01-05 0:27 ` Patchwork
-1 siblings, 0 replies; 12+ messages in thread
From: Patchwork @ 2022-01-05 0:27 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5667 bytes --]
== Series Details ==
Series: drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
URL : https://patchwork.freedesktop.org/series/98485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11046 -> Patchwork_21922
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/index.html
Participating hosts (50 -> 34)
------------------------------
Missing (16): fi-kbl-soraka fi-ilk-m540 bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan bat-adlp-6 fi-apl-guc fi-ctg-p8600 bat-adlp-4 fi-pnv-d510 bat-rpls-1 fi-bdw-samus bat-jsl-2 bat-jsl-1
Known issues
------------
Here are the changes found in Patchwork_21922 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-bsw-kefka/igt@amdgpu/amd_basic@query-info.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@gem_lmem_swapping@verify-random.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][4] -> [DMESG-FAIL][5] ([i915#4528])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/fi-blb-e6850/igt@i915_selftest@live@requests.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-blb-e6850/igt@i915_selftest@live@requests.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@kms_chamelium@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271]) +2 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [FAIL][9] ([i915#4547])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#2403] / [i915#4312])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-blb-e6850/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [INCOMPLETE][11] ([i915#4547]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [INCOMPLETE][13] ([i915#2940]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
#### Warnings ####
* igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4: [SKIP][15] ([i915#1072]) -> [SKIP][16] ([fdo#110189]) +3 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11046 -> Patchwork_21922
CI-20190529: 20190529
CI_DRM_11046: ee55310525cbff1a700aeeaf08f63a0f7b33c521 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6322: b0b7679b358b300b7b6bf42c6921d0aa1fc14388 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21922: a41655d678e9c50bf6ede1a2e9b13c094488dd7e @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a41655d678e9 drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/index.html
[-- Attachment #2: Type: text/html, Size: 7016 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-04 23:30 ` [Intel-gfx] " Matthew Brost
(?)
(?)
@ 2022-01-05 1:34 ` Patchwork
-1 siblings, 0 replies; 12+ messages in thread
From: Patchwork @ 2022-01-05 1:34 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30294 bytes --]
== Series Details ==
Series: drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
URL : https://patchwork.freedesktop.org/series/98485/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11046_full -> Patchwork_21922_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_21922_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21922_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
------------------------------
Missing (1): shard-dg1
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_21922_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_plane@plane-position-hole-dpms@pipe-b-planes:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-tglb2/igt@kms_plane@plane-position-hole-dpms@pipe-b-planes.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb8/igt@kms_plane@plane-position-hole-dpms@pipe-b-planes.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_persistence@smoketest:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-7/igt@gem_ctx_persistence@smoketest.html
* igt@gem_ctx_shared@q-smoketest-all:
- {shard-rkl}: [PASS][4] -> ([PASS][5], [INCOMPLETE][6])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-4/igt@gem_ctx_shared@q-smoketest-all.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-rkl-4/igt@gem_ctx_shared@q-smoketest-all.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-rkl-5/igt@gem_ctx_shared@q-smoketest-all.html
* igt@gem_mmap_offset@close-race:
- {shard-rkl}: ([PASS][7], [PASS][8]) -> [INCOMPLETE][9]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-1/igt@gem_mmap_offset@close-race.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-4/igt@gem_mmap_offset@close-race.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-rkl-5/igt@gem_mmap_offset@close-race.html
* igt@gem_mmap_offset@open-flood:
- {shard-rkl}: [PASS][10] -> [INCOMPLETE][11]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-1/igt@gem_mmap_offset@open-flood.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-rkl-5/igt@gem_mmap_offset@open-flood.html
* igt@runner@aborted:
- {shard-tglu}: [FAIL][12] ([i915#3002] / [i915#4312]) -> ([FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16]) ([i915#3002] / [i915#3690] / [i915#4312])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-tglu-5/igt@runner@aborted.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-7/igt@runner@aborted.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-5/igt@runner@aborted.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-3/igt@runner@aborted.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-5/igt@runner@aborted.html
* igt@testdisplay:
- {shard-tglu}: [PASS][17] -> [DMESG-WARN][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-tglu-1/igt@testdisplay.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-5/igt@testdisplay.html
Known issues
------------
Here are the changes found in Patchwork_21922_full that come from known issues:
### CI changes ###
#### Possible fixes ####
* boot:
- shard-glk: ([PASS][19], [PASS][20], [PASS][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43]) ([i915#4392]) -> ([PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59], [PASS][60], [PASS][61], [PASS][62], [PASS][63], [PASS][64], [PASS][65], [PASS][66], [PASS][67], [PASS][68])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk3/boot.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk5/boot.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk4/boot.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk4/boot.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk4/boot.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk4/boot.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk9/boot.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk9/boot.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk8/boot.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk8/boot.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk8/boot.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk7/boot.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk5/boot.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk7/boot.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk6/boot.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk1/boot.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk1/boot.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk6/boot.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk1/boot.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk2/boot.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk2/boot.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk6/boot.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk2/boot.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk3/boot.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk3/boot.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk9/boot.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk9/boot.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk9/boot.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk8/boot.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk8/boot.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk7/boot.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk7/boot.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk7/boot.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk6/boot.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk6/boot.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk6/boot.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk5/boot.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk5/boot.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk5/boot.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk4/boot.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk4/boot.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk4/boot.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/boot.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/boot.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/boot.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk2/boot.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk2/boot.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk2/boot.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk1/boot.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk1/boot.html
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-tglb: NOTRUN -> [DMESG-WARN][69] ([i915#3002])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb1/igt@gem_create@create-massive.html
* igt@gem_ctx_sseu@invalid-sseu:
- shard-tglb: NOTRUN -> [SKIP][70] ([i915#280])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@gem_ctx_sseu@invalid-sseu.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][71] -> [SKIP][72] ([i915#4525])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb1/igt@gem_exec_balancer@parallel.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb8/igt@gem_exec_balancer@parallel.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-tglb: NOTRUN -> [FAIL][73] ([i915#2842])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-apl: [PASS][74] -> [FAIL][75] ([i915#2842])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-apl7/igt@gem_exec_fair@basic-none@vcs0.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl3/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][76] -> [FAIL][77] ([i915#2842]) +1 similar issue
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk2/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][78] -> [FAIL][79] ([i915#2842])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs0.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-kbl4/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_exec_whisper@basic-forked:
- shard-glk: [PASS][80] -> [DMESG-WARN][81] ([i915#118])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk5/igt@gem_exec_whisper@basic-forked.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk7/igt@gem_exec_whisper@basic-forked.html
* igt@gem_lmem_swapping@heavy-verify-multi:
- shard-glk: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#4613])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@gem_lmem_swapping@heavy-verify-multi.html
* igt@gem_lmem_swapping@parallel-random:
- shard-skl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#4613]) +2 similar issues
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl4/igt@gem_lmem_swapping@parallel-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#4613]) +1 similar issue
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl8/igt@gem_lmem_swapping@parallel-random-engines.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][85] ([i915#3002])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@gem_userptr_blits@input-checking.html
* igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-tglb: NOTRUN -> [SKIP][86] ([i915#3297])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@gem_userptr_blits@unsync-unmap-cycles.html
* igt@gem_userptr_blits@vma-merge:
- shard-skl: NOTRUN -> [FAIL][87] ([i915#3318])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@gem_userptr_blits@vma-merge.html
* igt@gen3_render_mixed_blits:
- shard-tglb: NOTRUN -> [SKIP][88] ([fdo#109289])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@gen3_render_mixed_blits.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][89] -> [FAIL][90] ([i915#454])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb1/igt@i915_pm_dc@dc6-psr.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb8/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-iclb: [PASS][91] -> [INCOMPLETE][92] ([i915#4922])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb2/igt@i915_pm_rpm@modeset-lpsp-stress.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb4/igt@i915_pm_rpm@modeset-lpsp-stress.html
* igt@kms_big_fb@linear-16bpp-rotate-90:
- shard-apl: NOTRUN -> [SKIP][93] ([fdo#109271]) +118 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_big_fb@linear-16bpp-rotate-90.html
* igt@kms_big_fb@linear-8bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][94] ([fdo#111614])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_big_fb@linear-8bpp-rotate-90.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-skl: NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#3777])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][96] ([fdo#111615])
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_big_fb@yf-tiled-32bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#3777])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][98] ([fdo#109271] / [i915#3886]) +4 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][99] ([i915#3689])
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_ccs.html
* igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][100] ([i915#3689] / [i915#3886])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][101] ([fdo#109271] / [i915#3886]) +8 similar issues
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl5/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
- shard-glk: NOTRUN -> [SKIP][102] ([fdo#109271] / [i915#3886])
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][103] ([fdo#109271]) +283 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@vga-hpd:
- shard-apl: NOTRUN -> [SKIP][104] ([fdo#109271] / [fdo#111827]) +13 similar issues
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_chamelium@vga-hpd.html
* igt@kms_color_chamelium@pipe-a-ctm-0-25:
- shard-glk: NOTRUN -> [SKIP][105] ([fdo#109271] / [fdo#111827]) +2 similar issues
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@kms_color_chamelium@pipe-a-ctm-0-25.html
* igt@kms_color_chamelium@pipe-d-ctm-0-75:
- shard-skl: NOTRUN -> [SKIP][106] ([fdo#109271] / [fdo#111827]) +16 similar issues
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@kms_color_chamelium@pipe-d-ctm-0-75.html
* igt@kms_color_chamelium@pipe-d-ctm-max:
- shard-tglb: NOTRUN -> [SKIP][107] ([fdo#109284] / [fdo#111827]) +1 similar issue
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_color_chamelium@pipe-d-ctm-max.html
* igt@kms_content_protection@atomic:
- shard-apl: NOTRUN -> [TIMEOUT][108] ([i915#1319])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_content_protection@atomic.html
* igt@kms_cursor_crc@pipe-a-cursor-32x32-random:
- shard-tglb: NOTRUN -> [SKIP][109] ([i915#3319])
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-32x32-random.html
* igt@kms_cursor_crc@pipe-a-cursor-512x512-sliding:
- shard-tglb: NOTRUN -> [SKIP][110] ([fdo#109279] / [i915#3359])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-512x512-sliding.html
* igt@kms_cursor_crc@pipe-b-cursor-max-size-random:
- shard-tglb: NOTRUN -> [SKIP][111] ([i915#3359])
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_cursor_crc@pipe-b-cursor-max-size-random.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: NOTRUN -> [FAIL][112] ([i915#2346])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@2x-blocking-absolute-wf_vblank:
- shard-tglb: NOTRUN -> [SKIP][113] ([fdo#109274] / [fdo#111825]) +1 similar issue
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_flip@2x-blocking-absolute-wf_vblank.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][114] -> [FAIL][115] ([i915#79]) +1 similar issue
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: [PASS][116] -> [DMESG-WARN][117] ([i915#180]) +20 similar issues
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-kbl3/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-kbl6/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-apl: [PASS][118] -> [DMESG-WARN][119] ([i915#180]) +7 similar issues
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-apl1/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-skl: NOTRUN -> [FAIL][120] ([i915#2122])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling:
- shard-skl: NOTRUN -> [INCOMPLETE][121] ([i915#3701])
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl10/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
- shard-glk: [PASS][122] -> [FAIL][123] ([i915#4911])
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk9/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling:
- shard-iclb: [PASS][124] -> [SKIP][125] ([i915#3701])
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][126] ([fdo#109271]) +40 similar issues
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-move:
- shard-tglb: NOTRUN -> [SKIP][127] ([fdo#109280] / [fdo#111825]) +1 similar issue
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-move.html
* igt@kms_multipipe_modeset@basic-max-pipe-crc-check:
- shard-tglb: NOTRUN -> [SKIP][128] ([i915#1839])
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html
* igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d:
- shard-glk: NOTRUN -> [SKIP][129] ([fdo#109271] / [i915#533])
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][130] ([fdo#109271] / [i915#533]) +3 similar issues
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-skl: NOTRUN -> [FAIL][131] ([i915#265])
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> [FAIL][132] ([fdo#108145] / [i915#265])
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl2/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: NOTRUN -> [FAIL][133] ([fdo#108145] / [i915#265]) +2 similar issues
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-tglb: NOTRUN -> [SKIP][134] ([i915#3536])
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_plane_lowres@pipe-a-tiling-y.html
* igt@kms_psr2_sf@cursor-plane-update-sf:
- shard-skl: NOTRUN -> [SKIP][135] ([fdo#109271] / [i915#658]) +1 similar issue
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@kms_psr2_sf@cursor-plane-update-sf.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][136] ([fdo#109271] / [i915#658])
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][137] -> [SKIP][138] ([fdo#109441]) +2 similar issues
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-tglb: NOTRUN -> [FAIL][139] ([i915#132] / [i915#3467])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][140] -> [FAIL][141] ([i915#31])
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-apl4/igt@kms_setmode@basic.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_setmode@basic.html
* igt@kms_sysfs_edid_timing:
- shard-skl: NOTRUN -> [FAIL][142] ([IGT#2])
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@kms_sysfs_edid_timing.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][143] -> [DMESG-WARN][144] ([i915#180] / [i915#295])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-kbl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
- shard-apl: [PASS][145] -> [DMESG-WARN][146] ([i915#180] / [i915#295])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-apl2/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl8/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_writeback@writeback-check-output:
- shard-skl: NOTRUN -> [SKIP][147] ([fdo#109271] / [i915#2437])
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl9/igt@kms_writeback@writeback-check-output.html
* igt@kms_writeback@writeback-fb-id:
- shard-apl: NOTRUN -> [SKIP][148] ([fdo#109271] / [i915#2437])
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-apl1/igt@kms_writeback@writeback-fb-id.html
* igt@nouveau_crc@pipe-d-ctx-flip-skip-current-frame:
- shard-tglb: NOTRUN -> [SKIP][149] ([i915#2530])
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@nouveau_crc@pipe-d-ctx-flip-skip-current-frame.html
* igt@prime_nv_api@nv_i915_import_twice_check_flink_name:
- shard-tglb: NOTRUN -> [SKIP][150] ([fdo#109291])
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@prime_nv_api@nv_i915_import_twice_check_flink_name.html
* igt@prime_vgem@fence-read-hang:
- shard-tglb: NOTRUN -> [SKIP][151] ([fdo#109295])
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglb2/igt@prime_vgem@fence-read-hang.html
* igt@sysfs_clients@fair-0:
- shard-skl: NOTRUN -> [SKIP][152] ([fdo#109271] / [i915#2994]) +3 similar issues
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-skl8/igt@sysfs_clients@fair-0.html
* igt@sysfs_clients@fair-7:
- shard-glk: NOTRUN -> [SKIP][153] ([fdo#109271] / [i915#2994])
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk3/igt@sysfs_clients@fair-7.html
#### Possible fixes ####
* igt@fbdev@write:
- {shard-rkl}: ([SKIP][154], [SKIP][155]) ([i915#2582]) -> [PASS][156]
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-1/igt@fbdev@write.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-rkl-4/igt@fbdev@write.html
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-rkl-6/igt@fbdev@write.html
* igt@gem_exec_balancer@bonded-pair:
- {shard-tglu}: [FAIL][157] ([i915#1888]) -> [PASS][158]
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-tglu-7/igt@gem_exec_balancer@bonded-pair.html
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-tglu-7/igt@gem_exec_balancer@bonded-pair.html
* igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [SKIP][159] ([i915#4525]) -> [PASS][160]
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-iclb8/igt@gem_exec_balancer@parallel-keep-submit-fence.html
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-iclb1/igt@gem_exec_balancer@parallel-keep-submit-fence.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: [FAIL][161] ([i915#2846]) -> [PASS][162]
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-kbl4/igt@gem_exec_fair@basic-deadline.html
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-kbl7/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [FAIL][163] ([i915#2842]) -> [PASS][164]
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11046/shard-glk5/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/shard-glk5/igt@gem_exec_fair@
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21922/index.html
[-- Attachment #2: Type: text/html, Size: 33565 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-04 23:30 ` [Intel-gfx] " Matthew Brost
` (2 preceding siblings ...)
(?)
@ 2022-01-05 9:35 ` Tvrtko Ursulin
2022-01-05 16:24 ` Matthew Brost
-1 siblings, 1 reply; 12+ messages in thread
From: Tvrtko Ursulin @ 2022-01-05 9:35 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 04/01/2022 23:30, Matthew Brost wrote:
> Don't use the interruptable version of the timeline mutex lock in the
interruptible
> error path of eb_pin_timeline as the cleanup must always happen.
>
> v2:
> (John Harrison)
> - Don't check for interrupt during mutex lock
>
> Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index e9541244027a..e96e133cbb1f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> timeout) < 0) {
> i915_request_put(rq);
>
> - tl = intel_context_timeline_lock(ce);
> + mutex_lock(&ce->timeline->mutex);
On the other hand it is more user friendly to handle signals (which
maybe does not matter in this case, not sure any longer how long hold
time it can have) but there is also a question of consistency within the
very function you are changing.
Apart from consistency, what about the parent-child magic
intel_context_timeline_lock does and you wouldn't have here?
And what about the very existence of intel_context_timeline_lock as a
component boundary separation API, if it is used inconsistently
throughout i915_gem_execbuffer.c?
Regards,
Tvrtko
> intel_context_exit(ce);
> - intel_context_timeline_unlock(tl);
> + mutex_unlock(&ce->timeline->mutex);
>
> if (nonblock)
> return -EWOULDBLOCK;
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-05 9:35 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
@ 2022-01-05 16:24 ` Matthew Brost
2022-01-06 9:56 ` Tvrtko Ursulin
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Brost @ 2022-01-05 16:24 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
On Wed, Jan 05, 2022 at 09:35:44AM +0000, Tvrtko Ursulin wrote:
>
> On 04/01/2022 23:30, Matthew Brost wrote:
> > Don't use the interruptable version of the timeline mutex lock in the
>
> interruptible
>
> > error path of eb_pin_timeline as the cleanup must always happen.
> >
> > v2:
> > (John Harrison)
> > - Don't check for interrupt during mutex lock
> >
> > Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index e9541244027a..e96e133cbb1f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> > timeout) < 0) {
> > i915_request_put(rq);
> > - tl = intel_context_timeline_lock(ce);
> > + mutex_lock(&ce->timeline->mutex);
>
> On the other hand it is more user friendly to handle signals (which maybe
> does not matter in this case, not sure any longer how long hold time it can
> have) but there is also a question of consistency within the very function
> you are changing.
>
> Apart from consistency, what about the parent-child magic
> intel_context_timeline_lock does and you wouldn't have here?
>
> And what about the very existence of intel_context_timeline_lock as a
> component boundary separation API, if it is used inconsistently throughout
> i915_gem_execbuffer.c?
intel_context_timeline_lock does 2 things:
1. Handles lockdep nesting of timeline locks for parent-child contexts
ensuring locks are acquired from parent to last child, then released
last child to parent
2. Allows the mutex lock to be interrupted
This helper should be used in setup steps where a user can signal abort
(context pinning time + request creation time), by 'should be' I mean
this was how it was done before I extended the execbuf IOCTL for
multiple BBs. Slightly confusing but this is what was in place so I
stuck with it.
This code here is an error path that only hold at most 1 timeline lock
(no nesting required) and is a path that must be executed as it is a
cleanup step (not allowed to be interrupted by user, intel_context_exit
must be called or we have dangling engine PM refs).
Make sense? I probably should update the comment message to explain this
a bit better as it did take me a bit to understand how this locking
worked.
Matt
>
> Regards,
>
> Tvrtko
>
> > intel_context_exit(ce);
> > - intel_context_timeline_unlock(tl);
> > + mutex_unlock(&ce->timeline->mutex);
> > if (nonblock)
> > return -EWOULDBLOCK;
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-05 16:24 ` Matthew Brost
@ 2022-01-06 9:56 ` Tvrtko Ursulin
2022-01-06 16:18 ` Matthew Brost
0 siblings, 1 reply; 12+ messages in thread
From: Tvrtko Ursulin @ 2022-01-06 9:56 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx, dri-devel
On 05/01/2022 16:24, Matthew Brost wrote:
> On Wed, Jan 05, 2022 at 09:35:44AM +0000, Tvrtko Ursulin wrote:
>>
>> On 04/01/2022 23:30, Matthew Brost wrote:
>>> Don't use the interruptable version of the timeline mutex lock in the
>>
>> interruptible
>>
>>> error path of eb_pin_timeline as the cleanup must always happen.
>>>
>>> v2:
>>> (John Harrison)
>>> - Don't check for interrupt during mutex lock
>>>
>>> Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> index e9541244027a..e96e133cbb1f 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
>>> timeout) < 0) {
>>> i915_request_put(rq);
>>> - tl = intel_context_timeline_lock(ce);
>>> + mutex_lock(&ce->timeline->mutex);
>>
>> On the other hand it is more user friendly to handle signals (which maybe
>> does not matter in this case, not sure any longer how long hold time it can
>> have) but there is also a question of consistency within the very function
>> you are changing.
>>
>> Apart from consistency, what about the parent-child magic
>> intel_context_timeline_lock does and you wouldn't have here?
>>
>> And what about the very existence of intel_context_timeline_lock as a
>> component boundary separation API, if it is used inconsistently throughout
>> i915_gem_execbuffer.c?
>
> intel_context_timeline_lock does 2 things:
>
> 1. Handles lockdep nesting of timeline locks for parent-child contexts
> ensuring locks are acquired from parent to last child, then released
> last child to parent
> 2. Allows the mutex lock to be interrupted
>
> This helper should be used in setup steps where a user can signal abort
> (context pinning time + request creation time), by 'should be' I mean
> this was how it was done before I extended the execbuf IOCTL for
> multiple BBs. Slightly confusing but this is what was in place so I
> stuck with it.
>
> This code here is an error path that only hold at most 1 timeline lock
> (no nesting required) and is a path that must be executed as it is a
> cleanup step (not allowed to be interrupted by user, intel_context_exit
> must be called or we have dangling engine PM refs).
>
> Make sense? I probably should update the comment message to explain this
> a bit better as it did take me a bit to understand how this locking
> worked.
The part which does not make sense is this:
eb_pin_timeline()
{
...
tl = intel_context_timeline_lock(ce);
if (IS_ERR(tl))
return PTR_ERR(tl);
... do some throttling, and if it fail:
mutex_lock(&ce->timeline->mutex);
Therefore argument that at most one timeline lock is held and the extra
stuff is not needed does not hold for me. Why would the throttling
failed path be different than the initial step in this respect?
Using two ways to lock the same mutex withing 10 lines of code is confusing.
In my mind we have this question of API usage consistency, and also the
unanswered questions of whether reacting to signals during taking this
mutex matters (what are the pessimistic lock hold times and what
influences them?).
Note that first lock handles signals, throttling also handles signals,
so why wouldn't the cleanup path? Just because then you don't have to
bother with error unwind is to only reason I can see.
So I suggest you just do proper error unwind and be done with it.
if (rq) {
ret = i915_request_wait()
i915_request_put(rq)
if (ret)
goto err;
}
return 0;
err:
tl = intel_context_timeline_lock()
intel_context_exit()
intel_context_timeline_unlock()
return nonblock ? ... : ...;
Regards,
Tvrtko
>
> Matt
>
>>
>> Regards,
>>
>> Tvrtko
>>
>>> intel_context_exit(ce);
>>> - intel_context_timeline_unlock(tl);
>>> + mutex_unlock(&ce->timeline->mutex);
>>> if (nonblock)
>>> return -EWOULDBLOCK;
>>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-06 9:56 ` Tvrtko Ursulin
@ 2022-01-06 16:18 ` Matthew Brost
2022-01-06 16:51 ` Tvrtko Ursulin
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Brost @ 2022-01-06 16:18 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
On Thu, Jan 06, 2022 at 09:56:03AM +0000, Tvrtko Ursulin wrote:
>
> On 05/01/2022 16:24, Matthew Brost wrote:
> > On Wed, Jan 05, 2022 at 09:35:44AM +0000, Tvrtko Ursulin wrote:
> > >
> > > On 04/01/2022 23:30, Matthew Brost wrote:
> > > > Don't use the interruptable version of the timeline mutex lock in the
> > >
> > > interruptible
> > >
> > > > error path of eb_pin_timeline as the cleanup must always happen.
> > > >
> > > > v2:
> > > > (John Harrison)
> > > > - Don't check for interrupt during mutex lock
> > > >
> > > > Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > index e9541244027a..e96e133cbb1f 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> > > > timeout) < 0) {
> > > > i915_request_put(rq);
> > > > - tl = intel_context_timeline_lock(ce);
> > > > + mutex_lock(&ce->timeline->mutex);
> > >
> > > On the other hand it is more user friendly to handle signals (which maybe
> > > does not matter in this case, not sure any longer how long hold time it can
> > > have) but there is also a question of consistency within the very function
> > > you are changing.
> > >
> > > Apart from consistency, what about the parent-child magic
> > > intel_context_timeline_lock does and you wouldn't have here?
> > >
> > > And what about the very existence of intel_context_timeline_lock as a
> > > component boundary separation API, if it is used inconsistently throughout
> > > i915_gem_execbuffer.c?
> >
> > intel_context_timeline_lock does 2 things:
> >
> > 1. Handles lockdep nesting of timeline locks for parent-child contexts
> > ensuring locks are acquired from parent to last child, then released
> > last child to parent
> > 2. Allows the mutex lock to be interrupted
> >
> > This helper should be used in setup steps where a user can signal abort
> > (context pinning time + request creation time), by 'should be' I mean
> > this was how it was done before I extended the execbuf IOCTL for
> > multiple BBs. Slightly confusing but this is what was in place so I
> > stuck with it.
> >
> > This code here is an error path that only hold at most 1 timeline lock
> > (no nesting required) and is a path that must be executed as it is a
> > cleanup step (not allowed to be interrupted by user, intel_context_exit
> > must be called or we have dangling engine PM refs).
> >
> > Make sense? I probably should update the comment message to explain this
> > a bit better as it did take me a bit to understand how this locking
> > worked.
>
> The part which does not make sense is this:
>
I'll try to explain this again...
> eb_pin_timeline()
> {
> ...
> tl = intel_context_timeline_lock(ce);
> if (IS_ERR(tl))
> return PTR_ERR(tl);
This part is allowed to be aborted by the user.
>
> ... do some throttling, and if it fail:
> mutex_lock(&ce->timeline->mutex);
This part is not.
>
> Therefore argument that at most one timeline lock is held and the extra
> stuff is not needed does not hold for me. Why would the throttling failed
> path be different than the initial step in this respect?
>
> Using two ways to lock the same mutex withing 10 lines of code is confusing.
>
> In my mind we have this question of API usage consistency, and also the
> unanswered questions of whether reacting to signals during taking this mutex
> matters (what are the pessimistic lock hold times and what influences
> them?).
>
> Note that first lock handles signals, throttling also handles signals, so
> why wouldn't the cleanup path? Just because then you don't have to bother
> with error unwind is to only reason I can see.
>
> So I suggest you just do proper error unwind and be done with it.
>
> if (rq) {
> ret = i915_request_wait()
> i915_request_put(rq)
> if (ret)
> goto err;
> }
>
> return 0;
>
> err:
>
> tl = intel_context_timeline_lock()
We've already successfully called intel_context_enter,
intel_context_timeline_lock can be aborted by the user and return NULL.
If NULL lockdep blows up in intel_context_exit and we can NULL ptr dref
in intel_context_timeline_unlock. If we bail on tl returning NULL, now
we don't call intel_context_exit and be have dangling PM ref and GPU
will never power down.
Again all of the same code was in place before any of updated to the
execbuf IOCTL for multi-BB, just fixing a mistake I made when doing this
update.
Matt
> intel_context_exit()
> intel_context_timeline_unlock()
>
> return nonblock ? ... : ...;
>
> Regards,
>
> Tvrtko
>
> >
> > Matt
> >
> > >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > > intel_context_exit(ce);
> > > > - intel_context_timeline_unlock(tl);
> > > > + mutex_unlock(&ce->timeline->mutex);
> > > > if (nonblock)
> > > > return -EWOULDBLOCK;
> > > >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-06 16:18 ` Matthew Brost
@ 2022-01-06 16:51 ` Tvrtko Ursulin
2022-01-06 16:52 ` Matthew Brost
0 siblings, 1 reply; 12+ messages in thread
From: Tvrtko Ursulin @ 2022-01-06 16:51 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx, dri-devel
On 06/01/2022 16:18, Matthew Brost wrote:
> On Thu, Jan 06, 2022 at 09:56:03AM +0000, Tvrtko Ursulin wrote:
>>
>> On 05/01/2022 16:24, Matthew Brost wrote:
>>> On Wed, Jan 05, 2022 at 09:35:44AM +0000, Tvrtko Ursulin wrote:
>>>>
>>>> On 04/01/2022 23:30, Matthew Brost wrote:
>>>>> Don't use the interruptable version of the timeline mutex lock in the
>>>>
>>>> interruptible
>>>>
>>>>> error path of eb_pin_timeline as the cleanup must always happen.
>>>>>
>>>>> v2:
>>>>> (John Harrison)
>>>>> - Don't check for interrupt during mutex lock
>>>>>
>>>>> Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>> index e9541244027a..e96e133cbb1f 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>> @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
>>>>> timeout) < 0) {
>>>>> i915_request_put(rq);
>>>>> - tl = intel_context_timeline_lock(ce);
>>>>> + mutex_lock(&ce->timeline->mutex);
>>>>
>>>> On the other hand it is more user friendly to handle signals (which maybe
>>>> does not matter in this case, not sure any longer how long hold time it can
>>>> have) but there is also a question of consistency within the very function
>>>> you are changing.
>>>>
>>>> Apart from consistency, what about the parent-child magic
>>>> intel_context_timeline_lock does and you wouldn't have here?
>>>>
>>>> And what about the very existence of intel_context_timeline_lock as a
>>>> component boundary separation API, if it is used inconsistently throughout
>>>> i915_gem_execbuffer.c?
>>>
>>> intel_context_timeline_lock does 2 things:
>>>
>>> 1. Handles lockdep nesting of timeline locks for parent-child contexts
>>> ensuring locks are acquired from parent to last child, then released
>>> last child to parent
>>> 2. Allows the mutex lock to be interrupted
>>>
>>> This helper should be used in setup steps where a user can signal abort
>>> (context pinning time + request creation time), by 'should be' I mean
>>> this was how it was done before I extended the execbuf IOCTL for
>>> multiple BBs. Slightly confusing but this is what was in place so I
>>> stuck with it.
>>>
>>> This code here is an error path that only hold at most 1 timeline lock
>>> (no nesting required) and is a path that must be executed as it is a
>>> cleanup step (not allowed to be interrupted by user, intel_context_exit
>>> must be called or we have dangling engine PM refs).
>>>
>>> Make sense? I probably should update the comment message to explain this
>>> a bit better as it did take me a bit to understand how this locking
>>> worked.
>>
>> The part which does not make sense is this:
>>
>
> I'll try to explain this again...
>
>> eb_pin_timeline()
>> {
>> ...
>> tl = intel_context_timeline_lock(ce);
>> if (IS_ERR(tl))
>> return PTR_ERR(tl);
>
> This part is allowed to be aborted by the user.
>
>>
>> ... do some throttling, and if it fail:
>> mutex_lock(&ce->timeline->mutex);
>
> This part is not.
Pfft got it this time round.
I suggest a comment above the mutex to this effect. And maybe still
consider the explicit error path which may be more readable due single
request put, but it's up to you.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-06 16:51 ` Tvrtko Ursulin
@ 2022-01-06 16:52 ` Matthew Brost
0 siblings, 0 replies; 12+ messages in thread
From: Matthew Brost @ 2022-01-06 16:52 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
On Thu, Jan 06, 2022 at 04:51:21PM +0000, Tvrtko Ursulin wrote:
>
> On 06/01/2022 16:18, Matthew Brost wrote:
> > On Thu, Jan 06, 2022 at 09:56:03AM +0000, Tvrtko Ursulin wrote:
> > >
> > > On 05/01/2022 16:24, Matthew Brost wrote:
> > > > On Wed, Jan 05, 2022 at 09:35:44AM +0000, Tvrtko Ursulin wrote:
> > > > >
> > > > > On 04/01/2022 23:30, Matthew Brost wrote:
> > > > > > Don't use the interruptable version of the timeline mutex lock in the
> > > > >
> > > > > interruptible
> > > > >
> > > > > > error path of eb_pin_timeline as the cleanup must always happen.
> > > > > >
> > > > > > v2:
> > > > > > (John Harrison)
> > > > > > - Don't check for interrupt during mutex lock
> > > > > >
> > > > > > Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
> > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > index e9541244027a..e96e133cbb1f 100644
> > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> > > > > > timeout) < 0) {
> > > > > > i915_request_put(rq);
> > > > > > - tl = intel_context_timeline_lock(ce);
> > > > > > + mutex_lock(&ce->timeline->mutex);
> > > > >
> > > > > On the other hand it is more user friendly to handle signals (which maybe
> > > > > does not matter in this case, not sure any longer how long hold time it can
> > > > > have) but there is also a question of consistency within the very function
> > > > > you are changing.
> > > > >
> > > > > Apart from consistency, what about the parent-child magic
> > > > > intel_context_timeline_lock does and you wouldn't have here?
> > > > >
> > > > > And what about the very existence of intel_context_timeline_lock as a
> > > > > component boundary separation API, if it is used inconsistently throughout
> > > > > i915_gem_execbuffer.c?
> > > >
> > > > intel_context_timeline_lock does 2 things:
> > > >
> > > > 1. Handles lockdep nesting of timeline locks for parent-child contexts
> > > > ensuring locks are acquired from parent to last child, then released
> > > > last child to parent
> > > > 2. Allows the mutex lock to be interrupted
> > > >
> > > > This helper should be used in setup steps where a user can signal abort
> > > > (context pinning time + request creation time), by 'should be' I mean
> > > > this was how it was done before I extended the execbuf IOCTL for
> > > > multiple BBs. Slightly confusing but this is what was in place so I
> > > > stuck with it.
> > > >
> > > > This code here is an error path that only hold at most 1 timeline lock
> > > > (no nesting required) and is a path that must be executed as it is a
> > > > cleanup step (not allowed to be interrupted by user, intel_context_exit
> > > > must be called or we have dangling engine PM refs).
> > > >
> > > > Make sense? I probably should update the comment message to explain this
> > > > a bit better as it did take me a bit to understand how this locking
> > > > worked.
> > >
> > > The part which does not make sense is this:
> > >
> >
> > I'll try to explain this again...
> >
> > > eb_pin_timeline()
> > > {
> > > ...
> > > tl = intel_context_timeline_lock(ce);
> > > if (IS_ERR(tl))
> > > return PTR_ERR(tl);
> >
> > This part is allowed to be aborted by the user.
> >
> > >
> > > ... do some throttling, and if it fail:
> > > mutex_lock(&ce->timeline->mutex);
> >
> > This part is not.
>
> Pfft got it this time round.
>
> I suggest a comment above the mutex to this effect. And maybe still consider
> the explicit error path which may be more readable due single request put,
> but it's up to you.
>
I'll add comment and see how adding an explict error path looks in the code.
Matt
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
2022-01-11 16:39 Matthew Brost
@ 2022-01-20 20:54 ` John Harrison
0 siblings, 0 replies; 12+ messages in thread
From: John Harrison @ 2022-01-20 20:54 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 1/11/2022 08:39, Matthew Brost wrote:
> Don't use the interruptable version of the timeline mutex lock in the
> error path of eb_pin_timeline as the cleanup must always happen.
>
> v2:
> (John Harrison)
> - Don't check for interrupt during mutex lock
> v3:
> (Tvrtko)
> - A comment explaining why lock helper isn't used
>
> Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 9e221ce427075..4a611d62e991a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2518,9 +2518,14 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> timeout) < 0) {
> i915_request_put(rq);
>
> - tl = intel_context_timeline_lock(ce);
> + /*
> + * Error path, cannot use intel_context_timeline_lock as
> + * that is user interruptable and this clean up step
> + * must be done.
> + */
> + mutex_lock(&ce->timeline->mutex);
> intel_context_exit(ce);
> - intel_context_timeline_unlock(tl);
> + mutex_unlock(&ce->timeline->mutex);
>
> if (nonblock)
> return -EWOULDBLOCK;
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
@ 2022-01-11 16:39 Matthew Brost
2022-01-20 20:54 ` John Harrison
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Brost @ 2022-01-11 16:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Don't use the interruptable version of the timeline mutex lock in the
error path of eb_pin_timeline as the cleanup must always happen.
v2:
(John Harrison)
- Don't check for interrupt during mutex lock
v3:
(Tvrtko)
- A comment explaining why lock helper isn't used
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9e221ce427075..4a611d62e991a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2518,9 +2518,14 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
timeout) < 0) {
i915_request_put(rq);
- tl = intel_context_timeline_lock(ce);
+ /*
+ * Error path, cannot use intel_context_timeline_lock as
+ * that is user interruptable and this clean up step
+ * must be done.
+ */
+ mutex_lock(&ce->timeline->mutex);
intel_context_exit(ce);
- intel_context_timeline_unlock(tl);
+ mutex_unlock(&ce->timeline->mutex);
if (nonblock)
return -EWOULDBLOCK;
--
2.34.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-01-20 20:54 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-04 23:30 [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline Matthew Brost
2022-01-04 23:30 ` [Intel-gfx] " Matthew Brost
2022-01-05 0:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-01-05 1:34 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-01-05 9:35 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-01-05 16:24 ` Matthew Brost
2022-01-06 9:56 ` Tvrtko Ursulin
2022-01-06 16:18 ` Matthew Brost
2022-01-06 16:51 ` Tvrtko Ursulin
2022-01-06 16:52 ` Matthew Brost
2022-01-11 16:39 Matthew Brost
2022-01-20 20:54 ` John Harrison
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.