* [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine
@ 2023-07-05 16:08 Andrzej Hajda
2023-07-05 17:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
` (6 more replies)
0 siblings, 7 replies; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-05 16:08 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson, Andrzej Hajda, Nirmoy Das
GuC virtual engines can be removed before request removal. On the other
side driver expects rq->engine to be a valid pointer for a whole life of
request. Setting rq->engine to an always valid engine should solve
the issue.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7926
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d246..2c877ea5eda6f0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
static void remove_from_context(struct i915_request *rq)
{
struct intel_context *ce = request_to_scheduling_context(rq);
+ struct intel_engine_cs *engine;
+ intel_engine_mask_t tmp;
GEM_BUG_ON(intel_context_is_child(ce));
@@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
atomic_dec(&ce->guc_id.ref);
i915_request_notify_execute_cb_imm(rq);
+
+ /*
+ * GuC virtual engine can disappear after this call, so let's assign
+ * something valid, as driver expects this to be always valid pointer.
+ */
+ for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
+ rq->engine = engine;
+ break;
+ }
}
static const struct intel_context_ops guc_context_ops = {
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
@ 2023-07-05 17:34 ` Patchwork
2023-07-05 17:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (5 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Patchwork @ 2023-07-05 17:34 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine
URL : https://patchwork.freedesktop.org/series/120238/
State : warning
== Summary ==
Error: patch https://patchwork.freedesktop.org/api/1.0/series/120238/revisions/1/mbox/ not found
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
2023-07-05 17:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
@ 2023-07-05 17:50 ` Patchwork
2023-07-05 19:11 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
` (4 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Patchwork @ 2023-07-05 17:50 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 15058 bytes --]
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine
URL : https://patchwork.freedesktop.org/series/120238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13346 -> Patchwork_120238v1
====================================================
Summary
-------
**WARNING**
Minor unknown changes coming with Patchwork_120238v1 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_120238v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/index.html
Participating hosts (40 -> 40)
------------------------------
Additional (2): bat-atsm-1 fi-pnv-d510
Missing (2): fi-kbl-soraka fi-snb-2520m
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_120238v1:
### IGT changes ###
#### Warnings ####
* igt@kms_psr@primary_page_flip:
- bat-rplp-1: [SKIP][1] ([i915#1072]) -> [ABORT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-rplp-1/igt@kms_psr@primary_page_flip.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html
Known issues
------------
Here are the changes found in Patchwork_120238v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@gem_lmem_swapping@parallel-random-engines.html
* igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4083])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@gem_mmap@basic.html
* igt@gem_render_tiled_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@gem_render_tiled_blits@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@gem_tiled_fence_blits@basic.html
* igt@i915_pm_rps@basic-api:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6621])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@i915_pm_rps@basic-api.html
- bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#6621])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_pm_rps@basic-api.html
* igt@i915_selftest@live@gt_mocs:
- bat-mtlp-8: NOTRUN -> [DMESG-FAIL][9] ([i915#7059])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][10] -> [DMESG-FAIL][11] ([i915#8723])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/fi-skl-guc/igt@i915_selftest@live@hangcheck.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/fi-skl-guc/igt@i915_selftest@live@hangcheck.html
* igt@i915_selftest@live@migrate:
- bat-mtlp-6: [PASS][12] -> [DMESG-FAIL][13] ([i915#7699])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_selftest@live@migrate.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_selftest@live@migrate.html
* igt@i915_selftest@live@requests:
- bat-mtlp-8: NOTRUN -> [DMESG-FAIL][14] ([i915#8497])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_selftest@live@requests.html
- bat-mtlp-6: [PASS][15] -> [DMESG-FAIL][16] ([i915#8497])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_selftest@live@requests.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_selftest@live@requests.html
* igt@i915_selftest@live@slpc:
- bat-mtlp-6: [PASS][17] -> [DMESG-WARN][18] ([i915#6367])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_selftest@live@slpc.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_selftest@live@slpc.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][19] ([i915#6367])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_selftest@live@slpc.html
- bat-rpls-1: [PASS][20] -> [DMESG-WARN][21] ([i915#6367])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-rpls-1/igt@i915_selftest@live@slpc.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-rpls-1/igt@i915_selftest@live@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-kbl-7567u: [PASS][22] -> [ABORT][23] ([i915#8299])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/fi-kbl-7567u/igt@i915_suspend@basic-s2idle-without-i915.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/fi-kbl-7567u/igt@i915_suspend@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-6: NOTRUN -> [SKIP][24] ([i915#6645])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_suspend@basic-s3-without-i915.html
- bat-atsm-1: NOTRUN -> [SKIP][25] ([i915#6645])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@i915_suspend@basic-s3-without-i915.html
- bat-mtlp-8: NOTRUN -> [SKIP][26] ([i915#6645])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_suspend@basic-s3-without-i915.html
* igt@kms_addfb_basic@size-max:
- bat-atsm-1: NOTRUN -> [SKIP][27] ([i915#6077]) +36 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_addfb_basic@size-max.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-mtlp-6: NOTRUN -> [SKIP][28] ([i915#7828])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@kms_chamelium_hpd@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][29] ([i915#7828])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@kms_chamelium_hpd@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- bat-atsm-1: NOTRUN -> [SKIP][30] ([i915#6078]) +19 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- bat-atsm-1: NOTRUN -> [SKIP][31] ([i915#6166]) +3 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_flip@basic-flip-vs-wf_vblank.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-atsm-1: NOTRUN -> [SKIP][32] ([i915#6093]) +3 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-atsm-1: NOTRUN -> [SKIP][33] ([i915#1836]) +6 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-mtlp-6: NOTRUN -> [SKIP][34] ([i915#1845] / [i915#4078])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@kms_pipe_crc_basic@suspend-read-crc.html
* igt@kms_prop_blob@basic:
- bat-atsm-1: NOTRUN -> [SKIP][35] ([i915#7357])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_prop_blob@basic.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510: NOTRUN -> [SKIP][36] ([fdo#109271]) +38 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
* igt@kms_psr@sprite_plane_onoff:
- bat-atsm-1: NOTRUN -> [SKIP][37] ([i915#1072]) +3 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-atsm-1: NOTRUN -> [SKIP][38] ([i915#6094])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@kms_setmode@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-flip:
- bat-atsm-1: NOTRUN -> [SKIP][39] ([fdo#109295] / [i915#6078])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@prime_vgem@basic-fence-flip.html
* igt@prime_vgem@basic-fence-read:
- bat-mtlp-8: NOTRUN -> [SKIP][40] ([i915#3708]) +2 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@prime_vgem@basic-fence-read.html
* igt@prime_vgem@basic-gtt:
- bat-atsm-1: NOTRUN -> [SKIP][41] ([fdo#109295] / [i915#4077]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@prime_vgem@basic-gtt.html
- bat-mtlp-8: NOTRUN -> [SKIP][42] ([i915#3708] / [i915#4077]) +1 similar issue
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@prime_vgem@basic-gtt.html
* igt@prime_vgem@basic-write:
- bat-atsm-1: NOTRUN -> [SKIP][43] ([fdo#109295]) +2 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-atsm-1/igt@prime_vgem@basic-write.html
#### Possible fixes ####
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-mtlp-8: [ABORT][44] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][45]
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-8/igt@i915_pm_rpm@basic-pci-d3-state.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-8/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [DMESG-FAIL][46] ([i915#7059]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@guc:
- bat-rpls-1: [DMESG-WARN][48] ([i915#7852]) -> [PASS][49]
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-rpls-1/igt@i915_selftest@live@guc.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-rpls-1/igt@i915_selftest@live@guc.html
* igt@i915_selftest@live@workarounds:
- bat-mtlp-6: [DMESG-FAIL][50] ([i915#6763]) -> [PASS][51]
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_selftest@live@workarounds.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_selftest@live@workarounds.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-mtlp-6: [ABORT][52] -> [PASS][53]
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-mtlp-6/igt@i915_suspend@basic-s2idle-without-i915.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-mtlp-6/igt@i915_suspend@basic-s2idle-without-i915.html
#### Warnings ####
* igt@i915_module_load@load:
- bat-adlp-11: [DMESG-WARN][54] ([i915#4423]) -> [ABORT][55] ([i915#4423])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/bat-adlp-11/igt@i915_module_load@load.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/bat-adlp-11/igt@i915_module_load@load.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4423]: https://gitlab.freedesktop.org/drm/intel/issues/4423
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#6077]: https://gitlab.freedesktop.org/drm/intel/issues/6077
[i915#6078]: https://gitlab.freedesktop.org/drm/intel/issues/6078
[i915#6093]: https://gitlab.freedesktop.org/drm/intel/issues/6093
[i915#6094]: https://gitlab.freedesktop.org/drm/intel/issues/6094
[i915#6166]: https://gitlab.freedesktop.org/drm/intel/issues/6166
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763
[i915#7059]: https://gitlab.freedesktop.org/drm/intel/issues/7059
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7357]: https://gitlab.freedesktop.org/drm/intel/issues/7357
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#8299]: https://gitlab.freedesktop.org/drm/intel/issues/8299
[i915#8497]: https://gitlab.freedesktop.org/drm/intel/issues/8497
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8723]: https://gitlab.freedesktop.org/drm/intel/issues/8723
Build changes
-------------
* Linux: CI_DRM_13346 -> Patchwork_120238v1
CI-20190529: 20190529
CI_DRM_13346: c5442b2363bf5ad916805d105ff03ce5805070e5 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7370: f63ab5e7c3ddef724bebde558e36647ca65d98bc @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120238v1: c5442b2363bf5ad916805d105ff03ce5805070e5 @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
6bd24e531fc2 drm/i915/gt: update request engine before removing virtual GuC engine
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/index.html
[-- Attachment #2: Type: text/html, Size: 17758 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
2023-07-05 17:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2023-07-05 17:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2023-07-05 19:11 ` Patchwork
2023-07-06 15:16 ` [Intel-gfx] [PATCH v2] " Andrzej Hajda
` (3 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Patchwork @ 2023-07-05 19:11 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 60944 bytes --]
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine
URL : https://patchwork.freedesktop.org/series/120238/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13346_full -> Patchwork_120238v1_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_120238v1_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_120238v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 9)
------------------------------
Missing (1): shard-rkl0
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_120238v1_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_content_protection@lic:
- shard-mtlp: NOTRUN -> [SKIP][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_content_protection@lic.html
* igt@kms_plane_alpha_blend@alpha-opaque-fb:
- shard-dg2: NOTRUN -> [TIMEOUT][2] +1 similar issue
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-1/igt@kms_plane_alpha_blend@alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@coverage-7efc@pipe-a-edp-1:
- shard-mtlp: NOTRUN -> [FAIL][3] +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_plane_alpha_blend@coverage-7efc@pipe-a-edp-1.html
* igt@syncobj_timeline@reset-signaled:
- shard-dg2: [PASS][4] -> [TIMEOUT][5] +1 similar issue
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-12/igt@syncobj_timeline@reset-signaled.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-1/igt@syncobj_timeline@reset-signaled.html
#### Warnings ####
* igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible:
- shard-dg2: [SKIP][6] ([fdo#109274]) -> [TIMEOUT][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-12/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-1/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible.html
Known issues
------------
Here are the changes found in Patchwork_120238v1_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@drm_fdinfo@busy-idle-check-all@vcs0:
- shard-dg2: NOTRUN -> [SKIP][8] ([i915#8414]) +10 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@drm_fdinfo@busy-idle-check-all@vcs0.html
* igt@drm_fdinfo@busy@vcs0:
- shard-mtlp: NOTRUN -> [SKIP][9] ([i915#8414]) +7 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@drm_fdinfo@busy@vcs0.html
* igt@gem_ccs@ctrl-surf-copy:
- shard-rkl: NOTRUN -> [SKIP][10] ([i915#3555] / [i915#5325])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gem_ccs@ctrl-surf-copy.html
* igt@gem_ctx_persistence@heartbeat-hostile:
- shard-mtlp: NOTRUN -> [SKIP][11] ([i915#8555])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_ctx_persistence@heartbeat-hostile.html
* igt@gem_eio@hibernate:
- shard-dg2: [PASS][12] -> [ABORT][13] ([i915#7975] / [i915#8213])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-11/igt@gem_eio@hibernate.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-7/igt@gem_eio@hibernate.html
* igt@gem_eio@in-flight-10ms:
- shard-mtlp: [PASS][14] -> [ABORT][15] ([i915#8503])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-2/igt@gem_eio@in-flight-10ms.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-5/igt@gem_eio@in-flight-10ms.html
* igt@gem_exec_balancer@full-pulse:
- shard-dg2: [PASS][16] -> [FAIL][17] ([i915#6032])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-5/igt@gem_exec_balancer@full-pulse.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-8/igt@gem_exec_balancer@full-pulse.html
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-mtlp: NOTRUN -> [SKIP][18] ([i915#6334])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_exec_capture@capture-invisible@smem0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][19] -> [FAIL][20] ([i915#2842])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#2842])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-glk4/igt@gem_exec_fair@basic-pace-share@rcs0.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-glk2/igt@gem_exec_fair@basic-pace-share@rcs0.html
- shard-tglu: [PASS][23] -> [FAIL][24] ([i915#2842])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-tglu-3/igt@gem_exec_fair@basic-pace-share@rcs0.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-tglu-9/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-rkl: [PASS][25] -> [FAIL][26] ([i915#2842])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-2/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- shard-rkl: NOTRUN -> [SKIP][27] ([i915#3281]) +1 similar issue
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gem_exec_reloc@basic-gtt-read-noreloc.html
* igt@gem_exec_reloc@basic-gtt-wc-active:
- shard-dg2: NOTRUN -> [SKIP][28] ([i915#3281]) +2 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_exec_reloc@basic-gtt-wc-active.html
* igt@gem_exec_reloc@basic-wc-gtt-noreloc:
- shard-mtlp: NOTRUN -> [SKIP][29] ([i915#3281]) +1 similar issue
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_exec_reloc@basic-wc-gtt-noreloc.html
* igt@gem_exec_schedule@preempt-queue-contexts:
- shard-mtlp: NOTRUN -> [SKIP][30] ([i915#4812])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_exec_schedule@preempt-queue-contexts.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-rkl: NOTRUN -> [ABORT][31] ([i915#7975] / [i915#8213])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gem_exec_suspend@basic-s4-devices@smem.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-mtlp: NOTRUN -> [SKIP][32] ([i915#4613]) +2 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@gem_lmem_swapping@heavy-multi.html
* igt@gem_lmem_swapping@verify:
- shard-apl: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#4613])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@gem_lmem_swapping@verify.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-mtlp: NOTRUN -> [SKIP][34] ([i915#4077]) +4 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
* igt@gem_mmap_wc@read:
- shard-mtlp: NOTRUN -> [SKIP][35] ([i915#4083]) +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_mmap_wc@read.html
* igt@gem_partial_pwrite_pread@write:
- shard-rkl: NOTRUN -> [SKIP][36] ([i915#3282]) +1 similar issue
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gem_partial_pwrite_pread@write.html
* igt@gem_partial_pwrite_pread@write-display:
- shard-dg2: NOTRUN -> [SKIP][37] ([i915#3282])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_partial_pwrite_pread@write-display.html
* igt@gem_partial_pwrite_pread@writes-after-reads:
- shard-mtlp: NOTRUN -> [SKIP][38] ([i915#3282]) +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_partial_pwrite_pread@writes-after-reads.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb: [PASS][39] -> [DMESG-FAIL][40] ([i915#8295])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-snb6/igt@gem_ppgtt@blt-vs-render-ctxn.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-snb6/igt@gem_ppgtt@blt-vs-render-ctxn.html
* igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-dg2: NOTRUN -> [SKIP][41] ([i915#4270])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted.html
* igt@gem_pxp@protected-encrypted-src-copy-not-readible:
- shard-mtlp: NOTRUN -> [SKIP][42] ([i915#4270])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_pxp@protected-encrypted-src-copy-not-readible.html
* igt@gem_render_copy@yf-tiled-mc-ccs-to-vebox-yf-tiled:
- shard-dg2: NOTRUN -> [SKIP][43] ([i915#5190]) +2 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@gem_render_copy@yf-tiled-mc-ccs-to-vebox-yf-tiled.html
- shard-mtlp: NOTRUN -> [SKIP][44] ([i915#8428])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_render_copy@yf-tiled-mc-ccs-to-vebox-yf-tiled.html
* igt@gem_softpin@evict-snoop-interruptible:
- shard-mtlp: NOTRUN -> [SKIP][45] ([i915#4885])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@gem_softpin@evict-snoop-interruptible.html
* igt@gem_spin_batch@spin-all-new:
- shard-dg2: NOTRUN -> [FAIL][46] ([i915#5889])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_spin_batch@spin-all-new.html
* igt@gem_tiled_partial_pwrite_pread@writes-after-reads:
- shard-dg2: NOTRUN -> [SKIP][47] ([i915#4077])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_tiled_partial_pwrite_pread@writes-after-reads.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-dg2: NOTRUN -> [SKIP][48] ([i915#3297] / [i915#4880])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
* igt@gen7_exec_parse@basic-offset:
- shard-rkl: NOTRUN -> [SKIP][49] ([fdo#109289])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gen7_exec_parse@basic-offset.html
* igt@gen9_exec_parse@allowed-all:
- shard-mtlp: NOTRUN -> [SKIP][50] ([i915#2856])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gen9_exec_parse@allowed-all.html
* igt@gen9_exec_parse@batch-zero-length:
- shard-rkl: NOTRUN -> [SKIP][51] ([i915#2527])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@gen9_exec_parse@batch-zero-length.html
* igt@gen9_exec_parse@bb-oversize:
- shard-dg2: NOTRUN -> [SKIP][52] ([i915#2856])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gen9_exec_parse@bb-oversize.html
* igt@i915_pipe_stress@stress-xrgb8888-ytiled:
- shard-dg2: NOTRUN -> [SKIP][53] ([i915#7091])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@i915_pipe_stress@stress-xrgb8888-ytiled.html
* igt@i915_pm_dc@dc5-dpms-negative:
- shard-mtlp: NOTRUN -> [SKIP][54] ([i915#8018])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@i915_pm_dc@dc5-dpms-negative.html
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- shard-mtlp: NOTRUN -> [SKIP][55] ([fdo#109289] / [i915#8403])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@i915_pm_rc6_residency@media-rc6-accuracy.html
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- shard-rkl: NOTRUN -> [SKIP][56] ([fdo#109506])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
* igt@i915_suspend@basic-s3-without-i915:
- shard-rkl: [PASS][57] -> [FAIL][58] ([fdo#103375])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-1/igt@i915_suspend@basic-s3-without-i915.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-4/igt@i915_suspend@basic-s3-without-i915.html
- shard-mtlp: NOTRUN -> [SKIP][59] ([i915#6645])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@i915_suspend@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- shard-mtlp: NOTRUN -> [SKIP][60] ([i915#4212]) +1 similar issue
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy.html
* igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- shard-dg2: NOTRUN -> [SKIP][61] ([i915#4212])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@kms_addfb_basic@framebuffer-vs-set-tiling.html
* igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-1-y-rc_ccs:
- shard-rkl: NOTRUN -> [SKIP][62] ([i915#8502]) +3 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-1-y-rc_ccs.html
* igt@kms_async_flips@crc@pipe-b-hdmi-a-1:
- shard-rkl: NOTRUN -> [FAIL][63] ([i915#8247]) +1 similar issue
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@kms_async_flips@crc@pipe-b-hdmi-a-1.html
* igt@kms_async_flips@crc@pipe-d-dp-4:
- shard-dg2: NOTRUN -> [FAIL][64] ([i915#8247]) +3 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_async_flips@crc@pipe-d-dp-4.html
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- shard-rkl: NOTRUN -> [SKIP][65] ([i915#1769] / [i915#3555])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels.html
* igt@kms_big_fb@4-tiled-64bpp-rotate-180:
- shard-mtlp: [PASS][66] -> [FAIL][67] ([i915#5138])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-1/igt@kms_big_fb@4-tiled-64bpp-rotate-180.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-4/igt@kms_big_fb@4-tiled-64bpp-rotate-180.html
* igt@kms_big_fb@4-tiled-8bpp-rotate-180:
- shard-rkl: NOTRUN -> [SKIP][68] ([i915#5286])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_big_fb@4-tiled-8bpp-rotate-180.html
* igt@kms_big_fb@4-tiled-8bpp-rotate-270:
- shard-mtlp: NOTRUN -> [SKIP][69] ([fdo#111614]) +1 similar issue
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_big_fb@4-tiled-8bpp-rotate-270.html
* igt@kms_big_fb@linear-64bpp-rotate-270:
- shard-rkl: NOTRUN -> [SKIP][70] ([fdo#111614] / [i915#3638]) +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_big_fb@linear-64bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-90:
- shard-dg2: NOTRUN -> [SKIP][71] ([i915#4538] / [i915#5190]) +2 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@kms_big_fb@yf-tiled-32bpp-rotate-90.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-rkl: NOTRUN -> [SKIP][72] ([fdo#110723]) +1 similar issue
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-90:
- shard-mtlp: NOTRUN -> [SKIP][73] ([fdo#111615]) +5 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_big_fb@yf-tiled-64bpp-rotate-90.html
* igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-rkl: NOTRUN -> [SKIP][74] ([i915#3886] / [i915#5354] / [i915#6095])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs:
- shard-rkl: NOTRUN -> [SKIP][75] ([i915#5354] / [i915#6095]) +5 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-mtlp: NOTRUN -> [SKIP][76] ([i915#3886] / [i915#6095]) +4 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][77] ([fdo#109271] / [i915#3886]) +2 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- shard-dg2: NOTRUN -> [SKIP][78] ([i915#3689] / [i915#5354])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-dg2: NOTRUN -> [SKIP][79] ([i915#3689] / [i915#3886] / [i915#5354])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
- shard-rkl: NOTRUN -> [SKIP][80] ([i915#5354]) +4 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-d-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-mtlp: NOTRUN -> [SKIP][81] ([i915#6095]) +12 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_ccs@pipe-d-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_cdclk@plane-scaling:
- shard-rkl: NOTRUN -> [SKIP][82] ([i915#3742])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_cdclk@plane-scaling.html
* igt@kms_cdclk@plane-scaling@pipe-b-dp-4:
- shard-dg2: NOTRUN -> [SKIP][83] ([i915#4087]) +7 similar issues
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_cdclk@plane-scaling@pipe-b-dp-4.html
* igt@kms_chamelium_color@ctm-0-25:
- shard-dg2: NOTRUN -> [SKIP][84] ([fdo#111827])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_chamelium_color@ctm-0-25.html
* igt@kms_chamelium_color@ctm-negative:
- shard-glk: NOTRUN -> [SKIP][85] ([fdo#109271]) +14 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-glk9/igt@kms_chamelium_color@ctm-negative.html
* igt@kms_chamelium_color@ctm-red-to-blue:
- shard-mtlp: NOTRUN -> [SKIP][86] ([fdo#111827])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_chamelium_color@ctm-red-to-blue.html
* igt@kms_chamelium_edid@hdmi-mode-timings:
- shard-rkl: NOTRUN -> [SKIP][87] ([i915#7828]) +2 similar issues
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_chamelium_edid@hdmi-mode-timings.html
* igt@kms_chamelium_frames@dp-frame-dump:
- shard-dg2: NOTRUN -> [SKIP][88] ([i915#7828]) +1 similar issue
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_chamelium_frames@dp-frame-dump.html
* igt@kms_chamelium_hpd@vga-hpd-without-ddc:
- shard-mtlp: NOTRUN -> [SKIP][89] ([i915#7828]) +3 similar issues
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_chamelium_hpd@vga-hpd-without-ddc.html
* igt@kms_color@deep-color:
- shard-rkl: NOTRUN -> [SKIP][90] ([i915#3555]) +2 similar issues
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-6/igt@kms_color@deep-color.html
* igt@kms_content_protection@atomic:
- shard-rkl: NOTRUN -> [SKIP][91] ([i915#3555] / [i915#7118])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_content_protection@atomic.html
* igt@kms_content_protection@atomic@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [TIMEOUT][92] ([i915#7173]) +1 similar issue
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_content_protection@atomic@pipe-a-dp-4.html
* igt@kms_content_protection@dp-mst-type-0:
- shard-mtlp: NOTRUN -> [SKIP][93] ([i915#3299])
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_content_protection@dp-mst-type-0.html
* igt@kms_content_protection@lic:
- shard-dg2: NOTRUN -> [SKIP][94] ([i915#7118])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@kms_content_protection@lic.html
* igt@kms_content_protection@uevent@pipe-a-dp-2:
- shard-dg2: NOTRUN -> [FAIL][95] ([i915#1339])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-12/igt@kms_content_protection@uevent@pipe-a-dp-2.html
* igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- shard-mtlp: NOTRUN -> [SKIP][96] ([i915#3546]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-5/igt@kms_cursor_legacy@cursora-vs-flipb-legacy.html
* igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions:
- shard-mtlp: NOTRUN -> [SKIP][97] ([fdo#111767] / [i915#3546])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [PASS][98] -> [FAIL][99] ([i915#2346])
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@short-busy-flip-before-cursor-toggle:
- shard-rkl: NOTRUN -> [SKIP][100] ([i915#4103])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_cursor_legacy@short-busy-flip-before-cursor-toggle.html
* igt@kms_cursor_legacy@single-bo@all-pipes:
- shard-mtlp: [PASS][101] -> [DMESG-WARN][102] ([i915#2017])
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-6/igt@kms_cursor_legacy@single-bo@all-pipes.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-4/igt@kms_cursor_legacy@single-bo@all-pipes.html
* igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
- shard-mtlp: NOTRUN -> [SKIP][103] ([i915#3637])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-dg2: NOTRUN -> [SKIP][104] ([fdo#109274] / [fdo#111767])
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][105] -> [FAIL][106] ([i915#79])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-flip-vs-panning:
- shard-rkl: NOTRUN -> [SKIP][107] ([fdo#111825]) +1 similar issue
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_flip@2x-flip-vs-panning.html
* igt@kms_flip@flip-vs-suspend@b-dp1:
- shard-apl: [PASS][108] -> [DMESG-WARN][109] ([i915#7634])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-apl6/igt@kms_flip@flip-vs-suspend@b-dp1.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl3/igt@kms_flip@flip-vs-suspend@b-dp1.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling@pipe-a-default-mode:
- shard-mtlp: NOTRUN -> [SKIP][110] ([i915#2672])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling@pipe-a-default-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode:
- shard-rkl: NOTRUN -> [SKIP][111] ([i915#2672]) +1 similar issue
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-dg2: [PASS][112] -> [FAIL][113] ([i915#6880])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-blt:
- shard-dg2: NOTRUN -> [SKIP][114] ([i915#5354]) +10 similar issues
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt:
- shard-dg2: NOTRUN -> [SKIP][115] ([i915#8708]) +3 similar issues
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-rkl: NOTRUN -> [SKIP][116] ([fdo#111825] / [i915#1825]) +9 similar issues
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-plflip-blt:
- shard-dg2: NOTRUN -> [SKIP][117] ([i915#3458]) +1 similar issue
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-mtlp: NOTRUN -> [SKIP][118] ([i915#8708]) +4 similar issues
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-shrfb-draw-mmap-wc:
- shard-mtlp: NOTRUN -> [SKIP][119] ([i915#1825]) +13 similar issues
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-shrfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@psr-farfromfence-mmap-gtt:
- shard-rkl: NOTRUN -> [SKIP][120] ([i915#3023]) +3 similar issues
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_frontbuffer_tracking@psr-farfromfence-mmap-gtt.html
* igt@kms_hdr@invalid-metadata-sizes:
- shard-dg2: NOTRUN -> [SKIP][121] ([i915#3555] / [i915#8228])
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-7/igt@kms_hdr@invalid-metadata-sizes.html
* igt@kms_panel_fitting@atomic-fastset:
- shard-dg2: NOTRUN -> [SKIP][122] ([i915#3555]) +4 similar issues
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_panel_fitting@atomic-fastset.html
* igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c:
- shard-mtlp: NOTRUN -> [SKIP][123] ([fdo#109289]) +3 similar issues
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c.html
* igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][124] ([fdo#109271]) +29 similar issues
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-snb2/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1.html
* igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-edp-1:
- shard-mtlp: NOTRUN -> [SKIP][125] ([i915#5176]) +3 similar issues
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-edp-1.html
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-1:
- shard-rkl: NOTRUN -> [SKIP][126] ([i915#5176]) +3 similar issues
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-1.html
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-d-dp-4:
- shard-dg2: NOTRUN -> [SKIP][127] ([i915#5176]) +3 similar issues
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-d-dp-4.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-b-hdmi-a-1:
- shard-rkl: NOTRUN -> [SKIP][128] ([i915#5235]) +1 similar issue
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-b-hdmi-a-1.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-d-hdmi-a-3:
- shard-dg2: NOTRUN -> [SKIP][129] ([i915#5235]) +19 similar issues
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-6/igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-d-hdmi-a-3.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][130] ([fdo#109271]) +32 similar issues
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-c-dp-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf:
- shard-rkl: NOTRUN -> [SKIP][131] ([i915#658]) +1 similar issue
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf.html
* igt@kms_psr2_su@frontbuffer-xrgb8888:
- shard-rkl: NOTRUN -> [SKIP][132] ([fdo#111068] / [i915#658])
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_psr2_su@frontbuffer-xrgb8888.html
* igt@kms_psr2_su@page_flip-nv12:
- shard-mtlp: NOTRUN -> [SKIP][133] ([i915#4348])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_psr2_su@page_flip-nv12.html
* igt@kms_psr@cursor_blt:
- shard-dg2: NOTRUN -> [SKIP][134] ([i915#1072])
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_psr@cursor_blt.html
* igt@kms_psr@no_drrs:
- shard-rkl: NOTRUN -> [SKIP][135] ([i915#1072])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_psr@no_drrs.html
* igt@kms_setmode@basic@pipe-a-vga-1:
- shard-snb: NOTRUN -> [FAIL][136] ([i915#5465]) +1 similar issue
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-snb2/igt@kms_setmode@basic@pipe-a-vga-1.html
* igt@kms_setmode@invalid-clone-single-crtc:
- shard-rkl: NOTRUN -> [SKIP][137] ([i915#3555] / [i915#4098])
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_setmode@invalid-clone-single-crtc.html
* igt@kms_tiled_display@basic-test-pattern-with-chamelium:
- shard-mtlp: NOTRUN -> [SKIP][138] ([i915#8623])
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-dg2: [PASS][139] -> [FAIL][140] ([fdo#103375] / [i915#6121])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-d-query-forked-hang:
- shard-rkl: NOTRUN -> [SKIP][141] ([i915#4070] / [i915#533] / [i915#6768]) +1 similar issue
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_vblank@pipe-d-query-forked-hang.html
* igt@kms_vrr@flipline:
- shard-mtlp: NOTRUN -> [SKIP][142] ([i915#3555]) +1 similar issue
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@kms_vrr@flipline.html
* igt@kms_writeback@writeback-invalid-parameters:
- shard-mtlp: NOTRUN -> [SKIP][143] ([i915#2437]) +1 similar issue
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@kms_writeback@writeback-invalid-parameters.html
* igt@perf@global-sseu-config:
- shard-dg2: NOTRUN -> [SKIP][144] ([i915#7387])
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@perf@global-sseu-config.html
* igt@perf@non-zero-reason@0-rcs0:
- shard-dg2: [PASS][145] -> [FAIL][146] ([i915#7757])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-1/igt@perf@non-zero-reason@0-rcs0.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@perf@non-zero-reason@0-rcs0.html
* igt@perf_pmu@module-unload:
- shard-dg2: NOTRUN -> [FAIL][147] ([i915#5793] / [i915#6121])
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@perf_pmu@module-unload.html
* igt@prime_vgem@basic-fence-read:
- shard-mtlp: NOTRUN -> [SKIP][148] ([i915#3708])
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@prime_vgem@basic-fence-read.html
* igt@prime_vgem@fence-flip-hang:
- shard-rkl: NOTRUN -> [SKIP][149] ([fdo#109295] / [i915#3708])
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@prime_vgem@fence-flip-hang.html
* igt@sysfs_preempt_timeout@timeout@vecs0:
- shard-mtlp: NOTRUN -> [TIMEOUT][150] ([i915#7947])
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@sysfs_preempt_timeout@timeout@vecs0.html
* igt@v3d/v3d_job_submission@multiple-singlesync-to-multisync:
- shard-rkl: NOTRUN -> [SKIP][151] ([fdo#109315]) +2 similar issues
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@v3d/v3d_job_submission@multiple-singlesync-to-multisync.html
* igt@v3d/v3d_submit_cl@bad-bo:
- shard-dg2: NOTRUN -> [SKIP][152] ([i915#2575]) +2 similar issues
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@v3d/v3d_submit_cl@bad-bo.html
* igt@v3d/v3d_submit_csd@bad-multisync-pad:
- shard-mtlp: NOTRUN -> [SKIP][153] ([i915#2575]) +5 similar issues
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@v3d/v3d_submit_csd@bad-multisync-pad.html
* igt@vc4/vc4_purgeable_bo@access-purged-bo-mem:
- shard-mtlp: NOTRUN -> [SKIP][154] ([i915#7711]) +3 similar issues
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@vc4/vc4_purgeable_bo@access-purged-bo-mem.html
- shard-dg2: NOTRUN -> [SKIP][155] ([i915#7711]) +1 similar issue
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@vc4/vc4_purgeable_bo@access-purged-bo-mem.html
* igt@vc4/vc4_wait_bo@bad-bo:
- shard-rkl: NOTRUN -> [SKIP][156] ([i915#7711]) +1 similar issue
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@vc4/vc4_wait_bo@bad-bo.html
#### Possible fixes ####
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl: [FAIL][157] ([i915#7742]) -> [PASS][158]
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- shard-dg2: [ABORT][159] ([i915#7461] / [i915#8211] / [i915#8234]) -> [PASS][160]
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-12/igt@gem_barrier_race@remote-request@rcs0.html
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-5/igt@gem_barrier_race@remote-request@rcs0.html
* igt@gem_create@hog-create@smem0:
- shard-dg2: [FAIL][161] ([i915#5892] / [i915#8758]) -> [PASS][162]
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-6/igt@gem_create@hog-create@smem0.html
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-1/igt@gem_create@hog-create@smem0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglu: [FAIL][163] ([i915#6268]) -> [PASS][164]
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-tglu-8/igt@gem_ctx_exec@basic-nohangcheck.html
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-tglu-5/igt@gem_ctx_exec@basic-nohangcheck.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-mtlp: [ABORT][165] ([i915#8503]) -> [PASS][166]
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-1/igt@gem_eio@in-flight-contexts-immediate.html
[166]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl: [FAIL][167] ([i915#2842]) -> [PASS][168] +2 similar issues
[167]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-1/igt@gem_exec_fair@basic-pace@vecs0.html
[168]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-4/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_schedule@deep@vcs0:
- shard-mtlp: [FAIL][169] ([i915#8545]) -> [PASS][170] +1 similar issue
[169]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-1/igt@gem_exec_schedule@deep@vcs0.html
[170]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-4/igt@gem_exec_schedule@deep@vcs0.html
* igt@gem_exec_suspend@basic-s4-devices@lmem0:
- shard-dg2: [ABORT][171] ([i915#7975] / [i915#8213] / [i915#8682]) -> [PASS][172]
[171]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-1/igt@gem_exec_suspend@basic-s4-devices@lmem0.html
[172]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@gem_exec_suspend@basic-s4-devices@lmem0.html
* igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [ABORT][173] ([i915#8131]) -> [PASS][174]
[173]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-7/igt@gem_exec_whisper@basic-contexts-forked-all.html
[174]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-1/igt@gem_exec_whisper@basic-contexts-forked-all.html
* igt@gem_exec_whisper@basic-queues-all:
- shard-mtlp: [FAIL][175] ([i915#6363]) -> [PASS][176]
[175]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-2/igt@gem_exec_whisper@basic-queues-all.html
[176]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-5/igt@gem_exec_whisper@basic-queues-all.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- {shard-dg1}: [TIMEOUT][177] ([i915#5493]) -> [PASS][178]
[177]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg1-17/igt@gem_lmem_swapping@smem-oom@lmem0.html
[178]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg1-15/igt@gem_lmem_swapping@smem-oom@lmem0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [ABORT][179] ([i915#5566]) -> [PASS][180]
[179]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-glk8/igt@gen9_exec_parse@allowed-single.html
[180]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-glk9/igt@gen9_exec_parse@allowed-single.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-mtlp: [ABORT][181] ([i915#8489] / [i915#8668]) -> [PASS][182]
[181]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-6/igt@i915_module_load@reload-with-fault-injection.html
[182]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-3/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_dc@dc6-dpms:
- shard-tglu: [FAIL][183] ([i915#3989] / [i915#454]) -> [PASS][184]
[183]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-tglu-3/igt@i915_pm_dc@dc6-dpms.html
[184]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-tglu-9/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_rpm@modeset-lpsp:
- shard-dg2: [SKIP][185] ([i915#1397]) -> [PASS][186]
[185]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-7/igt@i915_pm_rpm@modeset-lpsp.html
[186]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-12/igt@i915_pm_rpm@modeset-lpsp.html
- shard-rkl: [SKIP][187] ([i915#1397]) -> [PASS][188] +2 similar issues
[187]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-2/igt@i915_pm_rpm@modeset-lpsp.html
[188]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@i915_pm_rpm@modeset-lpsp.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- {shard-dg1}: [SKIP][189] ([i915#1397]) -> [PASS][190] +1 similar issue
[189]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg1-19/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
[190]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg1-17/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-mtlp: [FAIL][191] ([i915#8248]) -> [PASS][192]
[191]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-2/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
[192]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-7/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [FAIL][193] ([i915#2346]) -> [PASS][194]
[193]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-apl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[194]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@dpms-vs-vblank-race@a-edp1:
- shard-mtlp: [DMESG-WARN][195] ([i915#1982]) -> [PASS][196]
[195]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-8/igt@kms_flip@dpms-vs-vblank-race@a-edp1.html
[196]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-5/igt@kms_flip@dpms-vs-vblank-race@a-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-apl: [ABORT][197] ([i915#180]) -> [PASS][198]
[197]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
[198]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
* igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-dg2: [FAIL][199] ([i915#6880]) -> [PASS][200]
[199]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-3/igt@kms_frontbuffer_tracking@fbc-badstride.html
[200]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-3/igt@kms_frontbuffer_tracking@fbc-badstride.html
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-dg2: [INCOMPLETE][201] ([i915#7838]) -> [PASS][202]
[201]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-1/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
[202]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-11/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
* igt@perf@enable-disable@0-rcs0:
- shard-dg2: [FAIL][203] ([i915#8724]) -> [PASS][204]
[203]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-11/igt@perf@enable-disable@0-rcs0.html
[204]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-7/igt@perf@enable-disable@0-rcs0.html
#### Warnings ####
* igt@i915_module_load@reload-with-fault-injection:
- shard-dg2: [WARN][205] ([i915#6596] / [i915#7356]) -> [DMESG-WARN][206] ([i915#7061])
[205]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-11/igt@i915_module_load@reload-with-fault-injection.html
[206]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-7/igt@i915_module_load@reload-with-fault-injection.html
* igt@kms_content_protection@atomic-dpms@pipe-a-dp-1:
- shard-apl: [TIMEOUT][207] ([i915#7173]) -> [FAIL][208] ([i915#7173])
[207]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-apl6/igt@kms_content_protection@atomic-dpms@pipe-a-dp-1.html
[208]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-apl3/igt@kms_content_protection@atomic-dpms@pipe-a-dp-1.html
* igt@kms_content_protection@content_type_change:
- shard-dg2: [SKIP][209] ([i915#3555] / [i915#7118] / [i915#7162]) -> [SKIP][210] ([i915#3555] / [i915#7118])
[209]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-11/igt@kms_content_protection@content_type_change.html
[210]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-7/igt@kms_content_protection@content_type_change.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- shard-dg2: [SKIP][211] ([i915#4103] / [i915#4213]) -> [TIMEOUT][212] ([i915#8197])
[211]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-dg2-12/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
[212]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-dg2-1/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-mtlp: [FAIL][213] ([i915#2346]) -> [DMESG-FAIL][214] ([i915#2017] / [i915#5954])
[213]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-5/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[214]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-rkl: [SKIP][215] ([i915#3955]) -> [SKIP][216] ([fdo#110189] / [i915#3955])
[215]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-6/igt@kms_fbcon_fbt@psr-suspend.html
[216]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-2/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- shard-rkl: [SKIP][217] ([fdo#109285] / [i915#4098]) -> [SKIP][218] ([fdo#109285])
[217]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-rkl-2/igt@kms_force_connector_basic@force-load-detect.html
[218]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-rkl-7/igt@kms_force_connector_basic@force-load-detect.html
* igt@sysfs_timeslice_duration@timeout@vecs0:
- shard-mtlp: [TIMEOUT][219] ([i915#6950]) -> [ABORT][220] ([i915#8521])
[219]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13346/shard-mtlp-6/igt@sysfs_timeslice_duration@timeout@vecs0.html
[220]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v1/shard-mtlp-4/igt@sysfs_timeslice_duration@timeout@vecs0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111767]: https://bugs.freedesktop.org/show_bug.cgi?id=111767
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1339]: https://gitlab.freedesktop.org/drm/intel/issues/1339
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1937]: https://gitlab.freedesktop.org/drm/intel/issues/1937
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2017]: https://gitlab.freedesktop.org/drm/intel/issues/2017
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
[i915#3023]: https://gitlab.freedesktop.org/drm/intel/issues/3023
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989
[i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4087]: https://gitlab.freedesktop.org/drm/intel/issues/4087
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4348]: https://gitlab.freedesktop.org/drm/intel/issues/4348
[i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
[i915#4880]: https://gitlab.freedesktop.org/drm/intel/issues/4880
[i915#4885]: https://gitlab.freedesktop.org/drm/intel/issues/4885
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5138]: https://gitlab.freedesktop.org/drm/intel/issues/5138
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5465]: https://gitlab.freedesktop.org/drm/intel/issues/5465
[i915#5493]: https://gitlab.freedesktop.org/drm/intel/issues/5493
[i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#5793]: https://gitlab.freedesktop.org/drm/intel/issues/5793
[i915#5889]: https://gitlab.freedesktop.org/drm/intel/issues/5889
[i915#5892]: https://gitlab.freedesktop.org/drm/intel/issues/5892
[i915#5954]: https://gitlab.freedesktop.org/drm/intel/issues/5954
[i915#6032]: https://gitlab.freedesktop.org/drm/intel/issues/6032
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
[i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
[i915#6334]: https://gitlab.freedesktop.org/drm/intel/issues/6334
[i915#6363]: https://gitlab.freedesktop.org/drm/intel/issues/6363
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6768]: https://gitlab.freedesktop.org/drm/intel/issues/6768
[i915#6880]: https://gitlab.freedesktop.org/drm/intel/issues/6880
[i915#6950]: https://gitlab.freedesktop.org/drm/intel/issues/6950
[i915#7061]: https://gitlab.freedesktop.org/drm/intel/issues/7061
[i915#7091]: https://gitlab.freedesktop.org/drm/intel/issues/7091
[i915#7118]: https://gitlab.freedesktop.org/drm/intel/issues/7118
[i915#7162]: https://gitlab.freedesktop.org/drm/intel/issues/7162
[i915#7173]: https://gitlab.freedesktop.org/drm/intel/issues/7173
[i915#7356]: https://gitlab.freedesktop.org/drm/intel/issues/7356
[i915#7387]: https://gitlab.freedesktop.org/drm/intel/issues/7387
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7634]: https://gitlab.freedesktop.org/drm/intel/issues/7634
[i915#7711]: https://gitlab.freedesktop.org/drm/intel/issues/7711
[i915#7742]: https://gitlab.freedesktop.org/drm/intel/issues/7742
[i915#7757]: https://gitlab.freedesktop.org/drm/intel/issues/7757
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7838]: https://gitlab.freedesktop.org/drm/intel/issues/7838
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#7947]: https://gitlab.freedesktop.org/drm/intel/issues/7947
[i915#7975]: https://gitlab.freedesktop.org/drm/intel/issues/7975
[i915#8018]: https://gitlab.freedesktop.org/drm/intel/issues/8018
[i915#8131]: https://gitlab.freedesktop.org/drm/intel/issues/8131
[i915#8197]: https://gitlab.freedesktop.org/drm/intel/issues/8197
[i915#8211]: https://gitlab.freedesktop.org/drm/intel/issues/8211
[i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
[i915#8228]: https://gitlab.freedesktop.org/drm/intel/issues/8228
[i915#8234]: https://gitlab.freedesktop.org/drm/intel/issues/8234
[i915#8247]: https://gitlab.freedesktop.org/drm/intel/issues/8247
[i915#8248]: https://gitlab.freedesktop.org/drm/intel/issues/8248
[i915#8292]: https://gitlab.freedesktop.org/drm/intel/issues/8292
[i915#8295]: https://gitlab.freedesktop.org/drm/intel/issues/8295
[i915#8403]: https://gitlab.freedesktop.org/drm/intel/issues/8403
[i915#8414]: https://gitlab.freedesktop.org/drm/intel/issues/8414
[i915#8428]: https://gitlab.freedesktop.org/drm/intel/issues/8428
[i915#8489]: https://gitlab.freedesktop.org/drm/intel/issues/8489
[i915#8502]: https://gitlab.freedesktop.org/drm/intel/issues/8502
[i915#8503]: https://gitlab.freedesktop.org/drm/intel/issues/8503
[i915#8521]: https://gitlab.freedesktop.org/drm/intel/issues/8521
[i915#8545]: https://gitlab.freedesktop.org/drm/intel/issues/8545
[i915#8555]: https://gitlab.freedesktop.org/drm/intel/issues/8555
[i915#8623]: https://gitlab.freedesktop.org/drm/intel/issues/8623
[i915#8661]: https://gitlab.freedesktop.org/drm/intel/issues/8661
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8682]: https://gitlab.freedesktop.org/drm/intel/issues/8682
[i915#8708]: https://gitlab.freedesktop.org/drm/intel/issues/8708
[i915#8724]: https://gitlab.freedesktop.org/drm/intel/issues/8724
[i915#8758]: https://gitlab.freedesktop.org/drm/intel/issues/8758
Build changes
-------------
* Linux: CI_DRM_13346 -> Patchwork_120238v1
CI-20190529: 20190529
CI_DRM_13346: c5442b2363bf5ad916805d105ff03ce5805070e5 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7370: f63ab5e7c3ddef724bebde558e36647ca65d98bc @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120238v1: c5442b2363bf5ad916805d105ff03ce5805070e5 @ 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_120238v1/index.html
[-- Attachment #2: Type: text/html, Size: 70838 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
` (2 preceding siblings ...)
2023-07-05 19:11 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2023-07-06 15:16 ` Andrzej Hajda
2023-07-07 8:05 ` Nirmoy Das
2023-07-11 10:18 ` Andi Shyti
2023-07-06 20:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: update request engine before removing virtual GuC engine (rev2) Patchwork
` (2 subsequent siblings)
6 siblings, 2 replies; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-06 15:16 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson, Andrzej Hajda, Nirmoy Das
GuC virtual engines can be removed before request removal. On the other
side driver expects rq->engine to be a valid pointer for a whole life of
request. Setting rq->engine to an always valid engine should solve
the issue.
The patch fixes bug detected by KASAN with following signature:
i915 0000:00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 0x0000005c [0x0000005c]
BUG: KASAN: slab-use-after-free in i915_fence_release+0x2a2/0x2f0 [i915]
Read of size 4 at addr ffff88813ffda6e8 by task kworker/u32:10/157
...
Allocated by task 1184:
...
guc_create_virtual+0x4d/0x1160 [i915]
i915_gem_create_context+0x11ee/0x18c0 [i915]
...
Freed by task 151:
...
intel_guc_deregister_done_process_msg+0x324/0x6d0 [i915]
...
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7926
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d246..2c877ea5eda6f0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
static void remove_from_context(struct i915_request *rq)
{
struct intel_context *ce = request_to_scheduling_context(rq);
+ struct intel_engine_cs *engine;
+ intel_engine_mask_t tmp;
GEM_BUG_ON(intel_context_is_child(ce));
@@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
atomic_dec(&ce->guc_id.ref);
i915_request_notify_execute_cb_imm(rq);
+
+ /*
+ * GuC virtual engine can disappear after this call, so let's assign
+ * something valid, as driver expects this to be always valid pointer.
+ */
+ for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
+ rq->engine = engine;
+ break;
+ }
}
static const struct intel_context_ops guc_context_ops = {
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
` (3 preceding siblings ...)
2023-07-06 15:16 ` [Intel-gfx] [PATCH v2] " Andrzej Hajda
@ 2023-07-06 20:01 ` Patchwork
2023-07-06 20:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-07 2:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
6 siblings, 0 replies; 30+ messages in thread
From: Patchwork @ 2023-07-06 20:01 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
URL : https://patchwork.freedesktop.org/series/120238/
State : warning
== Summary ==
Error: dim checkpatch failed
35bc390bc9f2 drm/i915/gt: update request engine before removing virtual GuC engine
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#13:
i915 0000:00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 0x0000005c [0x0000005c]
total: 0 errors, 1 warnings, 0 checks, 23 lines checked
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
` (4 preceding siblings ...)
2023-07-06 20:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: update request engine before removing virtual GuC engine (rev2) Patchwork
@ 2023-07-06 20:13 ` Patchwork
2023-07-07 2:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
6 siblings, 0 replies; 30+ messages in thread
From: Patchwork @ 2023-07-06 20:13 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5363 bytes --]
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
URL : https://patchwork.freedesktop.org/series/120238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13351 -> Patchwork_120238v2
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/index.html
Participating hosts (40 -> 39)
------------------------------
Additional (1): fi-pnv-d510
Missing (2): fi-kbl-soraka fi-snb-2520m
Known issues
------------
Here are the changes found in Patchwork_120238v2 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live@hangcheck:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#7677])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-rpls-1/igt@i915_selftest@live@hangcheck.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-rpls-1/igt@i915_selftest@live@hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1:
- fi-kbl-7567u: [PASS][3] -> [ABORT][4] ([i915#8218])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/fi-kbl-7567u/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510: NOTRUN -> [SKIP][5] ([fdo#109271]) +38 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
* igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: NOTRUN -> [ABORT][6] ([i915#8442] / [i915#8668] / [i915#8712])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
#### Possible fixes ####
* igt@i915_selftest@live@gt_heartbeat:
- bat-dg2-9: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-dg2-9/igt@i915_selftest@live@gt_heartbeat.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-dg2-9/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [DMESG-FAIL][9] ([i915#7699] / [i915#7913]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-atsm-1/igt@i915_selftest@live@migrate.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-atsm-1/igt@i915_selftest@live@migrate.html
* igt@i915_selftest@live@mman:
- bat-rpls-2: [TIMEOUT][11] ([i915#6794] / [i915#7392]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-rpls-2/igt@i915_selftest@live@mman.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-rpls-2/igt@i915_selftest@live@mman.html
#### Warnings ####
* igt@i915_module_load@load:
- bat-adlp-11: [DMESG-WARN][13] ([i915#4423]) -> [ABORT][14] ([i915#4423])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-adlp-11/igt@i915_module_load@load.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-adlp-11/igt@i915_module_load@load.html
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [ABORT][15] ([i915#8434]) -> [SKIP][16] ([i915#1072])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#4423]: https://gitlab.freedesktop.org/drm/intel/issues/4423
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392
[i915#7677]: https://gitlab.freedesktop.org/drm/intel/issues/7677
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#8218]: https://gitlab.freedesktop.org/drm/intel/issues/8218
[i915#8434]: https://gitlab.freedesktop.org/drm/intel/issues/8434
[i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8712]: https://gitlab.freedesktop.org/drm/intel/issues/8712
Build changes
-------------
* Linux: CI_DRM_13351 -> Patchwork_120238v2
CI-20190529: 20190529
CI_DRM_13351: c5262da740fe00ef30394118a108dcf0723a0318 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7376: 38af51c0ce6d9573793f53fc32782b77061bf169 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120238v2: c5262da740fe00ef30394118a108dcf0723a0318 @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
f8aee366be17 drm/i915/gt: update request engine before removing virtual GuC engine
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/index.html
[-- Attachment #2: Type: text/html, Size: 6328 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
` (5 preceding siblings ...)
2023-07-06 20:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2023-07-07 2:52 ` Patchwork
2023-07-10 12:51 ` Andrzej Hajda
6 siblings, 1 reply; 30+ messages in thread
From: Patchwork @ 2023-07-07 2:52 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 43226 bytes --]
== Series Details ==
Series: drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
URL : https://patchwork.freedesktop.org/series/120238/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13351_full -> Patchwork_120238v2_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_120238v2_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_120238v2_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (9 -> 10)
------------------------------
Additional (1): shard-tglu0
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_120238v2_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_reloc@basic-wc-cpu-active:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] +4 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@gem_exec_reloc@basic-wc-cpu-active.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@gem_exec_reloc@basic-wc-cpu-active.html
* igt@kms_plane_multiple@tiling-y:
- shard-dg2: NOTRUN -> [SKIP][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_plane_multiple@tiling-y.html
New tests
---------
New tests have been introduced between CI_DRM_13351_full and Patchwork_120238v2_full:
### New IGT tests (34) ###
* igt@gem_exec_basic@basic@bcs0-lmem0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@gem_exec_basic@basic@rcs0-lmem0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@gem_exec_basic@basic@vcs0-lmem0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@gem_exec_basic@basic@vcs1-lmem0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@gem_exec_basic@basic@vecs0-lmem0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-blocking-absolute-wf_vblank@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-blocking-wf_vblank@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-dpms-vs-vblank-race@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-flip-vs-panning-interruptible@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@2x-plain-flip-ts-check@ab-vga1-hdmi-a1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@basic-flip-vs-dpms@d-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@blocking-absolute-wf_vblank@d-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@bo-too-big@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@bo-too-big@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@bo-too-big@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-expired-vblank-interruptible@d-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-panning-vs-hang@d-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-panning@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-panning@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-panning@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-suspend@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-suspend@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@flip-vs-suspend@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@modeset-vs-vblank-race-interruptible@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@modeset-vs-vblank-race-interruptible@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@modeset-vs-vblank-race-interruptible@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@nonexisting-fb-interruptible@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@nonexisting-fb-interruptible@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@nonexisting-fb-interruptible@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@nonexisting-fb@d-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate@a-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate@b-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate@c-dp2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
Known issues
------------
Here are the changes found in Patchwork_120238v2_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@drm_fdinfo@busy-hang@bcs0:
- shard-dg2: NOTRUN -> [SKIP][4] ([i915#8414]) +10 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@drm_fdinfo@busy-hang@bcs0.html
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl: [PASS][5] -> [FAIL][6] ([i915#7742])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-mtlp: [PASS][7] -> [ABORT][8] ([i915#8503])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-7/igt@gem_eio@in-flight-contexts-immediate.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-2/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_exec_balancer@bonded-pair:
- shard-dg2: NOTRUN -> [SKIP][9] ([i915#4771])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_balancer@bonded-pair.html
* igt@gem_exec_balancer@full-pulse:
- shard-dg2: [PASS][10] -> [FAIL][11] ([i915#6032]) +1 similar issue
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@gem_exec_balancer@full-pulse.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-8/igt@gem_exec_balancer@full-pulse.html
* igt@gem_exec_balancer@sliced:
- shard-dg2: NOTRUN -> [SKIP][12] ([i915#4812])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_balancer@sliced.html
* igt@gem_exec_fair@basic-none-rrul:
- shard-dg2: NOTRUN -> [SKIP][13] ([i915#3539] / [i915#4852])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_fair@basic-none-rrul.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_reloc@basic-wc:
- shard-dg2: NOTRUN -> [SKIP][16] ([i915#3281]) +3 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_reloc@basic-wc.html
* igt@gem_exec_schedule@deep@vcs0:
- shard-mtlp: [PASS][17] -> [FAIL][18] ([i915#8545])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@gem_exec_schedule@deep@vcs0.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-4/igt@gem_exec_schedule@deep@vcs0.html
* igt@gem_exec_schedule@preempt-queue:
- shard-dg2: NOTRUN -> [SKIP][19] ([i915#4537] / [i915#4812])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_schedule@preempt-queue.html
* igt@gem_fence_thrash@bo-write-verify-y:
- shard-dg2: NOTRUN -> [SKIP][20] ([i915#4860]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_fence_thrash@bo-write-verify-y.html
* igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-glk: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@gem_lmem_swapping@parallel-random-verify-ccs.html
* igt@gem_mmap_wc@pf-nonblock:
- shard-dg2: NOTRUN -> [SKIP][22] ([i915#4083])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_mmap_wc@pf-nonblock.html
* igt@gem_pwrite@basic-exhaustion:
- shard-snb: NOTRUN -> [WARN][23] ([i915#2658])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@gem_pwrite@basic-exhaustion.html
* igt@gem_spin_batch@spin-each:
- shard-apl: [PASS][24] -> [FAIL][25] ([i915#2898])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl3/igt@gem_spin_batch@spin-each.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl2/igt@gem_spin_batch@spin-each.html
* igt@gem_tiled_pread_basic:
- shard-dg2: NOTRUN -> [SKIP][26] ([i915#4079])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_tiled_pread_basic.html
* igt@gem_userptr_blits@forbidden-operations:
- shard-dg2: NOTRUN -> [SKIP][27] ([i915#3282]) +1 similar issue
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_userptr_blits@forbidden-operations.html
* igt@gem_userptr_blits@unsync-unmap-after-close:
- shard-dg2: NOTRUN -> [SKIP][28] ([i915#3297])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_userptr_blits@unsync-unmap-after-close.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][29] -> [ABORT][30] ([i915#5566])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl7/igt@gen9_exec_parse@allowed-all.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl4/igt@gen9_exec_parse@allowed-all.html
* igt@gen9_exec_parse@batch-invalid-length:
- shard-dg2: NOTRUN -> [SKIP][31] ([i915#2856])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gen9_exec_parse@batch-invalid-length.html
* igt@gen9_exec_parse@unaligned-jump:
- shard-mtlp: NOTRUN -> [SKIP][32] ([i915#2856])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@gen9_exec_parse@unaligned-jump.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- shard-dg2: [PASS][33] -> [SKIP][34] ([i915#1397])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-12/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-rkl: [PASS][35] -> [SKIP][36] ([i915#1397]) +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-4/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
* igt@i915_pm_sseu@full-enable:
- shard-dg2: NOTRUN -> [SKIP][37] ([i915#4387])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_pm_sseu@full-enable.html
* igt@i915_selftest@live@hangcheck:
- shard-dg2: NOTRUN -> [ABORT][38] ([i915#7913])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_selftest@live@hangcheck.html
* igt@i915_suspend@fence-restore-untiled:
- shard-dg2: NOTRUN -> [SKIP][39] ([i915#4077]) +7 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_suspend@fence-restore-untiled.html
* igt@kms_big_fb@4-tiled-16bpp-rotate-270:
- shard-dg2: NOTRUN -> [SKIP][40] ([fdo#111614]) +1 similar issue
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@4-tiled-16bpp-rotate-270.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][41] ([fdo#109271]) +62 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-mtlp: [PASS][42] -> [FAIL][43] ([i915#5138])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-5/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-addfb-size-overflow:
- shard-dg2: NOTRUN -> [SKIP][44] ([i915#5190]) +2 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@yf-tiled-addfb-size-overflow.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- shard-dg2: NOTRUN -> [SKIP][45] ([i915#4538] / [i915#5190]) +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][46] ([fdo#109271] / [i915#3886]) +1 similar issue
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc:
- shard-mtlp: NOTRUN -> [SKIP][47] ([i915#6095])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs:
- shard-dg2: NOTRUN -> [SKIP][48] ([i915#3689] / [i915#5354]) +8 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-dg2: NOTRUN -> [SKIP][49] ([i915#3689] / [i915#3886] / [i915#5354]) +5 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-ccs-on-another-bo-4_tiled_mtl_rc_ccs:
- shard-dg2: NOTRUN -> [SKIP][50] ([i915#5354]) +15 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-d-ccs-on-another-bo-4_tiled_mtl_rc_ccs.html
* igt@kms_cdclk@mode-transition@pipe-d-dp-4:
- shard-dg2: NOTRUN -> [SKIP][51] ([i915#4087]) +3 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cdclk@mode-transition@pipe-d-dp-4.html
* igt@kms_chamelium_color@ctm-0-75:
- shard-dg2: NOTRUN -> [SKIP][52] ([fdo#111827])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_chamelium_color@ctm-0-75.html
* igt@kms_chamelium_hpd@vga-hpd-without-ddc:
- shard-dg2: NOTRUN -> [SKIP][53] ([i915#7828]) +1 similar issue
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_chamelium_hpd@vga-hpd-without-ddc.html
* igt@kms_content_protection@legacy@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [TIMEOUT][54] ([i915#7173])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_content_protection@legacy@pipe-a-dp-4.html
* igt@kms_content_protection@lic:
- shard-dg2: NOTRUN -> [SKIP][55] ([i915#7118])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_content_protection@lic.html
* igt@kms_content_protection@uevent@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [FAIL][56] ([i915#1339])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_content_protection@uevent@pipe-a-dp-4.html
* igt@kms_cursor_crc@cursor-rapid-movement-512x170:
- shard-dg2: NOTRUN -> [SKIP][57] ([i915#3359])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cursor_crc@cursor-rapid-movement-512x170.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size:
- shard-dg2: NOTRUN -> [SKIP][58] ([fdo#109274] / [i915#5354]) +1 similar issue
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][59] -> [FAIL][60] ([i915#2346])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@2x-busy-flip:
- shard-dg2: NOTRUN -> [SKIP][61] ([fdo#109274])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_flip@2x-busy-flip.html
* igt@kms_flip@2x-flip-vs-dpms:
- shard-mtlp: NOTRUN -> [SKIP][62] ([i915#3637])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_flip@2x-flip-vs-dpms.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][63] -> [FAIL][64] ([i915#79])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-mtlp: [PASS][65] -> [FAIL][66] ([i915#79])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-4/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-dg2: [PASS][67] -> [FAIL][68] ([i915#6880]) +1 similar issue
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-dg2: NOTRUN -> [SKIP][69] ([i915#8708]) +10 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-render:
- shard-mtlp: NOTRUN -> [SKIP][70] ([i915#1825]) +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu:
- shard-dg2: NOTRUN -> [SKIP][71] ([i915#3458]) +4 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html
* igt@kms_hdr@bpc-switch:
- shard-rkl: NOTRUN -> [SKIP][72] ([i915#3555])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@kms_hdr@bpc-switch.html
* igt@kms_plane@plane-panning-top-left@pipe-a-planes:
- shard-apl: [PASS][73] -> [DMESG-WARN][74] ([i915#180] / [i915#8585]) +5 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@kms_plane@plane-panning-top-left@pipe-a-planes.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@kms_plane@plane-panning-top-left@pipe-a-planes.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][75] ([i915#7862]) +1 similar issue
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@kms_plane_alpha_blend@alpha-basic@pipe-a-hdmi-a-1.html
* igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-2:
- shard-rkl: NOTRUN -> [SKIP][76] ([i915#5176]) +3 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-2.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [SKIP][77] ([i915#5235]) +7 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-dp-4.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-a-hdmi-a-1:
- shard-rkl: NOTRUN -> [SKIP][78] ([i915#5235]) +3 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-a-hdmi-a-1.html
* igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1:
- shard-apl: [PASS][79] -> [DMESG-WARN][80] ([i915#180]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1.html
* igt@kms_prime@basic-crc-hybrid:
- shard-dg2: NOTRUN -> [SKIP][81] ([i915#6524] / [i915#6805])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_prime@basic-crc-hybrid.html
* igt@kms_psr@psr2_primary_blt:
- shard-dg2: NOTRUN -> [SKIP][82] ([i915#1072]) +2 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_psr@psr2_primary_blt.html
* igt@kms_rotation_crc@primary-y-tiled-reflect-x-270:
- shard-rkl: [PASS][83] -> [ABORT][84] ([i915#7461] / [i915#8178])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-4/igt@kms_rotation_crc@primary-y-tiled-reflect-x-270.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_rotation_crc@primary-y-tiled-reflect-x-270.html
* igt@kms_setmode@basic@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [FAIL][85] ([i915#5465]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb1/igt@kms_setmode@basic@pipe-a-hdmi-a-1.html
* igt@kms_sysfs_edid_timing:
- shard-dg2: [PASS][86] -> [FAIL][87] ([IGT#2])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@kms_sysfs_edid_timing.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_sysfs_edid_timing.html
* igt@kms_vrr@flip-suspend:
- shard-snb: NOTRUN -> [SKIP][88] ([fdo#109271]) +117 similar issues
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@kms_vrr@flip-suspend.html
* igt@perf@global-sseu-config-invalid:
- shard-dg2: NOTRUN -> [SKIP][89] ([i915#7387])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@perf@global-sseu-config-invalid.html
* igt@perf@per-context-mode-unprivileged:
- shard-dg2: NOTRUN -> [SKIP][90] ([fdo#109289]) +1 similar issue
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@perf@per-context-mode-unprivileged.html
* igt@prime_vgem@coherency-blt:
- shard-mtlp: NOTRUN -> [FAIL][91] ([i915#8445])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@prime_vgem@coherency-blt.html
* igt@prime_vgem@fence-read-hang:
- shard-dg2: NOTRUN -> [SKIP][92] ([i915#3708])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@prime_vgem@fence-read-hang.html
* igt@v3d/v3d_submit_csd@multiple-job-submission:
- shard-dg2: NOTRUN -> [SKIP][93] ([i915#2575]) +3 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@v3d/v3d_submit_csd@multiple-job-submission.html
* igt@vc4/vc4_label_bo@set-kernel-name:
- shard-dg2: NOTRUN -> [SKIP][94] ([i915#7711]) +3 similar issues
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@vc4/vc4_label_bo@set-kernel-name.html
#### Possible fixes ####
* igt@gem_create@hog-create@smem0:
- shard-dg2: [FAIL][95] ([i915#5892] / [i915#8758]) -> [PASS][96]
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@gem_create@hog-create@smem0.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-8/igt@gem_create@hog-create@smem0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglu: [FAIL][97] ([i915#6268]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-tglu-2/igt@gem_ctx_exec@basic-nohangcheck.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-tglu-6/igt@gem_ctx_exec@basic-nohangcheck.html
* igt@gem_eio@kms:
- {shard-dg1}: [FAIL][99] ([i915#5784]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-13/igt@gem_eio@kms.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-15/igt@gem_eio@kms.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: [FAIL][101] ([i915#2842]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk6/igt@gem_exec_fair@basic-pace@rcs0.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk2/igt@gem_exec_fair@basic-pace@rcs0.html
* igt@gem_exec_schedule@pi-distinct-iova@vcs1:
- shard-dg2: [DMESG-WARN][103] ([i915#8585]) -> [PASS][104] +3 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@gem_exec_schedule@pi-distinct-iova@vcs1.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_schedule@pi-distinct-iova@vcs1.html
* igt@gem_exec_whisper@basic-contexts-all:
- shard-mtlp: [FAIL][105] ([i915#6363]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-all.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-all.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- {shard-dg1}: [TIMEOUT][107] ([i915#5493]) -> [PASS][108]
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-12/igt@gem_lmem_swapping@smem-oom@lmem0.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-18/igt@gem_lmem_swapping@smem-oom@lmem0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [ABORT][109] ([i915#5566]) -> [PASS][110] +1 similar issue
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk7/igt@gen9_exec_parse@allowed-all.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pipe_stress@stress-xrgb8888-untiled:
- shard-mtlp: [FAIL][111] ([i915#8691]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html
* igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}: [FAIL][113] ([i915#3591]) -> [PASS][114] +1 similar issue
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-17/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html
* igt@i915_pm_rpm@modeset-lpsp:
- shard-rkl: [SKIP][115] ([i915#1397]) -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-1/igt@i915_pm_rpm@modeset-lpsp.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@i915_pm_rpm@modeset-lpsp.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-dg1}: [SKIP][117] ([i915#1397]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-19/igt@i915_pm_rpm@modeset-non-lpsp.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-16/igt@i915_pm_rpm@modeset-non-lpsp.html
* igt@i915_pm_rps@reset:
- shard-snb: [INCOMPLETE][119] ([i915#7790]) -> [PASS][120]
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-snb4/igt@i915_pm_rps@reset.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@i915_pm_rps@reset.html
* igt@i915_suspend@forcewake:
- shard-dg2: [FAIL][121] ([fdo#103375] / [i915#6121]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@i915_suspend@forcewake.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-2/igt@i915_suspend@forcewake.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
- shard-mtlp: [FAIL][123] ([i915#5138]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-mtlp: [FAIL][125] ([i915#3743]) -> [PASS][126] +2 similar issues
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1:
- shard-mtlp: [DMESG-WARN][127] ([i915#1982]) -> [PASS][128]
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-5/igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1.html
* igt@perf@non-zero-reason@0-rcs0:
- shard-dg2: [FAIL][129] ([i915#7484]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-2/igt@perf@non-zero-reason@0-rcs0.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-2/igt@perf@non-zero-reason@0-rcs0.html
#### Warnings ####
* igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [FAIL][131] ([i915#6363]) -> [ABORT][132] ([i915#8131])
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-2/igt@gem_exec_whisper@basic-contexts-forked-all.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@gem_exec_whisper@basic-contexts-forked-all.html
* igt@kms_async_flips@crc@pipe-a-edp-1:
- shard-mtlp: [FAIL][133] ([i915#8247]) -> [DMESG-FAIL][134] ([i915#1982] / [i915#8561])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@kms_async_flips@crc@pipe-a-edp-1.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_async_flips@crc@pipe-a-edp-1.html
* igt@kms_async_flips@crc@pipe-d-edp-1:
- shard-mtlp: [FAIL][135] ([i915#8247]) -> [DMESG-FAIL][136] ([i915#8561]) +2 similar issues
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@kms_async_flips@crc@pipe-d-edp-1.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_async_flips@crc@pipe-d-edp-1.html
* igt@kms_content_protection@type1:
- shard-dg2: [SKIP][137] ([i915#7118] / [i915#7162]) -> [SKIP][138] ([i915#7118])
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@kms_content_protection@type1.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_content_protection@type1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-mtlp: [FAIL][139] ([i915#2346]) -> [DMESG-FAIL][140] ([i915#1982] / [i915#2017] / [i915#5954])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-rkl: [SKIP][141] ([i915#3955]) -> [SKIP][142] ([fdo#110189] / [i915#3955]) +1 similar issue
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@kms_fbcon_fbt@psr-suspend.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-2/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- shard-rkl: [SKIP][143] ([fdo#109285]) -> [SKIP][144] ([fdo#109285] / [i915#4098])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@kms_force_connector_basic@force-load-detect.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_force_connector_basic@force-load-detect.html
* igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem:
- shard-dg2: [INCOMPLETE][145] ([i915#5493]) -> [CRASH][146] ([i915#7331])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#2]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/2
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1339]: https://gitlab.freedesktop.org/drm/intel/issues/1339
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2017]: https://gitlab.freedesktop.org/drm/intel/issues/2017
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
[i915#2898]: https://gitlab.freedesktop.org/drm/intel/issues/2898
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3743]: https://gitlab.freedesktop.org/drm/intel/issues/3743
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4087]: https://gitlab.freedesktop.org/drm/intel/issues/4087
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4387]: https://gitlab.freedesktop.org/drm/intel/issues/4387
[i915#4537]: https://gitlab.freedesktop.org/drm/intel/issues/4537
[i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4771]: https://gitlab.freedesktop.org/drm/intel/issues/4771
[i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
[i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
[i915#4860]: https://gitlab.freedesktop.org/drm/intel/issues/4860
[i915#5138]: https://gitlab.freedesktop.org/drm/intel/issues/5138
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5465]: https://gitlab.freedesktop.org/drm/intel/issues/5465
[i915#5493]: https://gitlab.freedesktop.org/drm/intel/issues/5493
[i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#5892]: https://gitlab.freedesktop.org/drm/intel/issues/5892
[i915#5954]: https://gitlab.freedesktop.org/drm/intel/issues/5954
[i915#6032]: https://gitlab.freedesktop.org/drm/intel/issues/6032
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
[i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
[i915#6363]: https://gitlab.freedesktop.org/drm/intel/issues/6363
[i915#6524]: https://gitlab.freedesktop.org/drm/intel/issues/6524
[i915#6805]: https://gitlab.freedesktop.org/drm/intel/issues/6805
[i915#6880]: https://gitlab.freedesktop.org/drm/intel/issues/6880
[i915#7118]: https://gitlab.freedesktop.org/drm/intel/issues/7118
[i915#7162]: https://gitlab.freedesktop.org/drm/intel/issues/7162
[i915#7173]: https://gitlab.freedesktop.org/drm/intel/issues/7173
[i915#7331]: https://gitlab.freedesktop.org/drm/intel/issues/7331
[i915#7387]: https://gitlab.freedesktop.org/drm/intel/issues/7387
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7484]: https://gitlab.freedesktop.org/drm/intel/issues/7484
[i915#7711]: https://gitlab.freedesktop.org/drm/intel/issues/7711
[i915#7742]: https://gitlab.freedesktop.org/drm/intel/issues/7742
[i915#7790]: https://gitlab.freedesktop.org/drm/intel/issues/7790
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7862]: https://gitlab.freedesktop.org/drm/intel/issues/7862
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#8131]: https://gitlab.freedesktop.org/drm/intel/issues/8131
[i915#8178]: https://gitlab.freedesktop.org/drm/intel/issues/8178
[i915#8247]: https://gitlab.freedesktop.org/drm/intel/issues/8247
[i915#8292]: https://gitlab.freedesktop.org/drm/intel/issues/8292
[i915#8414]: https://gitlab.freedesktop.org/drm/intel/issues/8414
[i915#8445]: https://gitlab.freedesktop.org/drm/intel/issues/8445
[i915#8503]: https://gitlab.freedesktop.org/drm/intel/issues/8503
[i915#8545]: https://gitlab.freedesktop.org/drm/intel/issues/8545
[i915#8561]: https://gitlab.freedesktop.org/drm/intel/issues/8561
[i915#8585]: https://gitlab.freedesktop.org/drm/intel/issues/8585
[i915#8691]: https://gitlab.freedesktop.org/drm/intel/issues/8691
[i915#8708]: https://gitlab.freedesktop.org/drm/intel/issues/8708
[i915#8758]: https://gitlab.freedesktop.org/drm/intel/issues/8758
Build changes
-------------
* Linux: CI_DRM_13351 -> Patchwork_120238v2
CI-20190529: 20190529
CI_DRM_13351: c5262da740fe00ef30394118a108dcf0723a0318 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7376: 38af51c0ce6d9573793f53fc32782b77061bf169 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120238v2: c5262da740fe00ef30394118a108dcf0723a0318 @ 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_120238v2/index.html
[-- Attachment #2: Type: text/html, Size: 49453 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-06 15:16 ` [Intel-gfx] [PATCH v2] " Andrzej Hajda
@ 2023-07-07 8:05 ` Nirmoy Das
2023-07-11 10:18 ` Andi Shyti
1 sibling, 0 replies; 30+ messages in thread
From: Nirmoy Das @ 2023-07-07 8:05 UTC (permalink / raw)
To: Andrzej Hajda, intel-gfx; +Cc: Chris Wilson, Nirmoy Das
On 7/6/2023 5:16 PM, Andrzej Hajda wrote:
> GuC virtual engines can be removed before request removal. On the other
> side driver expects rq->engine to be a valid pointer for a whole life of
> request. Setting rq->engine to an always valid engine should solve
> the issue.
>
> The patch fixes bug detected by KASAN with following signature:
> i915 0000:00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 0x0000005c [0x0000005c]
> BUG: KASAN: slab-use-after-free in i915_fence_release+0x2a2/0x2f0 [i915]
> Read of size 4 at addr ffff88813ffda6e8 by task kworker/u32:10/157
> ...
> Allocated by task 1184:
> ...
> guc_create_virtual+0x4d/0x1160 [i915]
> i915_gem_create_context+0x11ee/0x18c0 [i915]
> ...
> Freed by task 151:
> ...
> intel_guc_deregister_done_process_msg+0x324/0x6d0 [i915]
> ...
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7926
> Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index a0e3ef1c65d246..2c877ea5eda6f0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
> static void remove_from_context(struct i915_request *rq)
> {
> struct intel_context *ce = request_to_scheduling_context(rq);
> + struct intel_engine_cs *engine;
> + intel_engine_mask_t tmp;
>
> GEM_BUG_ON(intel_context_is_child(ce));
>
> @@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
>
> atomic_dec(&ce->guc_id.ref);
> i915_request_notify_execute_cb_imm(rq);
> +
> + /*
> + * GuC virtual engine can disappear after this call, so let's assign
> + * something valid, as driver expects this to be always valid pointer.
> + */
> + for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
> + rq->engine = engine;
> + break;
> + }
> }
>
> static const struct intel_context_ops guc_context_ops = {
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: update request engine before removing virtual GuC engine (rev2)
2023-07-07 2:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2023-07-10 12:51 ` Andrzej Hajda
0 siblings, 0 replies; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-10 12:51 UTC (permalink / raw)
To: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 47334 bytes --]
On 07.07.2023 04:52, Patchwork wrote:
> Project List - Patchwork *Patch Details*
> *Series:* drm/i915/gt: update request engine before removing virtual
> GuC engine (rev2)
> *URL:* https://patchwork.freedesktop.org/series/120238/
> *State:* failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/index.html
>
>
> CI Bug Log - changes from CI_DRM_13351_full -> Patchwork_120238v2_full
>
>
> Summary
>
> *FAILURE*
>
> Serious unknown changes coming with Patchwork_120238v2_full absolutely
> need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_120238v2_full, please notify your bug team to
> allow them
> to document this new failure mode, which will reduce false positives
> in CI.
>
>
> Participating hosts (9 -> 10)
>
> Additional (1): shard-tglu0
>
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_120238v2_full:
>
>
> IGT changes
>
>
> Possible regressions
>
> *
>
> igt@gem_exec_reloc@basic-wc-cpu-active:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@gem_exec_reloc@basic-wc-cpu-active.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@gem_exec_reloc@basic-wc-cpu-active.html>
> +4 similar issues
>
Not related, apl does not use GuC and the change is only for GuC submission.
> *
> *
>
> igt@kms_plane_multiple@tiling-y:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_plane_multiple@tiling-y.html>
>
Not related, this test is always skipped/notrun on dg2:
http://gfx-ci.igk.intel.com/tree/drm-tip/shards-all.html?testfilter=igt@kms_plane_multiple@tiling-y
Regards
Andrzej
> *
>
>
> New tests
>
> New tests have been introduced between CI_DRM_13351_full and
> Patchwork_120238v2_full:
>
>
> New IGT tests (34)
>
> *
>
> igt@gem_exec_basic@basic@bcs0-lmem0:
>
> o Statuses : 2 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@gem_exec_basic@basic@rcs0-lmem0:
>
> o Statuses : 2 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@gem_exec_basic@basic@vcs0-lmem0:
>
> o Statuses : 2 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@gem_exec_basic@basic@vcs1-lmem0:
>
> o Statuses : 2 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@gem_exec_basic@basic@vecs0-lmem0:
>
> o Statuses : 2 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-blocking-absolute-wf_vblank@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-blocking-wf_vblank@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-dpms-vs-vblank-race@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-flip-vs-panning-interruptible@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@2x-plain-flip-ts-check@ab-vga1-hdmi-a1:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@basic-flip-vs-dpms@d-hdmi-a2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@blocking-absolute-wf_vblank@d-hdmi-a2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@bo-too-big@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@bo-too-big@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@bo-too-big@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-expired-vblank-interruptible@d-hdmi-a2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-panning-vs-hang@d-hdmi-a2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-panning@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-panning@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-panning@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-suspend@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-suspend@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@flip-vs-suspend@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@modeset-vs-vblank-race-interruptible@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@modeset-vs-vblank-race-interruptible@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@modeset-vs-vblank-race-interruptible@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@nonexisting-fb-interruptible@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@nonexisting-fb-interruptible@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@nonexisting-fb-interruptible@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@nonexisting-fb@d-hdmi-a2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@plain-flip-fb-recreate@a-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@plain-flip-fb-recreate@b-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
> *
>
> igt@kms_flip@plain-flip-fb-recreate@c-dp2:
>
> o Statuses : 1 pass(s)
> o Exec time: [0.0] s
>
>
> Known issues
>
> Here are the changes found in Patchwork_120238v2_full that come from
> known issues:
>
>
> IGT changes
>
>
> Issues hit
>
> *
>
> igt@drm_fdinfo@busy-hang@bcs0:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@drm_fdinfo@busy-hang@bcs0.html>
> (i915#8414
> <https://gitlab.freedesktop.org/drm/intel/issues/8414>) +10
> similar issues
> *
>
> igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
>
> o shard-rkl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html>
> (i915#7742 <https://gitlab.freedesktop.org/drm/intel/issues/7742>)
> *
>
> igt@gem_eio@in-flight-contexts-immediate:
>
> o shard-mtlp: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-7/igt@gem_eio@in-flight-contexts-immediate.html>
> -> ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-2/igt@gem_eio@in-flight-contexts-immediate.html>
> (i915#8503 <https://gitlab.freedesktop.org/drm/intel/issues/8503>)
> *
>
> igt@gem_exec_balancer@bonded-pair:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_balancer@bonded-pair.html>
> (i915#4771 <https://gitlab.freedesktop.org/drm/intel/issues/4771>)
> *
>
> igt@gem_exec_balancer@full-pulse:
>
> o shard-dg2: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@gem_exec_balancer@full-pulse.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-8/igt@gem_exec_balancer@full-pulse.html>
> (i915#6032
> <https://gitlab.freedesktop.org/drm/intel/issues/6032>) +1
> similar issue
> *
>
> igt@gem_exec_balancer@sliced:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_balancer@sliced.html>
> (i915#4812 <https://gitlab.freedesktop.org/drm/intel/issues/4812>)
> *
>
> igt@gem_exec_fair@basic-none-rrul:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_fair@basic-none-rrul.html>
> (i915#3539
> <https://gitlab.freedesktop.org/drm/intel/issues/3539> /
> i915#4852 <https://gitlab.freedesktop.org/drm/intel/issues/4852>)
> *
>
> igt@gem_exec_fair@basic-pace-solo@rcs0:
>
> o shard-glk: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk4/igt@gem_exec_fair@basic-pace-solo@rcs0.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@gem_exec_fair@basic-pace-solo@rcs0.html>
> (i915#2842 <https://gitlab.freedesktop.org/drm/intel/issues/2842>)
> *
>
> igt@gem_exec_reloc@basic-wc:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_reloc@basic-wc.html>
> (i915#3281
> <https://gitlab.freedesktop.org/drm/intel/issues/3281>) +3
> similar issues
> *
>
> igt@gem_exec_schedule@deep@vcs0:
>
> o shard-mtlp: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@gem_exec_schedule@deep@vcs0.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-4/igt@gem_exec_schedule@deep@vcs0.html>
> (i915#8545 <https://gitlab.freedesktop.org/drm/intel/issues/8545>)
> *
>
> igt@gem_exec_schedule@preempt-queue:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_schedule@preempt-queue.html>
> (i915#4537
> <https://gitlab.freedesktop.org/drm/intel/issues/4537> /
> i915#4812 <https://gitlab.freedesktop.org/drm/intel/issues/4812>)
> *
>
> igt@gem_fence_thrash@bo-write-verify-y:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_fence_thrash@bo-write-verify-y.html>
> (i915#4860
> <https://gitlab.freedesktop.org/drm/intel/issues/4860>) +1
> similar issue
> *
>
> igt@gem_lmem_swapping@parallel-random-verify-ccs:
>
> o shard-glk: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@gem_lmem_swapping@parallel-random-verify-ccs.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> i915#4613 <https://gitlab.freedesktop.org/drm/intel/issues/4613>)
> *
>
> igt@gem_mmap_wc@pf-nonblock:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_mmap_wc@pf-nonblock.html>
> (i915#4083 <https://gitlab.freedesktop.org/drm/intel/issues/4083>)
> *
>
> igt@gem_pwrite@basic-exhaustion:
>
> o shard-snb: NOTRUN -> WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@gem_pwrite@basic-exhaustion.html>
> (i915#2658 <https://gitlab.freedesktop.org/drm/intel/issues/2658>)
> *
>
> igt@gem_spin_batch@spin-each:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl3/igt@gem_spin_batch@spin-each.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl2/igt@gem_spin_batch@spin-each.html>
> (i915#2898 <https://gitlab.freedesktop.org/drm/intel/issues/2898>)
> *
>
> igt@gem_tiled_pread_basic:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_tiled_pread_basic.html>
> (i915#4079 <https://gitlab.freedesktop.org/drm/intel/issues/4079>)
> *
>
> igt@gem_userptr_blits@forbidden-operations:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_userptr_blits@forbidden-operations.html>
> (i915#3282
> <https://gitlab.freedesktop.org/drm/intel/issues/3282>) +1
> similar issue
> *
>
> igt@gem_userptr_blits@unsync-unmap-after-close:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_userptr_blits@unsync-unmap-after-close.html>
> (i915#3297 <https://gitlab.freedesktop.org/drm/intel/issues/3297>)
> *
>
> igt@gen9_exec_parse@allowed-all:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl7/igt@gen9_exec_parse@allowed-all.html>
> -> ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl4/igt@gen9_exec_parse@allowed-all.html>
> (i915#5566 <https://gitlab.freedesktop.org/drm/intel/issues/5566>)
> *
>
> igt@gen9_exec_parse@batch-invalid-length:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gen9_exec_parse@batch-invalid-length.html>
> (i915#2856 <https://gitlab.freedesktop.org/drm/intel/issues/2856>)
> *
>
> igt@gen9_exec_parse@unaligned-jump:
>
> o shard-mtlp: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@gen9_exec_parse@unaligned-jump.html>
> (i915#2856 <https://gitlab.freedesktop.org/drm/intel/issues/2856>)
> *
>
> igt@i915_pm_rpm@modeset-non-lpsp-stress:
>
> o shard-dg2: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@i915_pm_rpm@modeset-non-lpsp-stress.html>
> -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-12/igt@i915_pm_rpm@modeset-non-lpsp-stress.html>
> (i915#1397 <https://gitlab.freedesktop.org/drm/intel/issues/1397>)
> *
>
> igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
>
> o shard-rkl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-4/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html>
> -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html>
> (i915#1397
> <https://gitlab.freedesktop.org/drm/intel/issues/1397>) +2
> similar issues
> *
>
> igt@i915_pm_sseu@full-enable:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_pm_sseu@full-enable.html>
> (i915#4387 <https://gitlab.freedesktop.org/drm/intel/issues/4387>)
> *
>
> igt@i915_selftest@live@hangcheck:
>
> o shard-dg2: NOTRUN -> ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_selftest@live@hangcheck.html>
> (i915#7913 <https://gitlab.freedesktop.org/drm/intel/issues/7913>)
> *
>
> igt@i915_suspend@fence-restore-untiled:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@i915_suspend@fence-restore-untiled.html>
> (i915#4077
> <https://gitlab.freedesktop.org/drm/intel/issues/4077>) +7
> similar issues
> *
>
> igt@kms_big_fb@4-tiled-16bpp-rotate-270:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@4-tiled-16bpp-rotate-270.html>
> (fdo#111614
> <https://bugs.freedesktop.org/show_bug.cgi?id=111614>) +1
> similar issue
> *
>
> igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
>
> o shard-glk: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +62
> similar issues
> *
>
> igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip:
>
> o shard-mtlp: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-5/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html>
> (i915#5138 <https://gitlab.freedesktop.org/drm/intel/issues/5138>)
> *
>
> igt@kms_big_fb@yf-tiled-addfb-size-overflow:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@yf-tiled-addfb-size-overflow.html>
> (i915#5190
> <https://gitlab.freedesktop.org/drm/intel/issues/5190>) +2
> similar issues
> *
>
> igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html>
> (i915#4538
> <https://gitlab.freedesktop.org/drm/intel/issues/4538> /
> i915#5190
> <https://gitlab.freedesktop.org/drm/intel/issues/5190>) +1
> similar issue
> *
>
> igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
>
> o shard-glk: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> i915#3886
> <https://gitlab.freedesktop.org/drm/intel/issues/3886>) +1
> similar issue
> *
>
> igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc:
>
> o shard-mtlp: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc.html>
> (i915#6095 <https://gitlab.freedesktop.org/drm/intel/issues/6095>)
> *
>
> igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs.html>
> (i915#3689
> <https://gitlab.freedesktop.org/drm/intel/issues/3689> /
> i915#5354
> <https://gitlab.freedesktop.org/drm/intel/issues/5354>) +8
> similar issues
> *
>
> igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs.html>
> (i915#3689
> <https://gitlab.freedesktop.org/drm/intel/issues/3689> /
> i915#3886
> <https://gitlab.freedesktop.org/drm/intel/issues/3886> /
> i915#5354
> <https://gitlab.freedesktop.org/drm/intel/issues/5354>) +5
> similar issues
> *
>
> igt@kms_ccs@pipe-d-ccs-on-another-bo-4_tiled_mtl_rc_ccs:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_ccs@pipe-d-ccs-on-another-bo-4_tiled_mtl_rc_ccs.html>
> (i915#5354
> <https://gitlab.freedesktop.org/drm/intel/issues/5354>) +15
> similar issues
> *
>
> igt@kms_cdclk@mode-transition@pipe-d-dp-4:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cdclk@mode-transition@pipe-d-dp-4.html>
> (i915#4087
> <https://gitlab.freedesktop.org/drm/intel/issues/4087>) +3
> similar issues
> *
>
> igt@kms_chamelium_color@ctm-0-75:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_chamelium_color@ctm-0-75.html>
> (fdo#111827 <https://bugs.freedesktop.org/show_bug.cgi?id=111827>)
> *
>
> igt@kms_chamelium_hpd@vga-hpd-without-ddc:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_chamelium_hpd@vga-hpd-without-ddc.html>
> (i915#7828
> <https://gitlab.freedesktop.org/drm/intel/issues/7828>) +1
> similar issue
> *
>
> igt@kms_content_protection@legacy@pipe-a-dp-4:
>
> o shard-dg2: NOTRUN -> TIMEOUT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_content_protection@legacy@pipe-a-dp-4.html>
> (i915#7173 <https://gitlab.freedesktop.org/drm/intel/issues/7173>)
> *
>
> igt@kms_content_protection@lic:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_content_protection@lic.html>
> (i915#7118 <https://gitlab.freedesktop.org/drm/intel/issues/7118>)
> *
>
> igt@kms_content_protection@uevent@pipe-a-dp-4:
>
> o shard-dg2: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_content_protection@uevent@pipe-a-dp-4.html>
> (i915#1339 <https://gitlab.freedesktop.org/drm/intel/issues/1339>)
> *
>
> igt@kms_cursor_crc@cursor-rapid-movement-512x170:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cursor_crc@cursor-rapid-movement-512x170.html>
> (i915#3359 <https://gitlab.freedesktop.org/drm/intel/issues/3359>)
> *
>
> igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size.html>
> (fdo#109274
> <https://bugs.freedesktop.org/show_bug.cgi?id=109274> /
> i915#5354
> <https://gitlab.freedesktop.org/drm/intel/issues/5354>) +1
> similar issue
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> (i915#2346 <https://gitlab.freedesktop.org/drm/intel/issues/2346>)
> *
>
> igt@kms_flip@2x-busy-flip:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_flip@2x-busy-flip.html>
> (fdo#109274 <https://bugs.freedesktop.org/show_bug.cgi?id=109274>)
> *
>
> igt@kms_flip@2x-flip-vs-dpms:
>
> o shard-mtlp: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_flip@2x-flip-vs-dpms.html>
> (i915#3637 <https://gitlab.freedesktop.org/drm/intel/issues/3637>)
> *
>
> igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
>
> o shard-glk: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html>
> (i915#79 <https://gitlab.freedesktop.org/drm/intel/issues/79>)
> *
>
> igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
>
> o shard-mtlp: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-4/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html>
> (i915#79 <https://gitlab.freedesktop.org/drm/intel/issues/79>)
> *
>
> igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
>
> o shard-dg2: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html>
> (i915#6880
> <https://gitlab.freedesktop.org/drm/intel/issues/6880>) +1
> similar issue
> *
>
> igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt.html>
> (i915#8708
> <https://gitlab.freedesktop.org/drm/intel/issues/8708>) +10
> similar issues
> *
>
> igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-render:
>
> o shard-mtlp: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-render.html>
> (i915#1825
> <https://gitlab.freedesktop.org/drm/intel/issues/1825>) +1
> similar issue
> *
>
> igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html>
> (i915#3458
> <https://gitlab.freedesktop.org/drm/intel/issues/3458>) +4
> similar issues
> *
>
> igt@kms_hdr@bpc-switch:
>
> o shard-rkl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@kms_hdr@bpc-switch.html>
> (i915#3555 <https://gitlab.freedesktop.org/drm/intel/issues/3555>)
> *
>
> igt@kms_plane@plane-panning-top-left@pipe-a-planes:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@kms_plane@plane-panning-top-left@pipe-a-planes.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@kms_plane@plane-panning-top-left@pipe-a-planes.html>
> (i915#180
> <https://gitlab.freedesktop.org/drm/intel/issues/180> /
> i915#8585
> <https://gitlab.freedesktop.org/drm/intel/issues/8585>) +5
> similar issues
> *
>
> igt@kms_plane_alpha_blend@alpha-basic@pipe-a-hdmi-a-1:
>
> o shard-glk: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk8/igt@kms_plane_alpha_blend@alpha-basic@pipe-a-hdmi-a-1.html>
> (i915#7862
> <https://gitlab.freedesktop.org/drm/intel/issues/7862>) +1
> similar issue
> *
>
> igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-2:
>
> o shard-rkl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-2.html>
> (i915#5176
> <https://gitlab.freedesktop.org/drm/intel/issues/5176>) +3
> similar issues
> *
>
> igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-dp-4:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-dp-4.html>
> (i915#5235
> <https://gitlab.freedesktop.org/drm/intel/issues/5235>) +7
> similar issues
> *
>
> igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-a-hdmi-a-1:
>
> o shard-rkl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-a-hdmi-a-1.html>
> (i915#5235
> <https://gitlab.freedesktop.org/drm/intel/issues/5235>) +3
> similar issues
> *
>
> igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-apl1/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-apl1/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-dp-1.html>
> (i915#180
> <https://gitlab.freedesktop.org/drm/intel/issues/180>) +1
> similar issue
> *
>
> igt@kms_prime@basic-crc-hybrid:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_prime@basic-crc-hybrid.html>
> (i915#6524
> <https://gitlab.freedesktop.org/drm/intel/issues/6524> /
> i915#6805 <https://gitlab.freedesktop.org/drm/intel/issues/6805>)
> *
>
> igt@kms_psr@psr2_primary_blt:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@kms_psr@psr2_primary_blt.html>
> (i915#1072
> <https://gitlab.freedesktop.org/drm/intel/issues/1072>) +2
> similar issues
> *
>
> igt@kms_rotation_crc@primary-y-tiled-reflect-x-270:
>
> o shard-rkl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-4/igt@kms_rotation_crc@primary-y-tiled-reflect-x-270.html>
> -> ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_rotation_crc@primary-y-tiled-reflect-x-270.html>
> (i915#7461
> <https://gitlab.freedesktop.org/drm/intel/issues/7461> /
> i915#8178 <https://gitlab.freedesktop.org/drm/intel/issues/8178>)
> *
>
> igt@kms_setmode@basic@pipe-a-hdmi-a-1:
>
> o shard-snb: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb1/igt@kms_setmode@basic@pipe-a-hdmi-a-1.html>
> (i915#5465
> <https://gitlab.freedesktop.org/drm/intel/issues/5465>) +1
> similar issue
> *
>
> igt@kms_sysfs_edid_timing:
>
> o shard-dg2: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@kms_sysfs_edid_timing.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_sysfs_edid_timing.html>
> (IGT#2
> <https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/2>)
> *
>
> igt@kms_vrr@flip-suspend:
>
> o shard-snb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@kms_vrr@flip-suspend.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +117
> similar issues
> *
>
> igt@perf@global-sseu-config-invalid:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@perf@global-sseu-config-invalid.html>
> (i915#7387 <https://gitlab.freedesktop.org/drm/intel/issues/7387>)
> *
>
> igt@perf@per-context-mode-unprivileged:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@perf@per-context-mode-unprivileged.html>
> (fdo#109289
> <https://bugs.freedesktop.org/show_bug.cgi?id=109289>) +1
> similar issue
> *
>
> igt@prime_vgem@coherency-blt:
>
> o shard-mtlp: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@prime_vgem@coherency-blt.html>
> (i915#8445 <https://gitlab.freedesktop.org/drm/intel/issues/8445>)
> *
>
> igt@prime_vgem@fence-read-hang:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@prime_vgem@fence-read-hang.html>
> (i915#3708 <https://gitlab.freedesktop.org/drm/intel/issues/3708>)
> *
>
> igt@v3d/v3d_submit_csd@multiple-job-submission:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@v3d/v3d_submit_csd@multiple-job-submission.html>
> (i915#2575
> <https://gitlab.freedesktop.org/drm/intel/issues/2575>) +3
> similar issues
> *
>
> igt@vc4/vc4_label_bo@set-kernel-name:
>
> o shard-dg2: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@vc4/vc4_label_bo@set-kernel-name.html>
> (i915#7711
> <https://gitlab.freedesktop.org/drm/intel/issues/7711>) +3
> similar issues
>
>
> Possible fixes
>
> *
>
> igt@gem_create@hog-create@smem0:
>
> o shard-dg2: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@gem_create@hog-create@smem0.html>
> (i915#5892
> <https://gitlab.freedesktop.org/drm/intel/issues/5892> /
> i915#8758
> <https://gitlab.freedesktop.org/drm/intel/issues/8758>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-8/igt@gem_create@hog-create@smem0.html>
> *
>
> igt@gem_ctx_exec@basic-nohangcheck:
>
> o shard-tglu: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-tglu-2/igt@gem_ctx_exec@basic-nohangcheck.html>
> (i915#6268
> <https://gitlab.freedesktop.org/drm/intel/issues/6268>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-tglu-6/igt@gem_ctx_exec@basic-nohangcheck.html>
> *
>
> igt@gem_eio@kms:
>
> o {shard-dg1}: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-13/igt@gem_eio@kms.html>
> (i915#5784
> <https://gitlab.freedesktop.org/drm/intel/issues/5784>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-15/igt@gem_eio@kms.html>
> *
>
> igt@gem_exec_fair@basic-pace@rcs0:
>
> o shard-glk: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk6/igt@gem_exec_fair@basic-pace@rcs0.html>
> (i915#2842
> <https://gitlab.freedesktop.org/drm/intel/issues/2842>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk2/igt@gem_exec_fair@basic-pace@rcs0.html>
> *
>
> igt@gem_exec_schedule@pi-distinct-iova@vcs1:
>
> o shard-dg2: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@gem_exec_schedule@pi-distinct-iova@vcs1.html>
> (i915#8585
> <https://gitlab.freedesktop.org/drm/intel/issues/8585>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-11/igt@gem_exec_schedule@pi-distinct-iova@vcs1.html>
> +3 similar issues
> *
>
> igt@gem_exec_whisper@basic-contexts-all:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-all.html>
> (i915#6363
> <https://gitlab.freedesktop.org/drm/intel/issues/6363>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-all.html>
> *
>
> igt@gem_lmem_swapping@smem-oom@lmem0:
>
> o {shard-dg1}: TIMEOUT
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-12/igt@gem_lmem_swapping@smem-oom@lmem0.html>
> (i915#5493
> <https://gitlab.freedesktop.org/drm/intel/issues/5493>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-18/igt@gem_lmem_swapping@smem-oom@lmem0.html>
> *
>
> igt@gen9_exec_parse@allowed-all:
>
> o shard-glk: ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-glk7/igt@gen9_exec_parse@allowed-all.html>
> (i915#5566
> <https://gitlab.freedesktop.org/drm/intel/issues/5566>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-glk9/igt@gen9_exec_parse@allowed-all.html>
> +1 similar issue
> *
>
> igt@i915_pipe_stress@stress-xrgb8888-untiled:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html>
> (i915#8691
> <https://gitlab.freedesktop.org/drm/intel/issues/8691>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html>
> *
>
> igt@i915_pm_rc6_residency@rc6-idle@rcs0:
>
> o {shard-dg1}: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-17/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html>
> (i915#3591
> <https://gitlab.freedesktop.org/drm/intel/issues/3591>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html>
> +1 similar issue
> *
>
> igt@i915_pm_rpm@modeset-lpsp:
>
> o shard-rkl: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-1/igt@i915_pm_rpm@modeset-lpsp.html>
> (i915#1397
> <https://gitlab.freedesktop.org/drm/intel/issues/1397>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-7/igt@i915_pm_rpm@modeset-lpsp.html>
> *
>
> igt@i915_pm_rpm@modeset-non-lpsp:
>
> o {shard-dg1}: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg1-19/igt@i915_pm_rpm@modeset-non-lpsp.html>
> (i915#1397
> <https://gitlab.freedesktop.org/drm/intel/issues/1397>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg1-16/igt@i915_pm_rpm@modeset-non-lpsp.html>
> *
>
> igt@i915_pm_rps@reset:
>
> o shard-snb: INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-snb4/igt@i915_pm_rps@reset.html>
> (i915#7790
> <https://gitlab.freedesktop.org/drm/intel/issues/7790>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-snb5/igt@i915_pm_rps@reset.html>
> *
>
> igt@i915_suspend@forcewake:
>
> o shard-dg2: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-5/igt@i915_suspend@forcewake.html>
> (fdo#103375
> <https://bugs.freedesktop.org/show_bug.cgi?id=103375> /
> i915#6121
> <https://gitlab.freedesktop.org/drm/intel/issues/6121>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-2/igt@i915_suspend@forcewake.html>
> *
>
> igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html>
> (i915#5138
> <https://gitlab.freedesktop.org/drm/intel/issues/5138>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html>
> *
>
> igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html>
> (i915#3743
> <https://gitlab.freedesktop.org/drm/intel/issues/3743>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html>
> +2 similar issues
> *
>
> igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1:
>
> o shard-mtlp: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-5/igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1.html>
> (i915#1982
> <https://gitlab.freedesktop.org/drm/intel/issues/1982>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@kms_plane_scaling@plane-scaler-with-pixel-format-unity-scaling@pipe-b-edp-1.html>
> *
>
> igt@perf@non-zero-reason@0-rcs0:
>
> o shard-dg2: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-2/igt@perf@non-zero-reason@0-rcs0.html>
> (i915#7484
> <https://gitlab.freedesktop.org/drm/intel/issues/7484>) ->
> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-2/igt@perf@non-zero-reason@0-rcs0.html>
>
>
> Warnings
>
> *
>
> igt@gem_exec_whisper@basic-contexts-forked-all:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-2/igt@gem_exec_whisper@basic-contexts-forked-all.html>
> (i915#6363
> <https://gitlab.freedesktop.org/drm/intel/issues/6363>) ->
> ABORT
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-7/igt@gem_exec_whisper@basic-contexts-forked-all.html>
> (i915#8131 <https://gitlab.freedesktop.org/drm/intel/issues/8131>)
> *
>
> igt@kms_async_flips@crc@pipe-a-edp-1:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@kms_async_flips@crc@pipe-a-edp-1.html>
> (i915#8247
> <https://gitlab.freedesktop.org/drm/intel/issues/8247>) ->
> DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_async_flips@crc@pipe-a-edp-1.html>
> (i915#1982
> <https://gitlab.freedesktop.org/drm/intel/issues/1982> /
> i915#8561 <https://gitlab.freedesktop.org/drm/intel/issues/8561>)
> *
>
> igt@kms_async_flips@crc@pipe-d-edp-1:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-3/igt@kms_async_flips@crc@pipe-d-edp-1.html>
> (i915#8247
> <https://gitlab.freedesktop.org/drm/intel/issues/8247>) ->
> DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-8/igt@kms_async_flips@crc@pipe-d-edp-1.html>
> (i915#8561
> <https://gitlab.freedesktop.org/drm/intel/issues/8561>) +2
> similar issues
> *
>
> igt@kms_content_protection@type1:
>
> o shard-dg2: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@kms_content_protection@type1.html>
> (i915#7118
> <https://gitlab.freedesktop.org/drm/intel/issues/7118> /
> i915#7162
> <https://gitlab.freedesktop.org/drm/intel/issues/7162>) ->
> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@kms_content_protection@type1.html>
> (i915#7118 <https://gitlab.freedesktop.org/drm/intel/issues/7118>)
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
>
> o shard-mtlp: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-mtlp-6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> (i915#2346
> <https://gitlab.freedesktop.org/drm/intel/issues/2346>) ->
> DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-mtlp-6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> (i915#1982
> <https://gitlab.freedesktop.org/drm/intel/issues/1982> /
> i915#2017
> <https://gitlab.freedesktop.org/drm/intel/issues/2017> /
> i915#5954 <https://gitlab.freedesktop.org/drm/intel/issues/5954>)
> *
>
> igt@kms_fbcon_fbt@psr-suspend:
>
> o shard-rkl: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@kms_fbcon_fbt@psr-suspend.html>
> (i915#3955
> <https://gitlab.freedesktop.org/drm/intel/issues/3955>) ->
> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-2/igt@kms_fbcon_fbt@psr-suspend.html>
> (fdo#110189
> <https://bugs.freedesktop.org/show_bug.cgi?id=110189> /
> i915#3955
> <https://gitlab.freedesktop.org/drm/intel/issues/3955>) +1
> similar issue
> *
>
> igt@kms_force_connector_basic@force-load-detect:
>
> o shard-rkl: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-rkl-6/igt@kms_force_connector_basic@force-load-detect.html>
> (fdo#109285
> <https://bugs.freedesktop.org/show_bug.cgi?id=109285>) -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-rkl-4/igt@kms_force_connector_basic@force-load-detect.html>
> (fdo#109285
> <https://bugs.freedesktop.org/show_bug.cgi?id=109285> /
> i915#4098 <https://gitlab.freedesktop.org/drm/intel/issues/4098>)
> *
>
> igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem:
>
> o shard-dg2: INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13351/shard-dg2-11/igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem.html>
> (i915#5493
> <https://gitlab.freedesktop.org/drm/intel/issues/5493>) ->
> CRASH
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120238v2/shard-dg2-5/igt@prime_mmap@test_aperture_limit@test_aperture_limit-smem.html>
> (i915#7331 <https://gitlab.freedesktop.org/drm/intel/issues/7331>)
>
> {name}: This element is suppressed. This means it is ignored when
> computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
>
> Build changes
>
> * Linux: CI_DRM_13351 -> Patchwork_120238v2
>
> CI-20190529: 20190529
> CI_DRM_13351: c5262da740fe00ef30394118a108dcf0723a0318 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7376: 38af51c0ce6d9573793f53fc32782b77061bf169 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_120238v2: c5262da740fe00ef30394118a108dcf0723a0318 @
> git://anongit.freedesktop.org/gfx-ci/linux
> piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
> git://anongit.freedesktop.org/piglit
>
[-- Attachment #2: Type: text/html, Size: 71529 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-06 15:16 ` [Intel-gfx] [PATCH v2] " Andrzej Hajda
2023-07-07 8:05 ` Nirmoy Das
@ 2023-07-11 10:18 ` Andi Shyti
2023-07-11 11:12 ` Andrzej Hajda
1 sibling, 1 reply; 30+ messages in thread
From: Andi Shyti @ 2023-07-11 10:18 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
Hi Andrzej,
On Thu, Jul 06, 2023 at 05:16:11PM +0200, Andrzej Hajda wrote:
> GuC virtual engines can be removed before request removal. On the other
> side driver expects rq->engine to be a valid pointer for a whole life of
> request. Setting rq->engine to an always valid engine should solve
> the issue.
>
> The patch fixes bug detected by KASAN with following signature:
> i915 0000:00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 0x0000005c [0x0000005c]
> BUG: KASAN: slab-use-after-free in i915_fence_release+0x2a2/0x2f0 [i915]
> Read of size 4 at addr ffff88813ffda6e8 by task kworker/u32:10/157
> ...
> Allocated by task 1184:
> ...
> guc_create_virtual+0x4d/0x1160 [i915]
> i915_gem_create_context+0x11ee/0x18c0 [i915]
> ...
> Freed by task 151:
> ...
> intel_guc_deregister_done_process_msg+0x324/0x6d0 [i915]
> ...
so the only difference between v1 and v2 is this part of the log?
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7926
> Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index a0e3ef1c65d246..2c877ea5eda6f0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
> static void remove_from_context(struct i915_request *rq)
> {
> struct intel_context *ce = request_to_scheduling_context(rq);
> + struct intel_engine_cs *engine;
> + intel_engine_mask_t tmp;
>
> GEM_BUG_ON(intel_context_is_child(ce));
>
> @@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
>
> atomic_dec(&ce->guc_id.ref);
> i915_request_notify_execute_cb_imm(rq);
> +
> + /*
> + * GuC virtual engine can disappear after this call, so let's assign
> + * something valid, as driver expects this to be always valid pointer.
> + */
> + for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
> + rq->engine = engine;
yes... here the context might lose the virtual engine... I wonder
whether this is the rigth solution, though. Maybe we should set
rq->engine = NULL; and check for NULL? Don't know.
Andi
> + break;
> + }
> }
>
> static const struct intel_context_ops guc_context_ops = {
> --
> 2.34.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-11 10:18 ` Andi Shyti
@ 2023-07-11 11:12 ` Andrzej Hajda
2023-07-11 11:34 ` Andi Shyti
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-11 11:12 UTC (permalink / raw)
To: Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]
On 11.07.2023 12:18, Andi Shyti wrote:
> Hi Andrzej,
>
> On Thu, Jul 06, 2023 at 05:16:11PM +0200, Andrzej Hajda wrote:
>> GuC virtual engines can be removed before request removal. On the other
>> side driver expects rq->engine to be a valid pointer for a whole life of
>> request. Setting rq->engine to an always valid engine should solve
>> the issue.
>>
>> The patch fixes bug detected by KASAN with following signature:
>> i915 0000:00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 0x0000005c [0x0000005c]
>> BUG: KASAN: slab-use-after-free in i915_fence_release+0x2a2/0x2f0 [i915]
>> Read of size 4 at addr ffff88813ffda6e8 by task kworker/u32:10/157
>> ...
>> Allocated by task 1184:
>> ...
>> guc_create_virtual+0x4d/0x1160 [i915]
>> i915_gem_create_context+0x11ee/0x18c0 [i915]
>> ...
>> Freed by task 151:
>> ...
>> intel_guc_deregister_done_process_msg+0x324/0x6d0 [i915]
>> ...
> so the only difference between v1 and v2 is this part of the log?
yes, I forgot to add changelog.
>
>> Closes:https://gitlab.freedesktop.org/drm/intel/-/issues/7926
>> Signed-off-by: Andrzej Hajda<andrzej.hajda@intel.com>
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>> static void remove_from_context(struct i915_request *rq)
>> {
>> struct intel_context *ce = request_to_scheduling_context(rq);
>> + struct intel_engine_cs *engine;
>> + intel_engine_mask_t tmp;
>>
>> GEM_BUG_ON(intel_context_is_child(ce));
>>
>> @@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
>>
>> atomic_dec(&ce->guc_id.ref);
>> i915_request_notify_execute_cb_imm(rq);
>> +
>> + /*
>> + * GuC virtual engine can disappear after this call, so let's assign
>> + * something valid, as driver expects this to be always valid pointer.
>> + */
>> + for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
>> + rq->engine = engine;
> yes... here the context might lose the virtual engine... I wonder
> whether this is the rigth solution, though. Maybe we should set
> rq->engine = NULL; and check for NULL? Don't know.
Setting NULL causes occasional null page de-reference in
i915_request_wait_timeout:
mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
rq->engine after removing rq from context is (IMHO) used as a set of
aliases for gt and i915 (despite rq itself contains the alias to i915).
Regards
Andrzej
>
> Andi
>
>> + break;
>> + }
>> }
>>
>> static const struct intel_context_ops guc_context_ops = {
>> --
>> 2.34.1
[-- Attachment #2: Type: text/html, Size: 4507 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-11 11:12 ` Andrzej Hajda
@ 2023-07-11 11:34 ` Andi Shyti
2023-07-11 13:58 ` Andrzej Hajda
0 siblings, 1 reply; 30+ messages in thread
From: Andi Shyti @ 2023-07-11 11:34 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
Hi Andrzej,
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index a0e3ef1c65d246..2c877ea5eda6f0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
> static void remove_from_context(struct i915_request *rq)
> {
> struct intel_context *ce = request_to_scheduling_context(rq);
> + struct intel_engine_cs *engine;
> + intel_engine_mask_t tmp;
>
> GEM_BUG_ON(intel_context_is_child(ce));
>
> @@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
>
> atomic_dec(&ce->guc_id.ref);
> i915_request_notify_execute_cb_imm(rq);
> +
> + /*
> + * GuC virtual engine can disappear after this call, so let's assign
> + * something valid, as driver expects this to be always valid pointer.
> + */
> + for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
> + rq->engine = engine;
>
> yes... here the context might lose the virtual engine... I wonder
> whether this is the rigth solution, though. Maybe we should set
> rq->engine = NULL; and check for NULL? Don't know.
>
>
> Setting NULL causes occasional null page de-reference in
>
> i915_request_wait_timeout:
>
> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>
> rq->engine after removing rq from context is (IMHO) used as a set of aliases
> for gt and i915 (despite rq itself contains the alias to i915).
without investigating further, but maybe that code is not even
supposed to be executed, at this point, if the request's assigned
virtual engine is removed.
Andi
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-11 11:34 ` Andi Shyti
@ 2023-07-11 13:58 ` Andrzej Hajda
2023-07-11 15:27 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-11 13:58 UTC (permalink / raw)
To: Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 11.07.2023 13:34, Andi Shyti wrote:
> Hi Andrzej,
>
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>> static void remove_from_context(struct i915_request *rq)
>> {
>> struct intel_context *ce = request_to_scheduling_context(rq);
>> + struct intel_engine_cs *engine;
>> + intel_engine_mask_t tmp;
>>
>> GEM_BUG_ON(intel_context_is_child(ce));
>>
>> @@ -3478,6 +3480,15 @@ static void remove_from_context(struct i915_request *rq)
>>
>> atomic_dec(&ce->guc_id.ref);
>> i915_request_notify_execute_cb_imm(rq);
>> +
>> + /*
>> + * GuC virtual engine can disappear after this call, so let's assign
>> + * something valid, as driver expects this to be always valid pointer.
>> + */
>> + for_each_engine_masked(engine, rq->engine->gt, rq->execution_mask, tmp) {
>> + rq->engine = engine;
>>
>> yes... here the context might lose the virtual engine... I wonder
>> whether this is the rigth solution, though. Maybe we should set
>> rq->engine = NULL; and check for NULL? Don't know.
>>
>>
>> Setting NULL causes occasional null page de-reference in
>>
>> i915_request_wait_timeout:
>>
>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>
>> rq->engine after removing rq from context is (IMHO) used as a set of aliases
>> for gt and i915 (despite rq itself contains the alias to i915).
> without investigating further, but maybe that code is not even
> supposed to be executed, at this point, if the request's assigned
> virtual engine is removed.
Real tests show it is executed and the function
i915_request_wait_timeout is quite generic
I guess it is quite typical use-case, the only question is about timings
- what happens earlier -
finalization of i915_request_wait_timeout or context removal.
The other point rq->engine is accessed after context removal is
i915_fence_release -
there is long comment there regarding virtual context and reuse retired rq.
Anyway calling there "intel_engine_is_virtual(rq->engine)" is risky
without this patch and KASAN complains clearly about it:
http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
Regards
Andrzej
>
> Andi
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-11 13:58 ` Andrzej Hajda
@ 2023-07-11 15:27 ` Tvrtko Ursulin
2023-07-12 12:18 ` Andrzej Hajda
0 siblings, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-11 15:27 UTC (permalink / raw)
To: Andrzej Hajda, Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 11/07/2023 14:58, Andrzej Hajda wrote:
> On 11.07.2023 13:34, Andi Shyti wrote:
>> Hi Andrzej,
>>
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>> +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git
>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>> i915_request *rq, struct intel_context *ce)
>>> static void remove_from_context(struct i915_request *rq)
>>> {
>>> struct intel_context *ce =
>>> request_to_scheduling_context(rq);
>>> + struct intel_engine_cs *engine;
>>> + intel_engine_mask_t tmp;
>>>
>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>
>>> @@ -3478,6 +3480,15 @@ static void
>>> remove_from_context(struct i915_request *rq)
>>>
>>> atomic_dec(&ce->guc_id.ref);
>>> i915_request_notify_execute_cb_imm(rq);
>>> +
>>> + /*
>>> + * GuC virtual engine can disappear after this call,
>>> so let's assign
>>> + * something valid, as driver expects this to be
>>> always valid pointer.
>>> + */
>>> + for_each_engine_masked(engine, rq->engine->gt,
>>> rq->execution_mask, tmp) {
>>> + rq->engine = engine;
>>>
>>> yes... here the context might lose the virtual engine... I wonder
>>> whether this is the rigth solution, though. Maybe we should set
>>> rq->engine = NULL; and check for NULL? Don't know.
>>>
>>>
>>> Setting NULL causes occasional null page de-reference in
>>>
>>> i915_request_wait_timeout:
>>>
>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>
>>> rq->engine after removing rq from context is (IMHO) used as a set of
>>> aliases
>>> for gt and i915 (despite rq itself contains the alias to i915).
>> without investigating further, but maybe that code is not even
>> supposed to be executed, at this point, if the request's assigned
>> virtual engine is removed.
>
> Real tests show it is executed and the function
> i915_request_wait_timeout is quite generic
> I guess it is quite typical use-case, the only question is about timings
> - what happens earlier -
> finalization of i915_request_wait_timeout or context removal.
>
> The other point rq->engine is accessed after context removal is
> i915_fence_release -
> there is long comment there regarding virtual context and reuse retired rq.
> Anyway calling there "intel_engine_is_virtual(rq->engine)" is risky
> without this patch and KASAN complains clearly about it:
> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915: Hold
reference to intel_context over life of i915_request""), which was a
partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
intel_context over life of i915_request").
Ie. if 1e98d8c52ed5 recognised the problem with disappearing rq->engine,
then I am confused how bcb9aa45d5a0 left the rq->engine dereference in
there after removing the extra reference.
Could it be that the intel_engine_is_virtual check simply needs to be
removed from i915_fence_release, restoring things to how they were
before 1e98d8c52ed5? Could you try it out?
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-11 15:27 ` Tvrtko Ursulin
@ 2023-07-12 12:18 ` Andrzej Hajda
2023-07-12 12:35 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-12 12:18 UTC (permalink / raw)
To: Tvrtko Ursulin, Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>
> On 11/07/2023 14:58, Andrzej Hajda wrote:
>> On 11.07.2023 13:34, Andi Shyti wrote:
>>> Hi Andrzej,
>>>
>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>> +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git
>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>> i915_request *rq, struct intel_context *ce)
>>>> static void remove_from_context(struct i915_request *rq)
>>>> {
>>>> struct intel_context *ce =
>>>> request_to_scheduling_context(rq);
>>>> + struct intel_engine_cs *engine;
>>>> + intel_engine_mask_t tmp;
>>>>
>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>
>>>> @@ -3478,6 +3480,15 @@ static void
>>>> remove_from_context(struct i915_request *rq)
>>>>
>>>> atomic_dec(&ce->guc_id.ref);
>>>> i915_request_notify_execute_cb_imm(rq);
>>>> +
>>>> + /*
>>>> + * GuC virtual engine can disappear after this
>>>> call, so let's assign
>>>> + * something valid, as driver expects this to be
>>>> always valid pointer.
>>>> + */
>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>> rq->execution_mask, tmp) {
>>>> + rq->engine = engine;
>>>>
>>>> yes... here the context might lose the virtual engine... I wonder
>>>> whether this is the rigth solution, though. Maybe we should set
>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>
>>>>
>>>> Setting NULL causes occasional null page de-reference in
>>>>
>>>> i915_request_wait_timeout:
>>>>
>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>
>>>> rq->engine after removing rq from context is (IMHO) used as a set of
>>>> aliases
>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>> without investigating further, but maybe that code is not even
>>> supposed to be executed, at this point, if the request's assigned
>>> virtual engine is removed.
>>
>> Real tests show it is executed and the function
>> i915_request_wait_timeout is quite generic
>> I guess it is quite typical use-case, the only question is about
>> timings - what happens earlier -
>> finalization of i915_request_wait_timeout or context removal.
>>
>> The other point rq->engine is accessed after context removal is
>> i915_fence_release -
>> there is long comment there regarding virtual context and reuse
>> retired rq.
>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is risky
>> without this patch and KASAN complains clearly about it:
>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>
> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915: Hold
> reference to intel_context over life of i915_request""), which was a
> partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
> intel_context over life of i915_request").
>
> Ie. if 1e98d8c52ed5 recognised the problem with disappearing rq->engine,
> then I am confused how bcb9aa45d5a0 left the rq->engine dereference in
> there after removing the extra reference.
>
> Could it be that the intel_engine_is_virtual check simply needs to be
> removed from i915_fence_release, restoring things to how they were
> before 1e98d8c52ed5? Could you try it out?
I have already tried something similar [1] and KASAN bugs disappeared,
or more precisely gem_exec_balance tests passed. But I have been warned
by Nirmoy guc virtual engines can be created for only one real engine
(ie. is_power_of_2(rq->execution_mask) is true but rq->engine points to
virtual engine).
[1]: https://patchwork.freedesktop.org/series/118879/
Regards
Andrzej
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-12 12:18 ` Andrzej Hajda
@ 2023-07-12 12:35 ` Tvrtko Ursulin
2023-07-12 16:27 ` Andrzej Hajda
0 siblings, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-12 12:35 UTC (permalink / raw)
To: Andrzej Hajda, Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 12/07/2023 13:18, Andrzej Hajda wrote:
> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>
>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>> Hi Andrzej,
>>>>
>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>> +++++++++++
>>>>> 1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>>> i915_request *rq, struct intel_context *ce)
>>>>> static void remove_from_context(struct i915_request *rq)
>>>>> {
>>>>> struct intel_context *ce =
>>>>> request_to_scheduling_context(rq);
>>>>> + struct intel_engine_cs *engine;
>>>>> + intel_engine_mask_t tmp;
>>>>>
>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>
>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>> remove_from_context(struct i915_request *rq)
>>>>>
>>>>> atomic_dec(&ce->guc_id.ref);
>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>> +
>>>>> + /*
>>>>> + * GuC virtual engine can disappear after this
>>>>> call, so let's assign
>>>>> + * something valid, as driver expects this to be
>>>>> always valid pointer.
>>>>> + */
>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>> rq->execution_mask, tmp) {
>>>>> + rq->engine = engine;
>>>>>
>>>>> yes... here the context might lose the virtual engine... I wonder
>>>>> whether this is the rigth solution, though. Maybe we should set
>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>
>>>>>
>>>>> Setting NULL causes occasional null page de-reference in
>>>>>
>>>>> i915_request_wait_timeout:
>>>>>
>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>
>>>>> rq->engine after removing rq from context is (IMHO) used as a set
>>>>> of aliases
>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>> without investigating further, but maybe that code is not even
>>>> supposed to be executed, at this point, if the request's assigned
>>>> virtual engine is removed.
>>>
>>> Real tests show it is executed and the function
>>> i915_request_wait_timeout is quite generic
>>> I guess it is quite typical use-case, the only question is about
>>> timings - what happens earlier -
>>> finalization of i915_request_wait_timeout or context removal.
>>>
>>> The other point rq->engine is accessed after context removal is
>>> i915_fence_release -
>>> there is long comment there regarding virtual context and reuse
>>> retired rq.
>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is risky
>>> without this patch and KASAN complains clearly about it:
>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>
>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915: Hold
>> reference to intel_context over life of i915_request""), which was a
>> partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
>> intel_context over life of i915_request").
>>
>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>> rq->engine, then I am confused how bcb9aa45d5a0 left the rq->engine
>> dereference in there after removing the extra reference.
>>
>> Could it be that the intel_engine_is_virtual check simply needs to be
>> removed from i915_fence_release, restoring things to how they were
>> before 1e98d8c52ed5? Could you try it out?
>
>
> I have already tried something similar [1] and KASAN bugs disappeared,
> or more precisely gem_exec_balance tests passed. But I have been warned
> by Nirmoy guc virtual engines can be created for only one real engine
> (ie. is_power_of_2(rq->execution_mask) is true but rq->engine points to
> virtual engine).
>
> [1]: https://patchwork.freedesktop.org/series/118879/
Ugh.. Try involving media umd folks to see if they need a single engine
virtual engine? Or we could always just not create it in the driver, I
mean just use the physical one.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-12 12:35 ` Tvrtko Ursulin
@ 2023-07-12 16:27 ` Andrzej Hajda
2023-07-12 18:54 ` John Harrison
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-12 16:27 UTC (permalink / raw)
To: Tvrtko Ursulin, Andi Shyti; +Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>
> On 12/07/2023 13:18, Andrzej Hajda wrote:
>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>
>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>> Hi Andrzej,
>>>>>
>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>> +++++++++++
>>>>>> 1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>>>> i915_request *rq, struct intel_context *ce)
>>>>>> static void remove_from_context(struct i915_request *rq)
>>>>>> {
>>>>>> struct intel_context *ce =
>>>>>> request_to_scheduling_context(rq);
>>>>>> + struct intel_engine_cs *engine;
>>>>>> + intel_engine_mask_t tmp;
>>>>>>
>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>
>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>
>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>> +
>>>>>> + /*
>>>>>> + * GuC virtual engine can disappear after this
>>>>>> call, so let's assign
>>>>>> + * something valid, as driver expects this to be
>>>>>> always valid pointer.
>>>>>> + */
>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>> rq->execution_mask, tmp) {
>>>>>> + rq->engine = engine;
>>>>>>
>>>>>> yes... here the context might lose the virtual engine... I
>>>>>> wonder
>>>>>> whether this is the rigth solution, though. Maybe we should set
>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>
>>>>>>
>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>
>>>>>> i915_request_wait_timeout:
>>>>>>
>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>
>>>>>> rq->engine after removing rq from context is (IMHO) used as a set
>>>>>> of aliases
>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>> without investigating further, but maybe that code is not even
>>>>> supposed to be executed, at this point, if the request's assigned
>>>>> virtual engine is removed.
>>>>
>>>> Real tests show it is executed and the function
>>>> i915_request_wait_timeout is quite generic
>>>> I guess it is quite typical use-case, the only question is about
>>>> timings - what happens earlier -
>>>> finalization of i915_request_wait_timeout or context removal.
>>>>
>>>> The other point rq->engine is accessed after context removal is
>>>> i915_fence_release -
>>>> there is long comment there regarding virtual context and reuse
>>>> retired rq.
>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is risky
>>>> without this patch and KASAN complains clearly about it:
>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>
>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915: Hold
>>> reference to intel_context over life of i915_request""), which was a
>>> partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
>>> intel_context over life of i915_request").
>>>
>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>> rq->engine, then I am confused how bcb9aa45d5a0 left the rq->engine
>>> dereference in there after removing the extra reference.
>>>
>>> Could it be that the intel_engine_is_virtual check simply needs to be
>>> removed from i915_fence_release, restoring things to how they were
>>> before 1e98d8c52ed5? Could you try it out?
>>
>>
>> I have already tried something similar [1] and KASAN bugs disappeared,
>> or more precisely gem_exec_balance tests passed. But I have been
>> warned by Nirmoy guc virtual engines can be created for only one real
>> engine (ie. is_power_of_2(rq->execution_mask) is true but rq->engine
>> points to virtual engine).
>>
>> [1]: https://patchwork.freedesktop.org/series/118879/
>
> Ugh.. Try involving media umd folks to see if they need a single engine
> virtual engine? Or we could always just not create it in the driver, I
> mean just use the physical one.
In case there is single physical engine intel_engine_create_virtual
falls back to intel_context_create (no virtual engine), but in case of
parallel contexts there is special KMD flag FORCE_VIRTUAL which enforces
virtual engine even for single physical engine. So it seems to be KMD
concept.
Anyway is it worth investigating how to make
"is_power_of_2(rq->execution_mask)" indication of dangling engine
pointer? It will not help in 1st case:
mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
Regards
Andrzej
>
> Regards,
>
> Tvrtko
>
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-12 16:27 ` Andrzej Hajda
@ 2023-07-12 18:54 ` John Harrison
2023-07-13 7:39 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: John Harrison @ 2023-07-12 18:54 UTC (permalink / raw)
To: Andrzej Hajda, Tvrtko Ursulin, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 7/12/2023 09:27, Andrzej Hajda wrote:
> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>> Hi Andrzej,
>>>>>>
>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>>>>> i915_request *rq, struct intel_context *ce)
>>>>>>> static void remove_from_context(struct i915_request *rq)
>>>>>>> {
>>>>>>> struct intel_context *ce =
>>>>>>> request_to_scheduling_context(rq);
>>>>>>> + struct intel_engine_cs *engine;
>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>
>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>
>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>
>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>> +
>>>>>>> + /*
>>>>>>> + * GuC virtual engine can disappear after this
>>>>>>> call, so let's assign
>>>>>>> + * something valid, as driver expects this to
>>>>>>> be always valid pointer.
>>>>>>> + */
>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>> rq->execution_mask, tmp) {
>>>>>>> + rq->engine = engine;
>>>>>>>
>>>>>>> yes... here the context might lose the virtual engine... I
>>>>>>> wonder
>>>>>>> whether this is the rigth solution, though. Maybe we should
>>>>>>> set
>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>
>>>>>>>
>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>
>>>>>>> i915_request_wait_timeout:
>>>>>>>
>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>
>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>> set of aliases
>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>> without investigating further, but maybe that code is not even
>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>> virtual engine is removed.
>>>>>
>>>>> Real tests show it is executed and the function
>>>>> i915_request_wait_timeout is quite generic
>>>>> I guess it is quite typical use-case, the only question is about
>>>>> timings - what happens earlier -
>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>
>>>>> The other point rq->engine is accessed after context removal is
>>>>> i915_fence_release -
>>>>> there is long comment there regarding virtual context and reuse
>>>>> retired rq.
>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>> risky without this patch and KASAN complains clearly about it:
>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>
>>>>
>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>> Hold reference to intel_context over life of i915_request""), which
>>>> was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
>>>> intel_context over life of i915_request").
>>>>
>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the rq->engine
>>>> dereference in there after removing the extra reference.
>>>>
>>>> Could it be that the intel_engine_is_virtual check simply needs to
>>>> be removed from i915_fence_release, restoring things to how they
>>>> were before 1e98d8c52ed5? Could you try it out?
>>>
>>>
>>> I have already tried something similar [1] and KASAN bugs
>>> disappeared, or more precisely gem_exec_balance tests passed. But I
>>> have been warned by Nirmoy guc virtual engines can be created for
>>> only one real engine (ie. is_power_of_2(rq->execution_mask) is true
>>> but rq->engine points to virtual engine).
>>>
>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>
>> Ugh.. Try involving media umd folks to see if they need a single
>> engine virtual engine? Or we could always just not create it in the
>> driver, I mean just use the physical one.
>
>
> In case there is single physical engine intel_engine_create_virtual
> falls back to intel_context_create (no virtual engine), but in case of
> parallel contexts there is special KMD flag FORCE_VIRTUAL which
> enforces virtual engine even for single physical engine. So it seems
> to be KMD concept.
>
> Anyway is it worth investigating how to make
> "is_power_of_2(rq->execution_mask)" indication of dangling engine
> pointer? It will not help in 1st case:
> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>
>
There seems to be a fundamental problem here. Object 1 (rq) is holding a
pointer to a reference counted and transient object 2 (engine) but
without taking a reference count for itself. That is a Bad Thing(tm).
I'm not following the description in the revert patch as to why rq can't
ref count the context/engine. Is there actually a recursive counting
problem? Or is it just a lifetime issue caused by requests hanging
around indefinitely because they are locked by a user process?
Either way, jumping through convoluted hoops to ensure the code does not
attempt to dereference a dangling pointer seems like the wrong fix.
Removing the engine pointer when the request is completed and no longer
dependent upon an engine (but before the engine can possibly be
destroyed) seems like a much better solution. And then making the
request handling code check for and cope with a null engine pointer. It
sounds like the only problem there is the above mutex, but there is an
alternate route to that? Although why a completed request would need
access to a GT reset mutex seems confusing. If the request is done, then
what connection does it still have to the GT?
John.
> Regards
> Andrzej
>
>
>>
>> Regards,
>>
>> Tvrtko
>>
>>
>>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-12 18:54 ` John Harrison
@ 2023-07-13 7:39 ` Tvrtko Ursulin
2023-07-13 8:56 ` Tvrtko Ursulin
2023-07-13 11:09 ` Andrzej Hajda
0 siblings, 2 replies; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-13 7:39 UTC (permalink / raw)
To: John Harrison, Andrzej Hajda, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 12/07/2023 19:54, John Harrison wrote:
> On 7/12/2023 09:27, Andrzej Hajda wrote:
>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>> Hi Andrzej,
>>>>>>>
>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>>>>>> i915_request *rq, struct intel_context *ce)
>>>>>>>> static void remove_from_context(struct i915_request *rq)
>>>>>>>> {
>>>>>>>> struct intel_context *ce =
>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>
>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>
>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>
>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>> +
>>>>>>>> + /*
>>>>>>>> + * GuC virtual engine can disappear after this
>>>>>>>> call, so let's assign
>>>>>>>> + * something valid, as driver expects this to
>>>>>>>> be always valid pointer.
>>>>>>>> + */
>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>> + rq->engine = engine;
>>>>>>>>
>>>>>>>> yes... here the context might lose the virtual engine... I
>>>>>>>> wonder
>>>>>>>> whether this is the rigth solution, though. Maybe we should
>>>>>>>> set
>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>
>>>>>>>>
>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>
>>>>>>>> i915_request_wait_timeout:
>>>>>>>>
>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>
>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>> set of aliases
>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>> without investigating further, but maybe that code is not even
>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>> virtual engine is removed.
>>>>>>
>>>>>> Real tests show it is executed and the function
>>>>>> i915_request_wait_timeout is quite generic
>>>>>> I guess it is quite typical use-case, the only question is about
>>>>>> timings - what happens earlier -
>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>
>>>>>> The other point rq->engine is accessed after context removal is
>>>>>> i915_fence_release -
>>>>>> there is long comment there regarding virtual context and reuse
>>>>>> retired rq.
>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>
>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>> Hold reference to intel_context over life of i915_request""), which
>>>>> was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold reference to
>>>>> intel_context over life of i915_request").
>>>>>
>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the rq->engine
>>>>> dereference in there after removing the extra reference.
>>>>>
>>>>> Could it be that the intel_engine_is_virtual check simply needs to
>>>>> be removed from i915_fence_release, restoring things to how they
>>>>> were before 1e98d8c52ed5? Could you try it out?
>>>>
>>>>
>>>> I have already tried something similar [1] and KASAN bugs
>>>> disappeared, or more precisely gem_exec_balance tests passed. But I
>>>> have been warned by Nirmoy guc virtual engines can be created for
>>>> only one real engine (ie. is_power_of_2(rq->execution_mask) is true
>>>> but rq->engine points to virtual engine).
>>>>
>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>
>>> Ugh.. Try involving media umd folks to see if they need a single
>>> engine virtual engine? Or we could always just not create it in the
>>> driver, I mean just use the physical one.
>>
>>
>> In case there is single physical engine intel_engine_create_virtual
>> falls back to intel_context_create (no virtual engine), but in case of
>> parallel contexts there is special KMD flag FORCE_VIRTUAL which
>> enforces virtual engine even for single physical engine. So it seems
>> to be KMD concept.
>>
>> Anyway is it worth investigating how to make
>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>> pointer? It will not help in 1st case:
>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>
>>
> There seems to be a fundamental problem here. Object 1 (rq) is holding a
> pointer to a reference counted and transient object 2 (engine) but
> without taking a reference count for itself. That is a Bad Thing(tm).
> I'm not following the description in the revert patch as to why rq can't
> ref count the context/engine. Is there actually a recursive counting
> problem? Or is it just a lifetime issue caused by requests hanging
> around indefinitely because they are locked by a user process?
>
> Either way, jumping through convoluted hoops to ensure the code does not
> attempt to dereference a dangling pointer seems like the wrong fix.
> Removing the engine pointer when the request is completed and no longer
> dependent upon an engine (but before the engine can possibly be
> destroyed) seems like a much better solution. And then making the
> request handling code check for and cope with a null engine pointer. It
> sounds like the only problem there is the above mutex, but there is an
> alternate route to that? Although why a completed request would need
> access to a GT reset mutex seems confusing. If the request is done, then
> what connection does it still have to the GT?
Agreed in principle but the question is how invasive would it be to
change the rules.
With the latest info that the issue is really just the GuC _parallel_
engine setup, and looking at the code, I wonder if we couldn't just flag
the rq->flags with "kernel context request". The code in
i915_fence_release claims the rq pool is only relevant for those so it
sounds it would be safe to skip everything else based on that new flag.
For the mutex_release path, presumable the bad deref is only _after_ the
wait, right? (Only once the request has been retired.)
In which case caching the gt pointer at the start of
i915_request_wait_timeout would be sufficient.
That should be a few lines fixup overall and then the idea of allowing
rq->engine to be reset to NULL can be explored more leisurely.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 7:39 ` Tvrtko Ursulin
@ 2023-07-13 8:56 ` Tvrtko Ursulin
2023-07-13 11:59 ` Andrzej Hajda
2023-07-13 11:09 ` Andrzej Hajda
1 sibling, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-13 8:56 UTC (permalink / raw)
To: John Harrison, Andrzej Hajda, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 13/07/2023 08:39, Tvrtko Ursulin wrote:
>
> On 12/07/2023 19:54, John Harrison wrote:
>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>> Hi Andrzej,
>>>>>>>>
>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++++
>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> @@ -3461,6 +3461,8 @@ static void guc_prio_fini(struct
>>>>>>>>> i915_request *rq, struct intel_context *ce)
>>>>>>>>> static void remove_from_context(struct i915_request *rq)
>>>>>>>>> {
>>>>>>>>> struct intel_context *ce =
>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>
>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>
>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>
>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>> +
>>>>>>>>> + /*
>>>>>>>>> + * GuC virtual engine can disappear after this
>>>>>>>>> call, so let's assign
>>>>>>>>> + * something valid, as driver expects this to
>>>>>>>>> be always valid pointer.
>>>>>>>>> + */
>>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>>> + rq->engine = engine;
>>>>>>>>>
>>>>>>>>> yes... here the context might lose the virtual engine... I
>>>>>>>>> wonder
>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>> should set
>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>
>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>
>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>
>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>>> set of aliases
>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>>> virtual engine is removed.
>>>>>>>
>>>>>>> Real tests show it is executed and the function
>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>> I guess it is quite typical use-case, the only question is about
>>>>>>> timings - what happens earlier -
>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>
>>>>>>> The other point rq->engine is accessed after context removal is
>>>>>>> i915_fence_release -
>>>>>>> there is long comment there regarding virtual context and reuse
>>>>>>> retired rq.
>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>
>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>> reference to intel_context over life of i915_request").
>>>>>>
>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>> rq->engine dereference in there after removing the extra reference.
>>>>>>
>>>>>> Could it be that the intel_engine_is_virtual check simply needs to
>>>>>> be removed from i915_fence_release, restoring things to how they
>>>>>> were before 1e98d8c52ed5? Could you try it out?
>>>>>
>>>>>
>>>>> I have already tried something similar [1] and KASAN bugs
>>>>> disappeared, or more precisely gem_exec_balance tests passed. But I
>>>>> have been warned by Nirmoy guc virtual engines can be created for
>>>>> only one real engine (ie. is_power_of_2(rq->execution_mask) is true
>>>>> but rq->engine points to virtual engine).
>>>>>
>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>
>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>> engine virtual engine? Or we could always just not create it in the
>>>> driver, I mean just use the physical one.
>>>
>>>
>>> In case there is single physical engine intel_engine_create_virtual
>>> falls back to intel_context_create (no virtual engine), but in case
>>> of parallel contexts there is special KMD flag FORCE_VIRTUAL which
>>> enforces virtual engine even for single physical engine. So it seems
>>> to be KMD concept.
>>>
>>> Anyway is it worth investigating how to make
>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>> pointer? It will not help in 1st case:
>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>
>>>
>> There seems to be a fundamental problem here. Object 1 (rq) is holding
>> a pointer to a reference counted and transient object 2 (engine) but
>> without taking a reference count for itself. That is a Bad Thing(tm).
>> I'm not following the description in the revert patch as to why rq
>> can't ref count the context/engine. Is there actually a recursive
>> counting problem? Or is it just a lifetime issue caused by requests
>> hanging around indefinitely because they are locked by a user process?
>>
>> Either way, jumping through convoluted hoops to ensure the code does
>> not attempt to dereference a dangling pointer seems like the wrong
>> fix. Removing the engine pointer when the request is completed and no
>> longer dependent upon an engine (but before the engine can possibly be
>> destroyed) seems like a much better solution. And then making the
>> request handling code check for and cope with a null engine pointer.
>> It sounds like the only problem there is the above mutex, but there is
>> an alternate route to that? Although why a completed request would
>> need access to a GT reset mutex seems confusing. If the request is
>> done, then what connection does it still have to the GT?
>
> Agreed in principle but the question is how invasive would it be to
> change the rules.
>
> With the latest info that the issue is really just the GuC _parallel_
> engine setup, and looking at the code, I wonder if we couldn't just flag
> the rq->flags with "kernel context request". The code in
> i915_fence_release claims the rq pool is only relevant for those so it
> sounds it would be safe to skip everything else based on that new flag.
>
> For the mutex_release path, presumable the bad deref is only _after_ the
> wait, right? (Only once the request has been retired.)
>
> In which case caching the gt pointer at the start of
> i915_request_wait_timeout would be sufficient.
Or not, think here I confused rq reference with (lack of) rq->engine reference. If I have then there is plenty of rq->engine dereferences in just the i915_request_wait_timeout call stack. So neither caching the gt or NULL rq->engine don't think would fly.
Going back to this patch, this comment:
+ /*
+ * GuC virtual engine can disappear after this call, so let's assign
+ * something valid, as driver expects this to be always valid pointer.
+ */
Is it that only GuC virtual engine can disappear after this call, or any virtual engine really? If the former why only with GuC?
Regards,
Tvrtko
> That should be a few lines fixup overall and then the idea of allowing
> rq->engine to be reset to NULL can be explored more leisurely.
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 7:39 ` Tvrtko Ursulin
2023-07-13 8:56 ` Tvrtko Ursulin
@ 2023-07-13 11:09 ` Andrzej Hajda
2023-07-13 12:11 ` Tvrtko Ursulin
1 sibling, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-13 11:09 UTC (permalink / raw)
To: Tvrtko Ursulin, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
Hi,
On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>
> On 12/07/2023 19:54, John Harrison wrote:
>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>> Hi Andrzej,
>>>>>>>>
>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>> +++++++++++
>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>>>>>>>>> static void remove_from_context(struct i915_request
>>>>>>>>> *rq)
>>>>>>>>> {
>>>>>>>>> struct intel_context *ce =
>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>
>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>
>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>
>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>> +
>>>>>>>>> + /*
>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>> this call, so let's assign
>>>>>>>>> + * something valid, as driver expects this to
>>>>>>>>> be always valid pointer.
>>>>>>>>> + */
>>>>>>>>> + for_each_engine_masked(engine,
>>>>>>>>> rq->engine->gt, rq->execution_mask, tmp) {
>>>>>>>>> + rq->engine = engine;
>>>>>>>>>
>>>>>>>>> yes... here the context might lose the virtual engine...
>>>>>>>>> I wonder
>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>> should set
>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>
>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>
>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>
>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>>> set of aliases
>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>>> virtual engine is removed.
>>>>>>>
>>>>>>> Real tests show it is executed and the function
>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>> I guess it is quite typical use-case, the only question is about
>>>>>>> timings - what happens earlier -
>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>
>>>>>>> The other point rq->engine is accessed after context removal is
>>>>>>> i915_fence_release -
>>>>>>> there is long comment there regarding virtual context and reuse
>>>>>>> retired rq.
>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>
>>>>>>
>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>> reference to intel_context over life of i915_request").
>>>>>>
>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>> rq->engine dereference in there after removing the extra reference.
>>>>>>
>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>
>>>>>
>>>>> I have already tried something similar [1] and KASAN bugs
>>>>> disappeared, or more precisely gem_exec_balance tests passed. But
>>>>> I have been warned by Nirmoy guc virtual engines can be created
>>>>> for only one real engine (ie. is_power_of_2(rq->execution_mask) is
>>>>> true but rq->engine points to virtual engine).
>>>>>
>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>
>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>> engine virtual engine? Or we could always just not create it in the
>>>> driver, I mean just use the physical one.
>>>
>>>
>>> In case there is single physical engine intel_engine_create_virtual
>>> falls back to intel_context_create (no virtual engine), but in case
>>> of parallel contexts there is special KMD flag FORCE_VIRTUAL which
>>> enforces virtual engine even for single physical engine. So it seems
>>> to be KMD concept.
>>>
>>> Anyway is it worth investigating how to make
>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>> pointer? It will not help in 1st case:
>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>
>>>
>> There seems to be a fundamental problem here. Object 1 (rq) is
>> holding a pointer to a reference counted and transient object 2
>> (engine) but without taking a reference count for itself. That is a
>> Bad Thing(tm).
Engine is not ref counted (at least directly), hardware engines seems to
be even persistent across whole life of i915.
I guess before introduction of virtual engines the assumption about
validity of rq->engine was correct and developers used it to access
rq->engine->gt, rq->engine->i915, etc
So the problems described here are probably leftovers of this change.
After virtual engines were introduced
"is_power_of_2(rq->execution_mask)" was used to detect rq->engine is
virtual.
And after adding parallel engines it does not seem to be valid check
anymore.
>> I'm not following the description in the revert patch as to why rq
>> can't ref count the context/engine. Is there actually a recursive
>> counting problem? Or is it just a lifetime issue caused by requests
>> hanging around indefinitely because they are locked by a user process?
>>
>> Either way, jumping through convoluted hoops to ensure the code does
>> not attempt to dereference a dangling pointer seems like the wrong
>> fix. Removing the engine pointer when the request is completed and no
>> longer dependent upon an engine (but before the engine can possibly
>> be destroyed) seems like a much better solution. And then making the
>> request handling code check for and cope with a null engine pointer.
>> It sounds like the only problem there is the above mutex, but there
>> is an alternate route to that? Although why a completed request would
>> need access to a GT reset mutex seems confusing. If the request is
>> done, then what connection does it still have to the GT?
>
> Agreed in principle but the question is how invasive would it be to
> change the rules.
>
> With the latest info that the issue is really just the GuC _parallel_
> engine setup, and looking at the code, I wonder if we couldn't just
> flag the rq->flags with "kernel context request". The code in
> i915_fence_release claims the rq pool is only relevant for those so it
> sounds it would be safe to skip everything else based on that new flag.
>
> For the mutex_release path, presumable the bad deref is only _after_
> the wait, right? (Only once the request has been retired.)
>
> In which case caching the gt pointer at the start of
> i915_request_wait_timeout would be sufficient.
>
> That should be a few lines fixup overall and then the idea of allowing
> rq->engine to be reset to NULL can be explored more leisurely.
I guess:
- setting engine to NULL in remove_from_context,
- caching gt pointer,
- checking for null pointer in i915_fence_release
should be enough to solve current issue. However I am not sure if there
are no more dragons hidden in other execution paths. I will try inspect
the code.
Btw there is rq->i915 but code only uses "rq->engine->i915" which way
shall we go? remove former or latter?
Regards
Andrzej
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 8:56 ` Tvrtko Ursulin
@ 2023-07-13 11:59 ` Andrzej Hajda
2023-07-13 12:22 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-13 11:59 UTC (permalink / raw)
To: Tvrtko Ursulin, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 13.07.2023 10:56, Tvrtko Ursulin wrote:
>
> On 13/07/2023 08:39, Tvrtko Ursulin wrote:
>>
>> On 12/07/2023 19:54, John Harrison wrote:
>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>> Hi Andrzej,
>>>>>>>>>
>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>> +++++++++++
>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git
>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>>>>>>>>>> static void remove_from_context(struct i915_request
>>>>>>>>>> *rq)
>>>>>>>>>> {
>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>
>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>
>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>
>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>> +
>>>>>>>>>> + /*
>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>> this call, so let's assign
>>>>>>>>>> + * something valid, as driver expects this to
>>>>>>>>>> be always valid pointer.
>>>>>>>>>> + */
>>>>>>>>>> + for_each_engine_masked(engine,
>>>>>>>>>> rq->engine->gt, rq->execution_mask, tmp) {
>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>
>>>>>>>>>> yes... here the context might lose the virtual engine...
>>>>>>>>>> I wonder
>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>> should set
>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>
>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>
>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>>
>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>>>> set of aliases
>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>>>> virtual engine is removed.
>>>>>>>>
>>>>>>>> Real tests show it is executed and the function
>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>> I guess it is quite typical use-case, the only question is about
>>>>>>>> timings - what happens earlier -
>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>
>>>>>>>> The other point rq->engine is accessed after context removal is
>>>>>>>> i915_fence_release -
>>>>>>>> there is long comment there regarding virtual context and reuse
>>>>>>>> retired rq.
>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>
>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>>> reference to intel_context over life of i915_request").
>>>>>>>
>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>> rq->engine dereference in there after removing the extra reference.
>>>>>>>
>>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>>
>>>>>>
>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>> disappeared, or more precisely gem_exec_balance tests passed. But
>>>>>> I have been warned by Nirmoy guc virtual engines can be created
>>>>>> for only one real engine (ie. is_power_of_2(rq->execution_mask) is
>>>>>> true but rq->engine points to virtual engine).
>>>>>>
>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>
>>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>>> engine virtual engine? Or we could always just not create it in the
>>>>> driver, I mean just use the physical one.
>>>>
>>>>
>>>> In case there is single physical engine intel_engine_create_virtual
>>>> falls back to intel_context_create (no virtual engine), but in case
>>>> of parallel contexts there is special KMD flag FORCE_VIRTUAL which
>>>> enforces virtual engine even for single physical engine. So it seems
>>>> to be KMD concept.
>>>>
>>>> Anyway is it worth investigating how to make
>>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>>> pointer? It will not help in 1st case:
>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>
>>>>
>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>> holding a pointer to a reference counted and transient object 2
>>> (engine) but without taking a reference count for itself. That is a
>>> Bad Thing(tm). I'm not following the description in the revert patch
>>> as to why rq can't ref count the context/engine. Is there actually a
>>> recursive counting problem? Or is it just a lifetime issue caused by
>>> requests hanging around indefinitely because they are locked by a
>>> user process?
>>>
>>> Either way, jumping through convoluted hoops to ensure the code does
>>> not attempt to dereference a dangling pointer seems like the wrong
>>> fix. Removing the engine pointer when the request is completed and no
>>> longer dependent upon an engine (but before the engine can possibly
>>> be destroyed) seems like a much better solution. And then making the
>>> request handling code check for and cope with a null engine pointer.
>>> It sounds like the only problem there is the above mutex, but there
>>> is an alternate route to that? Although why a completed request would
>>> need access to a GT reset mutex seems confusing. If the request is
>>> done, then what connection does it still have to the GT?
>>
>> Agreed in principle but the question is how invasive would it be to
>> change the rules.
>>
>> With the latest info that the issue is really just the GuC _parallel_
>> engine setup, and looking at the code, I wonder if we couldn't just
>> flag the rq->flags with "kernel context request". The code in
>> i915_fence_release claims the rq pool is only relevant for those so it
>> sounds it would be safe to skip everything else based on that new flag.
>>
>> For the mutex_release path, presumable the bad deref is only _after_
>> the wait, right? (Only once the request has been retired.)
>>
>> In which case caching the gt pointer at the start of
>> i915_request_wait_timeout would be sufficient.
>
> Or not, think here I confused rq reference with (lack of) rq->engine
> reference. If I have then there is plenty of rq->engine dereferences in
> just the i915_request_wait_timeout call stack. So neither caching the gt
> or NULL rq->engine don't think would fly.
>
> Going back to this patch, this comment:
>
> + /*
> + * GuC virtual engine can disappear after this call, so let's assign
> + * something valid, as driver expects this to be always valid pointer.
> + */
>
> Is it that only GuC virtual engine can disappear after this call, or any
> virtual engine really? If the former why only with GuC?
intel_engine_create_virtual creates virtual context ONLY if there are
multiple siblings or FORCE_VIRTUAL flag is used. The function is called
with this flag only from guc_create_parallel.
So for non-guc virtual engines rq->execution_mask can be tested to
detect if engine is/was virtual. Until some day somebody will start
using the flag :)
Anyway apparently timings and/or better context protection prevents
KASAN bugs appear for non-guc machines[1], ie in i915_fence_release
context/engine is still valid.
[1]: http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=balance
Regards
Andrzej
>
> Regards,
>
> Tvrtko
>
>> That should be a few lines fixup overall and then the idea of allowing
>> rq->engine to be reset to NULL can be explored more leisurely.
>>
>> Regards,
>>
>> Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 11:09 ` Andrzej Hajda
@ 2023-07-13 12:11 ` Tvrtko Ursulin
2023-07-17 18:03 ` John Harrison
0 siblings, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-13 12:11 UTC (permalink / raw)
To: Andrzej Hajda, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 13/07/2023 12:09, Andrzej Hajda wrote:
> Hi,
>
> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>
>> On 12/07/2023 19:54, John Harrison wrote:
>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>> Hi Andrzej,
>>>>>>>>>
>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>> +++++++++++
>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git
>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>>>>>>>>>> static void remove_from_context(struct i915_request
>>>>>>>>>> *rq)
>>>>>>>>>> {
>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>
>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>
>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>
>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>> +
>>>>>>>>>> + /*
>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>> this call, so let's assign
>>>>>>>>>> + * something valid, as driver expects this to
>>>>>>>>>> be always valid pointer.
>>>>>>>>>> + */
>>>>>>>>>> + for_each_engine_masked(engine,
>>>>>>>>>> rq->engine->gt, rq->execution_mask, tmp) {
>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>
>>>>>>>>>> yes... here the context might lose the virtual engine...
>>>>>>>>>> I wonder
>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>> should set
>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>
>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>
>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>>
>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>>>> set of aliases
>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>>>> virtual engine is removed.
>>>>>>>>
>>>>>>>> Real tests show it is executed and the function
>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>> I guess it is quite typical use-case, the only question is about
>>>>>>>> timings - what happens earlier -
>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>
>>>>>>>> The other point rq->engine is accessed after context removal is
>>>>>>>> i915_fence_release -
>>>>>>>> there is long comment there regarding virtual context and reuse
>>>>>>>> retired rq.
>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>
>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>>> reference to intel_context over life of i915_request").
>>>>>>>
>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>> rq->engine dereference in there after removing the extra reference.
>>>>>>>
>>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>>
>>>>>>
>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>> disappeared, or more precisely gem_exec_balance tests passed. But
>>>>>> I have been warned by Nirmoy guc virtual engines can be created
>>>>>> for only one real engine (ie. is_power_of_2(rq->execution_mask) is
>>>>>> true but rq->engine points to virtual engine).
>>>>>>
>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>
>>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>>> engine virtual engine? Or we could always just not create it in the
>>>>> driver, I mean just use the physical one.
>>>>
>>>>
>>>> In case there is single physical engine intel_engine_create_virtual
>>>> falls back to intel_context_create (no virtual engine), but in case
>>>> of parallel contexts there is special KMD flag FORCE_VIRTUAL which
>>>> enforces virtual engine even for single physical engine. So it seems
>>>> to be KMD concept.
>>>>
>>>> Anyway is it worth investigating how to make
>>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>>> pointer? It will not help in 1st case:
>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>
>>>>
>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>> holding a pointer to a reference counted and transient object 2
>>> (engine) but without taking a reference count for itself. That is a
>>> Bad Thing(tm).
>
> Engine is not ref counted (at least directly), hardware engines seems to
> be even persistent across whole life of i915.
> I guess before introduction of virtual engines the assumption about
> validity of rq->engine was correct and developers used it to access
> rq->engine->gt, rq->engine->i915, etc
> So the problems described here are probably leftovers of this change.
> After virtual engines were introduced
> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine is
> virtual.
> And after adding parallel engines it does not seem to be valid check
> anymore.
>
>>> I'm not following the description in the revert patch as to why rq
>>> can't ref count the context/engine. Is there actually a recursive
>>> counting problem? Or is it just a lifetime issue caused by requests
>>> hanging around indefinitely because they are locked by a user process?
>>>
>>> Either way, jumping through convoluted hoops to ensure the code does
>>> not attempt to dereference a dangling pointer seems like the wrong
>>> fix. Removing the engine pointer when the request is completed and no
>>> longer dependent upon an engine (but before the engine can possibly
>>> be destroyed) seems like a much better solution. And then making the
>>> request handling code check for and cope with a null engine pointer.
>>> It sounds like the only problem there is the above mutex, but there
>>> is an alternate route to that? Although why a completed request would
>>> need access to a GT reset mutex seems confusing. If the request is
>>> done, then what connection does it still have to the GT?
>>
>> Agreed in principle but the question is how invasive would it be to
>> change the rules.
>>
>> With the latest info that the issue is really just the GuC _parallel_
>> engine setup, and looking at the code, I wonder if we couldn't just
>> flag the rq->flags with "kernel context request". The code in
>> i915_fence_release claims the rq pool is only relevant for those so it
>> sounds it would be safe to skip everything else based on that new flag.
>>
>> For the mutex_release path, presumable the bad deref is only _after_
>> the wait, right? (Only once the request has been retired.)
>>
>> In which case caching the gt pointer at the start of
>> i915_request_wait_timeout would be sufficient.
>>
>> That should be a few lines fixup overall and then the idea of allowing
>> rq->engine to be reset to NULL can be explored more leisurely.
>
> I guess:
> - setting engine to NULL in remove_from_context,
> - caching gt pointer,
> - checking for null pointer in i915_fence_release
>
> should be enough to solve current issue. However I am not sure if there
> are no more dragons hidden in other execution paths. I will try inspect
> the code.
What you have in this patch, cheat by replacing the engine, *might* work for the short term *if* you can make sure all parallel readers will see the updated rq->engine pointer in time, before the old one gets freed.
For the longer term solution - maybe making the engine reference counted?
Or if setting rq->engine to NULL then evaluating the paths which derefence it. AFAIR these request retirement races have been generally tricky/annoying.
For instance under the i915_request_wait_timeout chain.
1)
__i915_spin_request - could be racy if request gets retired between i915_request_wait_timeout/dma_fence_is_signaled check and __i915_spin_request dereferencing rq->engine.props?
2)
intel_rps_boost - claims to be safe by serialising via i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents retire tearing down the engine between:
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
---> HERE - if whole retirement happens here <----
struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
3)
__intel_engine_flush_submission - could be racy to? What if the whole process of consuming the request by the backend and retirement happens between these two lines:
if (i915_request_is_ready(rq))
---> HERE <---
__intel_engine_flush_submission(rq->engine, false);
Then "is ready" can be true, but by the 2nd line request retired and rq->engine freed/NULL already.
Lets hope I am just making unwarranted panic by being to away from this area of the driver for a while. :) But if I am not, then it could be that rq->engine is just overall too problematic and perhaps we should have a look into making it reference counted by the request.
> Btw there is rq->i915 but code only uses "rq->engine->i915" which way
> shall we go? remove former or latter?
Simpler/shorter option should be better.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 11:59 ` Andrzej Hajda
@ 2023-07-13 12:22 ` Tvrtko Ursulin
0 siblings, 0 replies; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-13 12:22 UTC (permalink / raw)
To: Andrzej Hajda, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 13/07/2023 12:59, Andrzej Hajda wrote:
> On 13.07.2023 10:56, Tvrtko Ursulin wrote:
>>
>> On 13/07/2023 08:39, Tvrtko Ursulin wrote:
>>>
>>> On 12/07/2023 19:54, John Harrison wrote:
>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>
>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>> +++++++++++
>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git
>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context *ce)
>>>>>>>>>>> static void remove_from_context(struct i915_request
>>>>>>>>>>> *rq)
>>>>>>>>>>> {
>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>
>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>
>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>
>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>> +
>>>>>>>>>>> + /*
>>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>>> this call, so let's assign
>>>>>>>>>>> + * something valid, as driver expects this
>>>>>>>>>>> to be always valid pointer.
>>>>>>>>>>> + */
>>>>>>>>>>> + for_each_engine_masked(engine,
>>>>>>>>>>> rq->engine->gt, rq->execution_mask, tmp) {
>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>
>>>>>>>>>>> yes... here the context might lose the virtual engine...
>>>>>>>>>>> I wonder
>>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>>> should set
>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>
>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>
>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>>>
>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as a
>>>>>>>>>>> set of aliases
>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>>> supposed to be executed, at this point, if the request's assigned
>>>>>>>>>> virtual engine is removed.
>>>>>>>>>
>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>> about timings - what happens earlier -
>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>
>>>>>>>>> The other point rq->engine is accessed after context removal is
>>>>>>>>> i915_fence_release -
>>>>>>>>> there is long comment there regarding virtual context and reuse
>>>>>>>>> retired rq.
>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>
>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>>>> reference to intel_context over life of i915_request").
>>>>>>>>
>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>>> rq->engine dereference in there after removing the extra reference.
>>>>>>>>
>>>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>>>
>>>>>>>
>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>> disappeared, or more precisely gem_exec_balance tests passed. But
>>>>>>> I have been warned by Nirmoy guc virtual engines can be created
>>>>>>> for only one real engine (ie. is_power_of_2(rq->execution_mask)
>>>>>>> is true but rq->engine points to virtual engine).
>>>>>>>
>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>
>>>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>>>> engine virtual engine? Or we could always just not create it in
>>>>>> the driver, I mean just use the physical one.
>>>>>
>>>>>
>>>>> In case there is single physical engine intel_engine_create_virtual
>>>>> falls back to intel_context_create (no virtual engine), but in case
>>>>> of parallel contexts there is special KMD flag FORCE_VIRTUAL which
>>>>> enforces virtual engine even for single physical engine. So it
>>>>> seems to be KMD concept.
>>>>>
>>>>> Anyway is it worth investigating how to make
>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>>>> pointer? It will not help in 1st case:
>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>
>>>>>
>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>> holding a pointer to a reference counted and transient object 2
>>>> (engine) but without taking a reference count for itself. That is a
>>>> Bad Thing(tm). I'm not following the description in the revert patch
>>>> as to why rq can't ref count the context/engine. Is there actually a
>>>> recursive counting problem? Or is it just a lifetime issue caused by
>>>> requests hanging around indefinitely because they are locked by a
>>>> user process?
>>>>
>>>> Either way, jumping through convoluted hoops to ensure the code does
>>>> not attempt to dereference a dangling pointer seems like the wrong
>>>> fix. Removing the engine pointer when the request is completed and
>>>> no longer dependent upon an engine (but before the engine can
>>>> possibly be destroyed) seems like a much better solution. And then
>>>> making the request handling code check for and cope with a null
>>>> engine pointer. It sounds like the only problem there is the above
>>>> mutex, but there is an alternate route to that? Although why a
>>>> completed request would need access to a GT reset mutex seems
>>>> confusing. If the request is done, then what connection does it
>>>> still have to the GT?
>>>
>>> Agreed in principle but the question is how invasive would it be to
>>> change the rules.
>>>
>>> With the latest info that the issue is really just the GuC _parallel_
>>> engine setup, and looking at the code, I wonder if we couldn't just
>>> flag the rq->flags with "kernel context request". The code in
>>> i915_fence_release claims the rq pool is only relevant for those so
>>> it sounds it would be safe to skip everything else based on that new
>>> flag.
>>>
>>> For the mutex_release path, presumable the bad deref is only _after_
>>> the wait, right? (Only once the request has been retired.)
>>>
>>> In which case caching the gt pointer at the start of
>>> i915_request_wait_timeout would be sufficient.
>>
>> Or not, think here I confused rq reference with (lack of) rq->engine
>> reference. If I have then there is plenty of rq->engine dereferences
>> in just the i915_request_wait_timeout call stack. So neither caching
>> the gt or NULL rq->engine don't think would fly.
>>
>> Going back to this patch, this comment:
>>
>> + /*
>> + * GuC virtual engine can disappear after this call, so let's assign
>> + * something valid, as driver expects this to be always valid
>> pointer.
>> + */
>>
>> Is it that only GuC virtual engine can disappear after this call, or
>> any virtual engine really? If the former why only with GuC?
>
>
> intel_engine_create_virtual creates virtual context ONLY if there are
> multiple siblings or FORCE_VIRTUAL flag is used. The function is called
> with this flag only from guc_create_parallel.
> So for non-guc virtual engines rq->execution_mask can be tested to
> detect if engine is/was virtual. Until some day somebody will start
> using the flag :)
> Anyway apparently timings and/or better context protection prevents
> KASAN bugs appear for non-guc machines[1], ie in i915_fence_release
> context/engine is still valid.
>
> [1]: http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=balance
Right, point of my question was that we need to be sure is the comment
accurate. Perhaps the issue is not just with the GuC virtual engines and
request wait path could hit it with execlists too (2+ wide virtual engines).
If the final intel_context_put happens via i915_request_retire ->
intel_context_unpin -> intel_context_put -> virtual_context_destroy ->
rcu_virtual_context_destroy -> kfree(ve) then rq->engine also becomes
invalid as observed from the request wait running in parallel.
Don't think RCU is enough to make this safe, but the fact GuC side uses
a straight worker might be making it easier to hit there.
Please double check my thinking here.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-13 12:11 ` Tvrtko Ursulin
@ 2023-07-17 18:03 ` John Harrison
2023-07-18 15:48 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: John Harrison @ 2023-07-17 18:03 UTC (permalink / raw)
To: Tvrtko Ursulin, Andrzej Hajda, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 7/13/2023 05:11, Tvrtko Ursulin wrote:
> On 13/07/2023 12:09, Andrzej Hajda wrote:
>> Hi,
>>
>> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>> On 12/07/2023 19:54, John Harrison wrote:
>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>
>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>> +++++++++++
>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git
>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>> ---
>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> +++
>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context
>>>>>>>>>>> *ce)
>>>>>>>>>>> static void remove_from_context(struct
>>>>>>>>>>> i915_request *rq)
>>>>>>>>>>> {
>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>
>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>
>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>
>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>> +
>>>>>>>>>>> + /*
>>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>>> this call, so let's assign
>>>>>>>>>>> + * something valid, as driver expects this
>>>>>>>>>>> to be always valid pointer.
>>>>>>>>>>> + */
>>>>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>
>>>>>>>>>>> yes... here the context might lose the virtual
>>>>>>>>>>> engine... I wonder
>>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>>> should set
>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>
>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>
>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>>>
>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as
>>>>>>>>>>> a set of aliases
>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>>> supposed to be executed, at this point, if the request's
>>>>>>>>>> assigned
>>>>>>>>>> virtual engine is removed.
>>>>>>>>>
>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>> about timings - what happens earlier -
>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>
>>>>>>>>> The other point rq->engine is accessed after context removal
>>>>>>>>> is i915_fence_release -
>>>>>>>>> there is long comment there regarding virtual context and
>>>>>>>>> reuse retired rq.
>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>>
>>>>>>>>
>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>>>> reference to intel_context over life of i915_request").
>>>>>>>>
>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>>> rq->engine dereference in there after removing the extra
>>>>>>>> reference.
>>>>>>>>
>>>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>>>
>>>>>>>
>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>> disappeared, or more precisely gem_exec_balance tests passed.
>>>>>>> But I have been warned by Nirmoy guc virtual engines can be
>>>>>>> created for only one real engine (ie.
>>>>>>> is_power_of_2(rq->execution_mask) is true but rq->engine points
>>>>>>> to virtual engine).
>>>>>>>
>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>
>>>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>>>> engine virtual engine? Or we could always just not create it in
>>>>>> the driver, I mean just use the physical one.
>>>>>
>>>>>
>>>>> In case there is single physical engine
>>>>> intel_engine_create_virtual falls back to intel_context_create (no
>>>>> virtual engine), but in case of parallel contexts there is special
>>>>> KMD flag FORCE_VIRTUAL which enforces virtual engine even for
>>>>> single physical engine. So it seems to be KMD concept.
>>>>>
>>>>> Anyway is it worth investigating how to make
>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>>>> pointer? It will not help in 1st case:
>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>
>>>>>
>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>> holding a pointer to a reference counted and transient object 2
>>>> (engine) but without taking a reference count for itself. That is a
>>>> Bad Thing(tm).
>>
>> Engine is not ref counted (at least directly), hardware engines seems
>> to be even persistent across whole life of i915.
>> I guess before introduction of virtual engines the assumption about
>> validity of rq->engine was correct and developers used it to access
>> rq->engine->gt, rq->engine->i915, etc
>> So the problems described here are probably leftovers of this change.
>> After virtual engines were introduced
>> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine is
>> virtual.
>> And after adding parallel engines it does not seem to be valid check
>> anymore.
>>
>>>> I'm not following the description in the revert patch as to why rq
>>>> can't ref count the context/engine. Is there actually a recursive
>>>> counting problem? Or is it just a lifetime issue caused by requests
>>>> hanging around indefinitely because they are locked by a user process?
>>>>
>>>> Either way, jumping through convoluted hoops to ensure the code
>>>> does not attempt to dereference a dangling pointer seems like the
>>>> wrong fix. Removing the engine pointer when the request is
>>>> completed and no longer dependent upon an engine (but before the
>>>> engine can possibly be destroyed) seems like a much better
>>>> solution. And then making the request handling code check for and
>>>> cope with a null engine pointer. It sounds like the only problem
>>>> there is the above mutex, but there is an alternate route to that?
>>>> Although why a completed request would need access to a GT reset
>>>> mutex seems confusing. If the request is done, then what connection
>>>> does it still have to the GT?
>>>
>>> Agreed in principle but the question is how invasive would it be to
>>> change the rules.
>>>
>>> With the latest info that the issue is really just the GuC
>>> _parallel_ engine setup, and looking at the code, I wonder if we
>>> couldn't just flag the rq->flags with "kernel context request". The
>>> code in i915_fence_release claims the rq pool is only relevant for
>>> those so it sounds it would be safe to skip everything else based on
>>> that new flag.
>>>
>>> For the mutex_release path, presumable the bad deref is only _after_
>>> the wait, right? (Only once the request has been retired.)
>>>
>>> In which case caching the gt pointer at the start of
>>> i915_request_wait_timeout would be sufficient.
>>>
>>> That should be a few lines fixup overall and then the idea of
>>> allowing rq->engine to be reset to NULL can be explored more leisurely.
>>
>> I guess:
>> - setting engine to NULL in remove_from_context,
>> - caching gt pointer,
>> - checking for null pointer in i915_fence_release
>>
>> should be enough to solve current issue. However I am not sure if
>> there are no more dragons hidden in other execution paths. I will try
>> inspect the code.
>
> What you have in this patch, cheat by replacing the engine, *might*
> work for the short term *if* you can make sure all parallel readers
> will see the updated rq->engine pointer in time, before the old one
> gets freed.
>
> For the longer term solution - maybe making the engine reference counted?
That was the point of the original solution - having the request
reference count the context. The context is what owns the virtual
engine. So ensuring that the context can't be destroyed while there are
requests outstanding on it ensured that rq->engine would always be
valid. Nice simple and clean solution.So why did that get reverted? What
is the problem with VM_BIND and having requests ensure that their
resources stay alive for the lifetime of the request?
John.
>
> Or if setting rq->engine to NULL then evaluating the paths which
> derefence it. AFAIR these request retirement races have been generally
> tricky/annoying.
>
> For instance under the i915_request_wait_timeout chain.
>
> 1)
> __i915_spin_request - could be racy if request gets retired between
> i915_request_wait_timeout/dma_fence_is_signaled check and
> __i915_spin_request dereferencing rq->engine.props?
>
> 2)
> intel_rps_boost - claims to be safe by serialising via
> i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents
> retire tearing down the engine between:
>
> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>
> ---> HERE - if whole retirement happens here <----
>
> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>
> 3)
> __intel_engine_flush_submission - could be racy to? What if the whole
> process of consuming the request by the backend and retirement happens
> between these two lines:
>
> if (i915_request_is_ready(rq))
>
> ---> HERE <---
> __intel_engine_flush_submission(rq->engine, false);
>
> Then "is ready" can be true, but by the 2nd line request retired and
> rq->engine freed/NULL already.
>
> Lets hope I am just making unwarranted panic by being to away from
> this area of the driver for a while. :) But if I am not, then it could
> be that rq->engine is just overall too problematic and perhaps we
> should have a look into making it reference counted by the request.
>
>> Btw there is rq->i915 but code only uses "rq->engine->i915" which way
>> shall we go? remove former or latter?
>
> Simpler/shorter option should be better.
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-17 18:03 ` John Harrison
@ 2023-07-18 15:48 ` Tvrtko Ursulin
2023-07-19 10:41 ` Andrzej Hajda
0 siblings, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-18 15:48 UTC (permalink / raw)
To: John Harrison, Andrzej Hajda, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 17/07/2023 19:03, John Harrison wrote:
> On 7/13/2023 05:11, Tvrtko Ursulin wrote:
>> On 13/07/2023 12:09, Andrzej Hajda wrote:
>>> Hi,
>>>
>>> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>>> On 12/07/2023 19:54, John Harrison wrote:
>>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>>
>>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>>> +++++++++++
>>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git
>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>>> ---
>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>> +++
>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct intel_context
>>>>>>>>>>>> *ce)
>>>>>>>>>>>> static void remove_from_context(struct
>>>>>>>>>>>> i915_request *rq)
>>>>>>>>>>>> {
>>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>>
>>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>>
>>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>>> +
>>>>>>>>>>>> + /*
>>>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>>>> this call, so let's assign
>>>>>>>>>>>> + * something valid, as driver expects this
>>>>>>>>>>>> to be always valid pointer.
>>>>>>>>>>>> + */
>>>>>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>>
>>>>>>>>>>>> yes... here the context might lose the virtual
>>>>>>>>>>>> engine... I wonder
>>>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>>>> should set
>>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>>
>>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>>
>>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>>>>
>>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used as
>>>>>>>>>>>> a set of aliases
>>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to i915).
>>>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>>>> supposed to be executed, at this point, if the request's
>>>>>>>>>>> assigned
>>>>>>>>>>> virtual engine is removed.
>>>>>>>>>>
>>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>>> about timings - what happens earlier -
>>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>>
>>>>>>>>>> The other point rq->engine is accessed after context removal
>>>>>>>>>> is i915_fence_release -
>>>>>>>>>> there is long comment there regarding virtual context and
>>>>>>>>>> reuse retired rq.
>>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)" is
>>>>>>>>>> risky without this patch and KASAN complains clearly about it:
>>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>>
>>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915:
>>>>>>>>> Hold reference to intel_context over life of i915_request""),
>>>>>>>>> which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold
>>>>>>>>> reference to intel_context over life of i915_request").
>>>>>>>>>
>>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>>>> rq->engine dereference in there after removing the extra
>>>>>>>>> reference.
>>>>>>>>>
>>>>>>>>> Could it be that the intel_engine_is_virtual check simply needs
>>>>>>>>> to be removed from i915_fence_release, restoring things to how
>>>>>>>>> they were before 1e98d8c52ed5? Could you try it out?
>>>>>>>>
>>>>>>>>
>>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>>> disappeared, or more precisely gem_exec_balance tests passed.
>>>>>>>> But I have been warned by Nirmoy guc virtual engines can be
>>>>>>>> created for only one real engine (ie.
>>>>>>>> is_power_of_2(rq->execution_mask) is true but rq->engine points
>>>>>>>> to virtual engine).
>>>>>>>>
>>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>>
>>>>>>> Ugh.. Try involving media umd folks to see if they need a single
>>>>>>> engine virtual engine? Or we could always just not create it in
>>>>>>> the driver, I mean just use the physical one.
>>>>>>
>>>>>>
>>>>>> In case there is single physical engine
>>>>>> intel_engine_create_virtual falls back to intel_context_create (no
>>>>>> virtual engine), but in case of parallel contexts there is special
>>>>>> KMD flag FORCE_VIRTUAL which enforces virtual engine even for
>>>>>> single physical engine. So it seems to be KMD concept.
>>>>>>
>>>>>> Anyway is it worth investigating how to make
>>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling engine
>>>>>> pointer? It will not help in 1st case:
>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>
>>>>>>
>>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>>> holding a pointer to a reference counted and transient object 2
>>>>> (engine) but without taking a reference count for itself. That is a
>>>>> Bad Thing(tm).
>>>
>>> Engine is not ref counted (at least directly), hardware engines seems
>>> to be even persistent across whole life of i915.
>>> I guess before introduction of virtual engines the assumption about
>>> validity of rq->engine was correct and developers used it to access
>>> rq->engine->gt, rq->engine->i915, etc
>>> So the problems described here are probably leftovers of this change.
>>> After virtual engines were introduced
>>> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine is
>>> virtual.
>>> And after adding parallel engines it does not seem to be valid check
>>> anymore.
>>>
>>>>> I'm not following the description in the revert patch as to why rq
>>>>> can't ref count the context/engine. Is there actually a recursive
>>>>> counting problem? Or is it just a lifetime issue caused by requests
>>>>> hanging around indefinitely because they are locked by a user process?
>>>>>
>>>>> Either way, jumping through convoluted hoops to ensure the code
>>>>> does not attempt to dereference a dangling pointer seems like the
>>>>> wrong fix. Removing the engine pointer when the request is
>>>>> completed and no longer dependent upon an engine (but before the
>>>>> engine can possibly be destroyed) seems like a much better
>>>>> solution. And then making the request handling code check for and
>>>>> cope with a null engine pointer. It sounds like the only problem
>>>>> there is the above mutex, but there is an alternate route to that?
>>>>> Although why a completed request would need access to a GT reset
>>>>> mutex seems confusing. If the request is done, then what connection
>>>>> does it still have to the GT?
>>>>
>>>> Agreed in principle but the question is how invasive would it be to
>>>> change the rules.
>>>>
>>>> With the latest info that the issue is really just the GuC
>>>> _parallel_ engine setup, and looking at the code, I wonder if we
>>>> couldn't just flag the rq->flags with "kernel context request". The
>>>> code in i915_fence_release claims the rq pool is only relevant for
>>>> those so it sounds it would be safe to skip everything else based on
>>>> that new flag.
>>>>
>>>> For the mutex_release path, presumable the bad deref is only _after_
>>>> the wait, right? (Only once the request has been retired.)
>>>>
>>>> In which case caching the gt pointer at the start of
>>>> i915_request_wait_timeout would be sufficient.
>>>>
>>>> That should be a few lines fixup overall and then the idea of
>>>> allowing rq->engine to be reset to NULL can be explored more leisurely.
>>>
>>> I guess:
>>> - setting engine to NULL in remove_from_context,
>>> - caching gt pointer,
>>> - checking for null pointer in i915_fence_release
>>>
>>> should be enough to solve current issue. However I am not sure if
>>> there are no more dragons hidden in other execution paths. I will try
>>> inspect the code.
>>
>> What you have in this patch, cheat by replacing the engine, *might*
>> work for the short term *if* you can make sure all parallel readers
>> will see the updated rq->engine pointer in time, before the old one
>> gets freed.
>>
>> For the longer term solution - maybe making the engine reference counted?
> That was the point of the original solution - having the request
> reference count the context. The context is what owns the virtual
> engine. So ensuring that the context can't be destroyed while there are
> requests outstanding on it ensured that rq->engine would always be
> valid. Nice simple and clean solution.So why did that get reverted? What
> is the problem with VM_BIND and having requests ensure that their
> resources stay alive for the lifetime of the request?
Don't ask me, but it perhaps it does read a bit vague from the commit message on its own:
commit bcb9aa45d5a0e11ef91245330c53cde214d15e8d (tag: intel/CI_DIGN_563)
Author: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Date: Wed Jun 15 00:13:47 2022 +0530
Revert "drm/i915: Hold reference to intel_context over life of i915_request"
This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.
The problem with this patch is that it makes i915_request to hold a
reference to intel_context, which in turn holds a reference on the VM.
This strong back referencing can lead to reference loops which leads
to resource leak.
An example is the upcoming VM_BIND work which requires VM to hold
a reference to some shared VM specific BO. But this BO's dma-resv
fences holds reference to the i915_request thus leading to reference
loop.
v2:
Do not use reserved requests for virtual engines
So I don't know what was the leak or was it permanent leak (?!) or not.
Given VM_BIND has been abandoned maybe this could even be unreverted. I don't see a problem with holding a reference for the request lifetime right now but could be wrong..
Regards,
Tvrtko
> John.
>
>
>>
>> Or if setting rq->engine to NULL then evaluating the paths which
>> derefence it. AFAIR these request retirement races have been generally
>> tricky/annoying.
>>
>> For instance under the i915_request_wait_timeout chain.
>>
>> 1)
>> __i915_spin_request - could be racy if request gets retired between
>> i915_request_wait_timeout/dma_fence_is_signaled check and
>> __i915_spin_request dereferencing rq->engine.props?
>>
>> 2)
>> intel_rps_boost - claims to be safe by serialising via
>> i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents
>> retire tearing down the engine between:
>>
>> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>>
>> ---> HERE - if whole retirement happens here <----
>>
>> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>>
>> 3)
>> __intel_engine_flush_submission - could be racy to? What if the whole
>> process of consuming the request by the backend and retirement happens
>> between these two lines:
>>
>> if (i915_request_is_ready(rq))
>>
>> ---> HERE <---
>> __intel_engine_flush_submission(rq->engine, false);
>>
>> Then "is ready" can be true, but by the 2nd line request retired and
>> rq->engine freed/NULL already.
>>
>> Lets hope I am just making unwarranted panic by being to away from
>> this area of the driver for a while. :) But if I am not, then it could
>> be that rq->engine is just overall too problematic and perhaps we
>> should have a look into making it reference counted by the request.
>>
>>> Btw there is rq->i915 but code only uses "rq->engine->i915" which way
>>> shall we go? remove former or latter?
>>
>> Simpler/shorter option should be better.
>>
>> Regards,
>>
>> Tvrtko
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-18 15:48 ` Tvrtko Ursulin
@ 2023-07-19 10:41 ` Andrzej Hajda
2023-07-19 12:43 ` Tvrtko Ursulin
0 siblings, 1 reply; 30+ messages in thread
From: Andrzej Hajda @ 2023-07-19 10:41 UTC (permalink / raw)
To: Tvrtko Ursulin, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 18.07.2023 17:48, Tvrtko Ursulin wrote:
>
> On 17/07/2023 19:03, John Harrison wrote:
>> On 7/13/2023 05:11, Tvrtko Ursulin wrote:
>>> On 13/07/2023 12:09, Andrzej Hajda wrote:
>>>> Hi,
>>>>
>>>> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>>>> On 12/07/2023 19:54, John Harrison wrote:
>>>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>>>
>>>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>>>> +++++++++++
>>>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git
>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>> +++
>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct
>>>>>>>>>>>>> intel_context *ce)
>>>>>>>>>>>>> static void remove_from_context(struct
>>>>>>>>>>>>> i915_request *rq)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>>>
>>>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>>>
>>>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>>>
>>>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + /*
>>>>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>>>>> this call, so let's assign
>>>>>>>>>>>>> + * something valid, as driver expects
>>>>>>>>>>>>> this to be always valid pointer.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes... here the context might lose the virtual
>>>>>>>>>>>>> engine... I wonder
>>>>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>>>>> should set
>>>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>>>
>>>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>>>
>>>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map,
>>>>>>>>>>>>> _THIS_IP_)
>>>>>>>>>>>>>
>>>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used
>>>>>>>>>>>>> as a set of aliases
>>>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to
>>>>>>>>>>>>> i915).
>>>>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>>>>> supposed to be executed, at this point, if the request's
>>>>>>>>>>>> assigned
>>>>>>>>>>>> virtual engine is removed.
>>>>>>>>>>>
>>>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>>>> about timings - what happens earlier -
>>>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>>>
>>>>>>>>>>> The other point rq->engine is accessed after context removal
>>>>>>>>>>> is i915_fence_release -
>>>>>>>>>>> there is long comment there regarding virtual context and
>>>>>>>>>>> reuse retired rq.
>>>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)"
>>>>>>>>>>> is risky without this patch and KASAN complains clearly
>>>>>>>>>>> about it:
>>>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert
>>>>>>>>>> "drm/i915: Hold reference to intel_context over life of
>>>>>>>>>> i915_request""), which was a partial revert of 1e98d8c52ed5
>>>>>>>>>> ("drm/i915: Hold reference to intel_context over life of
>>>>>>>>>> i915_request").
>>>>>>>>>>
>>>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>>>>> rq->engine dereference in there after removing the extra
>>>>>>>>>> reference.
>>>>>>>>>>
>>>>>>>>>> Could it be that the intel_engine_is_virtual check simply
>>>>>>>>>> needs to be removed from i915_fence_release, restoring things
>>>>>>>>>> to how they were before 1e98d8c52ed5? Could you try it out?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>>>> disappeared, or more precisely gem_exec_balance tests passed.
>>>>>>>>> But I have been warned by Nirmoy guc virtual engines can be
>>>>>>>>> created for only one real engine (ie.
>>>>>>>>> is_power_of_2(rq->execution_mask) is true but rq->engine
>>>>>>>>> points to virtual engine).
>>>>>>>>>
>>>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>>>
>>>>>>>> Ugh.. Try involving media umd folks to see if they need a
>>>>>>>> single engine virtual engine? Or we could always just not
>>>>>>>> create it in the driver, I mean just use the physical one.
>>>>>>>
>>>>>>>
>>>>>>> In case there is single physical engine
>>>>>>> intel_engine_create_virtual falls back to intel_context_create
>>>>>>> (no virtual engine), but in case of parallel contexts there is
>>>>>>> special KMD flag FORCE_VIRTUAL which enforces virtual engine
>>>>>>> even for single physical engine. So it seems to be KMD concept.
>>>>>>>
>>>>>>> Anyway is it worth investigating how to make
>>>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling
>>>>>>> engine pointer? It will not help in 1st case:
>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>
>>>>>>>
>>>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>>>> holding a pointer to a reference counted and transient object 2
>>>>>> (engine) but without taking a reference count for itself. That is
>>>>>> a Bad Thing(tm).
>>>>
>>>> Engine is not ref counted (at least directly), hardware engines
>>>> seems to be even persistent across whole life of i915.
>>>> I guess before introduction of virtual engines the assumption about
>>>> validity of rq->engine was correct and developers used it to access
>>>> rq->engine->gt, rq->engine->i915, etc
>>>> So the problems described here are probably leftovers of this change.
>>>> After virtual engines were introduced
>>>> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine
>>>> is virtual.
>>>> And after adding parallel engines it does not seem to be valid
>>>> check anymore.
>>>>
>>>>>> I'm not following the description in the revert patch as to why
>>>>>> rq can't ref count the context/engine. Is there actually a
>>>>>> recursive counting problem? Or is it just a lifetime issue caused
>>>>>> by requests hanging around indefinitely because they are locked
>>>>>> by a user process?
>>>>>>
>>>>>> Either way, jumping through convoluted hoops to ensure the code
>>>>>> does not attempt to dereference a dangling pointer seems like the
>>>>>> wrong fix. Removing the engine pointer when the request is
>>>>>> completed and no longer dependent upon an engine (but before the
>>>>>> engine can possibly be destroyed) seems like a much better
>>>>>> solution. And then making the request handling code check for and
>>>>>> cope with a null engine pointer. It sounds like the only problem
>>>>>> there is the above mutex, but there is an alternate route to
>>>>>> that? Although why a completed request would need access to a GT
>>>>>> reset mutex seems confusing. If the request is done, then what
>>>>>> connection does it still have to the GT?
>>>>>
>>>>> Agreed in principle but the question is how invasive would it be
>>>>> to change the rules.
>>>>>
>>>>> With the latest info that the issue is really just the GuC
>>>>> _parallel_ engine setup, and looking at the code, I wonder if we
>>>>> couldn't just flag the rq->flags with "kernel context request".
>>>>> The code in i915_fence_release claims the rq pool is only relevant
>>>>> for those so it sounds it would be safe to skip everything else
>>>>> based on that new flag.
>>>>>
>>>>> For the mutex_release path, presumable the bad deref is only
>>>>> _after_ the wait, right? (Only once the request has been retired.)
>>>>>
>>>>> In which case caching the gt pointer at the start of
>>>>> i915_request_wait_timeout would be sufficient.
>>>>>
>>>>> That should be a few lines fixup overall and then the idea of
>>>>> allowing rq->engine to be reset to NULL can be explored more
>>>>> leisurely.
>>>>
>>>> I guess:
>>>> - setting engine to NULL in remove_from_context,
>>>> - caching gt pointer,
>>>> - checking for null pointer in i915_fence_release
>>>>
>>>> should be enough to solve current issue. However I am not sure if
>>>> there are no more dragons hidden in other execution paths. I will
>>>> try inspect the code.
>>>
>>> What you have in this patch, cheat by replacing the engine, *might*
>>> work for the short term *if* you can make sure all parallel readers
>>> will see the updated rq->engine pointer in time, before the old one
>>> gets freed.
>>>
>>> For the longer term solution - maybe making the engine reference
>>> counted?
>> That was the point of the original solution - having the request
>> reference count the context. The context is what owns the virtual
>> engine. So ensuring that the context can't be destroyed while there
>> are requests outstanding on it ensured that rq->engine would always
>> be valid. Nice simple and clean solution.So why did that get
>> reverted? What is the problem with VM_BIND and having requests ensure
>> that their resources stay alive for the lifetime of the request?
>
> Don't ask me, but it perhaps it does read a bit vague from the commit
> message on its own:
>
> commit bcb9aa45d5a0e11ef91245330c53cde214d15e8d (tag: intel/CI_DIGN_563)
> Author: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
> Date: Wed Jun 15 00:13:47 2022 +0530
>
> Revert "drm/i915: Hold reference to intel_context over life of
> i915_request"
> This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.
> The problem with this patch is that it makes i915_request to
> hold a
> reference to intel_context, which in turn holds a reference on the
> VM.
> This strong back referencing can lead to reference loops which leads
> to resource leak.
> An example is the upcoming VM_BIND work which requires VM to hold
> a reference to some shared VM specific BO. But this BO's dma-resv
> fences holds reference to the i915_request thus leading to reference
> loop.
> v2:
> Do not use reserved requests for virtual engines
>
> So I don't know what was the leak or was it permanent leak (?!) or not.
>
> Given VM_BIND has been abandoned maybe this could even be unreverted.
> I don't see a problem with holding a reference for the request
> lifetime right now but could be wrong..
unrevert or alternatively hold reference to context only in case of
virtual engines, as in this case their lifetime is the same?
Regards
Andrzej
>
> Regards,
>
> Tvrtko
>
>> John.
>>
>>
>>>
>>> Or if setting rq->engine to NULL then evaluating the paths which
>>> derefence it. AFAIR these request retirement races have been
>>> generally tricky/annoying.
>>>
>>> For instance under the i915_request_wait_timeout chain.
>>>
>>> 1)
>>> __i915_spin_request - could be racy if request gets retired between
>>> i915_request_wait_timeout/dma_fence_is_signaled check and
>>> __i915_spin_request dereferencing rq->engine.props?
>>>
>>> 2)
>>> intel_rps_boost - claims to be safe by serialising via
>>> i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents
>>> retire tearing down the engine between:
>>>
>>> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>>>
>>> ---> HERE - if whole retirement happens here <----
>>>
>>> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>>>
>>> 3)
>>> __intel_engine_flush_submission - could be racy to? What if the
>>> whole process of consuming the request by the backend and retirement
>>> happens between these two lines:
>>>
>>> if (i915_request_is_ready(rq))
>>>
>>> ---> HERE <---
>>> __intel_engine_flush_submission(rq->engine, false);
>>>
>>> Then "is ready" can be true, but by the 2nd line request retired and
>>> rq->engine freed/NULL already.
>>>
>>> Lets hope I am just making unwarranted panic by being to away from
>>> this area of the driver for a while. :) But if I am not, then it
>>> could be that rq->engine is just overall too problematic and perhaps
>>> we should have a look into making it reference counted by the request.
>>>
>>>> Btw there is rq->i915 but code only uses "rq->engine->i915" which
>>>> way shall we go? remove former or latter?
>>>
>>> Simpler/shorter option should be better.
>>>
>>> Regards,
>>>
>>> Tvrtko
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-19 10:41 ` Andrzej Hajda
@ 2023-07-19 12:43 ` Tvrtko Ursulin
2023-07-24 19:40 ` John Harrison
0 siblings, 1 reply; 30+ messages in thread
From: Tvrtko Ursulin @ 2023-07-19 12:43 UTC (permalink / raw)
To: Andrzej Hajda, John Harrison, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 19/07/2023 11:41, Andrzej Hajda wrote:
> On 18.07.2023 17:48, Tvrtko Ursulin wrote:
>>
>> On 17/07/2023 19:03, John Harrison wrote:
>>> On 7/13/2023 05:11, Tvrtko Ursulin wrote:
>>>> On 13/07/2023 12:09, Andrzej Hajda wrote:
>>>>> Hi,
>>>>>
>>>>> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>>>>> On 12/07/2023 19:54, John Harrison wrote:
>>>>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>>>>> +++++++++++
>>>>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git
>>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>> +++
>>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct
>>>>>>>>>>>>>> intel_context *ce)
>>>>>>>>>>>>>> static void remove_from_context(struct
>>>>>>>>>>>>>> i915_request *rq)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + /*
>>>>>>>>>>>>>> + * GuC virtual engine can disappear after
>>>>>>>>>>>>>> this call, so let's assign
>>>>>>>>>>>>>> + * something valid, as driver expects
>>>>>>>>>>>>>> this to be always valid pointer.
>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>> + for_each_engine_masked(engine, rq->engine->gt,
>>>>>>>>>>>>>> rq->execution_mask, tmp) {
>>>>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> yes... here the context might lose the virtual
>>>>>>>>>>>>>> engine... I wonder
>>>>>>>>>>>>>> whether this is the rigth solution, though. Maybe we
>>>>>>>>>>>>>> should set
>>>>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map,
>>>>>>>>>>>>>> _THIS_IP_)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used
>>>>>>>>>>>>>> as a set of aliases
>>>>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to
>>>>>>>>>>>>>> i915).
>>>>>>>>>>>>> without investigating further, but maybe that code is not even
>>>>>>>>>>>>> supposed to be executed, at this point, if the request's
>>>>>>>>>>>>> assigned
>>>>>>>>>>>>> virtual engine is removed.
>>>>>>>>>>>>
>>>>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>>>>> about timings - what happens earlier -
>>>>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>>>>
>>>>>>>>>>>> The other point rq->engine is accessed after context removal
>>>>>>>>>>>> is i915_fence_release -
>>>>>>>>>>>> there is long comment there regarding virtual context and
>>>>>>>>>>>> reuse retired rq.
>>>>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)"
>>>>>>>>>>>> is risky without this patch and KASAN complains clearly
>>>>>>>>>>>> about it:
>>>>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>>>>
>>>>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert
>>>>>>>>>>> "drm/i915: Hold reference to intel_context over life of
>>>>>>>>>>> i915_request""), which was a partial revert of 1e98d8c52ed5
>>>>>>>>>>> ("drm/i915: Hold reference to intel_context over life of
>>>>>>>>>>> i915_request").
>>>>>>>>>>>
>>>>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with disappearing
>>>>>>>>>>> rq->engine, then I am confused how bcb9aa45d5a0 left the
>>>>>>>>>>> rq->engine dereference in there after removing the extra
>>>>>>>>>>> reference.
>>>>>>>>>>>
>>>>>>>>>>> Could it be that the intel_engine_is_virtual check simply
>>>>>>>>>>> needs to be removed from i915_fence_release, restoring things
>>>>>>>>>>> to how they were before 1e98d8c52ed5? Could you try it out?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>>>>> disappeared, or more precisely gem_exec_balance tests passed.
>>>>>>>>>> But I have been warned by Nirmoy guc virtual engines can be
>>>>>>>>>> created for only one real engine (ie.
>>>>>>>>>> is_power_of_2(rq->execution_mask) is true but rq->engine
>>>>>>>>>> points to virtual engine).
>>>>>>>>>>
>>>>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>>>>
>>>>>>>>> Ugh.. Try involving media umd folks to see if they need a
>>>>>>>>> single engine virtual engine? Or we could always just not
>>>>>>>>> create it in the driver, I mean just use the physical one.
>>>>>>>>
>>>>>>>>
>>>>>>>> In case there is single physical engine
>>>>>>>> intel_engine_create_virtual falls back to intel_context_create
>>>>>>>> (no virtual engine), but in case of parallel contexts there is
>>>>>>>> special KMD flag FORCE_VIRTUAL which enforces virtual engine
>>>>>>>> even for single physical engine. So it seems to be KMD concept.
>>>>>>>>
>>>>>>>> Anyway is it worth investigating how to make
>>>>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling
>>>>>>>> engine pointer? It will not help in 1st case:
>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>
>>>>>>>>
>>>>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>>>>> holding a pointer to a reference counted and transient object 2
>>>>>>> (engine) but without taking a reference count for itself. That is
>>>>>>> a Bad Thing(tm).
>>>>>
>>>>> Engine is not ref counted (at least directly), hardware engines
>>>>> seems to be even persistent across whole life of i915.
>>>>> I guess before introduction of virtual engines the assumption about
>>>>> validity of rq->engine was correct and developers used it to access
>>>>> rq->engine->gt, rq->engine->i915, etc
>>>>> So the problems described here are probably leftovers of this change.
>>>>> After virtual engines were introduced
>>>>> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine
>>>>> is virtual.
>>>>> And after adding parallel engines it does not seem to be valid
>>>>> check anymore.
>>>>>
>>>>>>> I'm not following the description in the revert patch as to why
>>>>>>> rq can't ref count the context/engine. Is there actually a
>>>>>>> recursive counting problem? Or is it just a lifetime issue caused
>>>>>>> by requests hanging around indefinitely because they are locked
>>>>>>> by a user process?
>>>>>>>
>>>>>>> Either way, jumping through convoluted hoops to ensure the code
>>>>>>> does not attempt to dereference a dangling pointer seems like the
>>>>>>> wrong fix. Removing the engine pointer when the request is
>>>>>>> completed and no longer dependent upon an engine (but before the
>>>>>>> engine can possibly be destroyed) seems like a much better
>>>>>>> solution. And then making the request handling code check for and
>>>>>>> cope with a null engine pointer. It sounds like the only problem
>>>>>>> there is the above mutex, but there is an alternate route to
>>>>>>> that? Although why a completed request would need access to a GT
>>>>>>> reset mutex seems confusing. If the request is done, then what
>>>>>>> connection does it still have to the GT?
>>>>>>
>>>>>> Agreed in principle but the question is how invasive would it be
>>>>>> to change the rules.
>>>>>>
>>>>>> With the latest info that the issue is really just the GuC
>>>>>> _parallel_ engine setup, and looking at the code, I wonder if we
>>>>>> couldn't just flag the rq->flags with "kernel context request".
>>>>>> The code in i915_fence_release claims the rq pool is only relevant
>>>>>> for those so it sounds it would be safe to skip everything else
>>>>>> based on that new flag.
>>>>>>
>>>>>> For the mutex_release path, presumable the bad deref is only
>>>>>> _after_ the wait, right? (Only once the request has been retired.)
>>>>>>
>>>>>> In which case caching the gt pointer at the start of
>>>>>> i915_request_wait_timeout would be sufficient.
>>>>>>
>>>>>> That should be a few lines fixup overall and then the idea of
>>>>>> allowing rq->engine to be reset to NULL can be explored more
>>>>>> leisurely.
>>>>>
>>>>> I guess:
>>>>> - setting engine to NULL in remove_from_context,
>>>>> - caching gt pointer,
>>>>> - checking for null pointer in i915_fence_release
>>>>>
>>>>> should be enough to solve current issue. However I am not sure if
>>>>> there are no more dragons hidden in other execution paths. I will
>>>>> try inspect the code.
>>>>
>>>> What you have in this patch, cheat by replacing the engine, *might*
>>>> work for the short term *if* you can make sure all parallel readers
>>>> will see the updated rq->engine pointer in time, before the old one
>>>> gets freed.
>>>>
>>>> For the longer term solution - maybe making the engine reference
>>>> counted?
>>> That was the point of the original solution - having the request
>>> reference count the context. The context is what owns the virtual
>>> engine. So ensuring that the context can't be destroyed while there
>>> are requests outstanding on it ensured that rq->engine would always
>>> be valid. Nice simple and clean solution.So why did that get
>>> reverted? What is the problem with VM_BIND and having requests ensure
>>> that their resources stay alive for the lifetime of the request?
>>
>> Don't ask me, but it perhaps it does read a bit vague from the commit
>> message on its own:
>>
>> commit bcb9aa45d5a0e11ef91245330c53cde214d15e8d (tag: intel/CI_DIGN_563)
>> Author: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
>> Date: Wed Jun 15 00:13:47 2022 +0530
>>
>> Revert "drm/i915: Hold reference to intel_context over life of
>> i915_request"
>> This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.
>> The problem with this patch is that it makes i915_request to
>> hold a
>> reference to intel_context, which in turn holds a reference on the
>> VM.
>> This strong back referencing can lead to reference loops which leads
>> to resource leak.
>> An example is the upcoming VM_BIND work which requires VM to hold
>> a reference to some shared VM specific BO. But this BO's dma-resv
>> fences holds reference to the i915_request thus leading to reference
>> loop.
>> v2:
>> Do not use reserved requests for virtual engines
>>
>> So I don't know what was the leak or was it permanent leak (?!) or not.
>>
>> Given VM_BIND has been abandoned maybe this could even be unreverted.
>> I don't see a problem with holding a reference for the request
>> lifetime right now but could be wrong..
>
> unrevert or alternatively hold reference to context only in case of
> virtual engines, as in this case their lifetime is the same?
IMO it is simpler to go for always, especially if we have doubts
execlists virtual engines might have the same issue just harder to hit
due the RCU free path. (I have doubts at least.)
It also probably does not make sense to have both
intel_engine_is_virtual and is_power_of_2 checks in i915_fence_release.
Since intel_engine_is_virtual will be safe with a reference, then
is_power_of_2 hack can go. So not a direct un-revert, but un-revert with
edits/improvements.
First thing though would be to get hold of Niranjana and John to bless
the whole plan, given they were involved in the original reference
counting and the revert.
Regards,
Tvrtko
>
> Regards
> Andrzej
>
>>
>> Regards,
>>
>> Tvrtko
>>
>>> John.
>>>
>>>
>>>>
>>>> Or if setting rq->engine to NULL then evaluating the paths which
>>>> derefence it. AFAIR these request retirement races have been
>>>> generally tricky/annoying.
>>>>
>>>> For instance under the i915_request_wait_timeout chain.
>>>>
>>>> 1)
>>>> __i915_spin_request - could be racy if request gets retired between
>>>> i915_request_wait_timeout/dma_fence_is_signaled check and
>>>> __i915_spin_request dereferencing rq->engine.props?
>>>>
>>>> 2)
>>>> intel_rps_boost - claims to be safe by serialising via
>>>> i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents
>>>> retire tearing down the engine between:
>>>>
>>>> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>>>>
>>>> ---> HERE - if whole retirement happens here <----
>>>>
>>>> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>>>>
>>>> 3)
>>>> __intel_engine_flush_submission - could be racy to? What if the
>>>> whole process of consuming the request by the backend and retirement
>>>> happens between these two lines:
>>>>
>>>> if (i915_request_is_ready(rq))
>>>>
>>>> ---> HERE <---
>>>> __intel_engine_flush_submission(rq->engine, false);
>>>>
>>>> Then "is ready" can be true, but by the 2nd line request retired and
>>>> rq->engine freed/NULL already.
>>>>
>>>> Lets hope I am just making unwarranted panic by being to away from
>>>> this area of the driver for a while. :) But if I am not, then it
>>>> could be that rq->engine is just overall too problematic and perhaps
>>>> we should have a look into making it reference counted by the request.
>>>>
>>>>> Btw there is rq->i915 but code only uses "rq->engine->i915" which
>>>>> way shall we go? remove former or latter?
>>>>
>>>> Simpler/shorter option should be better.
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>>>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine
2023-07-19 12:43 ` Tvrtko Ursulin
@ 2023-07-24 19:40 ` John Harrison
0 siblings, 0 replies; 30+ messages in thread
From: John Harrison @ 2023-07-24 19:40 UTC (permalink / raw)
To: Tvrtko Ursulin, Andrzej Hajda, Andi Shyti
Cc: intel-gfx, Chris Wilson, Nirmoy Das
On 7/19/2023 05:43, Tvrtko Ursulin wrote:
> On 19/07/2023 11:41, Andrzej Hajda wrote:
>> On 18.07.2023 17:48, Tvrtko Ursulin wrote:
>>> On 17/07/2023 19:03, John Harrison wrote:
>>>> On 7/13/2023 05:11, Tvrtko Ursulin wrote:
>>>>> On 13/07/2023 12:09, Andrzej Hajda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 13.07.2023 09:39, Tvrtko Ursulin wrote:
>>>>>>> On 12/07/2023 19:54, John Harrison wrote:
>>>>>>>> On 7/12/2023 09:27, Andrzej Hajda wrote:
>>>>>>>>> On 12.07.2023 14:35, Tvrtko Ursulin wrote:
>>>>>>>>>> On 12/07/2023 13:18, Andrzej Hajda wrote:
>>>>>>>>>>> On 11.07.2023 17:27, Tvrtko Ursulin wrote:
>>>>>>>>>>>> On 11/07/2023 14:58, Andrzej Hajda wrote:
>>>>>>>>>>>>> On 11.07.2023 13:34, Andi Shyti wrote:
>>>>>>>>>>>>>> Hi Andrzej,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
>>>>>>>>>>>>>>> +++++++++++
>>>>>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git
>>>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>>> index a0e3ef1c65d246..2c877ea5eda6f0 100644
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>>> +++
>>>>>>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>>>>>>>>>> @@ -3461,6 +3461,8 @@ static void
>>>>>>>>>>>>>>> guc_prio_fini(struct i915_request *rq, struct
>>>>>>>>>>>>>>> intel_context *ce)
>>>>>>>>>>>>>>> static void remove_from_context(struct
>>>>>>>>>>>>>>> i915_request *rq)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> struct intel_context *ce =
>>>>>>>>>>>>>>> request_to_scheduling_context(rq);
>>>>>>>>>>>>>>> + struct intel_engine_cs *engine;
>>>>>>>>>>>>>>> + intel_engine_mask_t tmp;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> GEM_BUG_ON(intel_context_is_child(ce));
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @@ -3478,6 +3480,15 @@ static void
>>>>>>>>>>>>>>> remove_from_context(struct i915_request *rq)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> atomic_dec(&ce->guc_id.ref);
>>>>>>>>>>>>>>> i915_request_notify_execute_cb_imm(rq);
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + /*
>>>>>>>>>>>>>>> + * GuC virtual engine can disappear
>>>>>>>>>>>>>>> after this call, so let's assign
>>>>>>>>>>>>>>> + * something valid, as driver expects
>>>>>>>>>>>>>>> this to be always valid pointer.
>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>> + for_each_engine_masked(engine,
>>>>>>>>>>>>>>> rq->engine->gt, rq->execution_mask, tmp) {
>>>>>>>>>>>>>>> + rq->engine = engine;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> yes... here the context might lose the virtual
>>>>>>>>>>>>>>> engine... I wonder
>>>>>>>>>>>>>>> whether this is the rigth solution, though. Maybe
>>>>>>>>>>>>>>> we should set
>>>>>>>>>>>>>>> rq->engine = NULL; and check for NULL? Don't know.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Setting NULL causes occasional null page de-reference in
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> i915_request_wait_timeout:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map,
>>>>>>>>>>>>>>> _THIS_IP_)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> rq->engine after removing rq from context is (IMHO) used
>>>>>>>>>>>>>>> as a set of aliases
>>>>>>>>>>>>>>> for gt and i915 (despite rq itself contains the alias to
>>>>>>>>>>>>>>> i915).
>>>>>>>>>>>>>> without investigating further, but maybe that code is not
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> supposed to be executed, at this point, if the request's
>>>>>>>>>>>>>> assigned
>>>>>>>>>>>>>> virtual engine is removed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Real tests show it is executed and the function
>>>>>>>>>>>>> i915_request_wait_timeout is quite generic
>>>>>>>>>>>>> I guess it is quite typical use-case, the only question is
>>>>>>>>>>>>> about timings - what happens earlier -
>>>>>>>>>>>>> finalization of i915_request_wait_timeout or context removal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The other point rq->engine is accessed after context
>>>>>>>>>>>>> removal is i915_fence_release -
>>>>>>>>>>>>> there is long comment there regarding virtual context and
>>>>>>>>>>>>> reuse retired rq.
>>>>>>>>>>>>> Anyway calling there "intel_engine_is_virtual(rq->engine)"
>>>>>>>>>>>>> is risky without this patch and KASAN complains clearly
>>>>>>>>>>>>> about it:
>>>>>>>>>>>>> http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like a bug introduced in bcb9aa45d5a0 ("Revert
>>>>>>>>>>>> "drm/i915: Hold reference to intel_context over life of
>>>>>>>>>>>> i915_request""), which was a partial revert of 1e98d8c52ed5
>>>>>>>>>>>> ("drm/i915: Hold reference to intel_context over life of
>>>>>>>>>>>> i915_request").
>>>>>>>>>>>>
>>>>>>>>>>>> Ie. if 1e98d8c52ed5 recognised the problem with
>>>>>>>>>>>> disappearing rq->engine, then I am confused how
>>>>>>>>>>>> bcb9aa45d5a0 left the rq->engine dereference in there after
>>>>>>>>>>>> removing the extra reference.
>>>>>>>>>>>>
>>>>>>>>>>>> Could it be that the intel_engine_is_virtual check simply
>>>>>>>>>>>> needs to be removed from i915_fence_release, restoring
>>>>>>>>>>>> things to how they were before 1e98d8c52ed5? Could you try
>>>>>>>>>>>> it out?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have already tried something similar [1] and KASAN bugs
>>>>>>>>>>> disappeared, or more precisely gem_exec_balance tests
>>>>>>>>>>> passed. But I have been warned by Nirmoy guc virtual engines
>>>>>>>>>>> can be created for only one real engine (ie.
>>>>>>>>>>> is_power_of_2(rq->execution_mask) is true but rq->engine
>>>>>>>>>>> points to virtual engine).
>>>>>>>>>>>
>>>>>>>>>>> [1]: https://patchwork.freedesktop.org/series/118879/
>>>>>>>>>>
>>>>>>>>>> Ugh.. Try involving media umd folks to see if they need a
>>>>>>>>>> single engine virtual engine? Or we could always just not
>>>>>>>>>> create it in the driver, I mean just use the physical one.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In case there is single physical engine
>>>>>>>>> intel_engine_create_virtual falls back to intel_context_create
>>>>>>>>> (no virtual engine), but in case of parallel contexts there is
>>>>>>>>> special KMD flag FORCE_VIRTUAL which enforces virtual engine
>>>>>>>>> even for single physical engine. So it seems to be KMD concept.
>>>>>>>>>
>>>>>>>>> Anyway is it worth investigating how to make
>>>>>>>>> "is_power_of_2(rq->execution_mask)" indication of dangling
>>>>>>>>> engine pointer? It will not help in 1st case:
>>>>>>>>> mutex_release(&rq->engine->gt->reset.mutex.dep_map, _THIS_IP_)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> There seems to be a fundamental problem here. Object 1 (rq) is
>>>>>>>> holding a pointer to a reference counted and transient object 2
>>>>>>>> (engine) but without taking a reference count for itself. That
>>>>>>>> is a Bad Thing(tm).
>>>>>>
>>>>>> Engine is not ref counted (at least directly), hardware engines
>>>>>> seems to be even persistent across whole life of i915.
>>>>>> I guess before introduction of virtual engines the assumption
>>>>>> about validity of rq->engine was correct and developers used it
>>>>>> to access rq->engine->gt, rq->engine->i915, etc
>>>>>> So the problems described here are probably leftovers of this
>>>>>> change.
>>>>>> After virtual engines were introduced
>>>>>> "is_power_of_2(rq->execution_mask)" was used to detect rq->engine
>>>>>> is virtual.
>>>>>> And after adding parallel engines it does not seem to be valid
>>>>>> check anymore.
>>>>>>
>>>>>>>> I'm not following the description in the revert patch as to why
>>>>>>>> rq can't ref count the context/engine. Is there actually a
>>>>>>>> recursive counting problem? Or is it just a lifetime issue
>>>>>>>> caused by requests hanging around indefinitely because they are
>>>>>>>> locked by a user process?
>>>>>>>>
>>>>>>>> Either way, jumping through convoluted hoops to ensure the code
>>>>>>>> does not attempt to dereference a dangling pointer seems like
>>>>>>>> the wrong fix. Removing the engine pointer when the request is
>>>>>>>> completed and no longer dependent upon an engine (but before
>>>>>>>> the engine can possibly be destroyed) seems like a much better
>>>>>>>> solution. And then making the request handling code check for
>>>>>>>> and cope with a null engine pointer. It sounds like the only
>>>>>>>> problem there is the above mutex, but there is an alternate
>>>>>>>> route to that? Although why a completed request would need
>>>>>>>> access to a GT reset mutex seems confusing. If the request is
>>>>>>>> done, then what connection does it still have to the GT?
>>>>>>>
>>>>>>> Agreed in principle but the question is how invasive would it be
>>>>>>> to change the rules.
>>>>>>>
>>>>>>> With the latest info that the issue is really just the GuC
>>>>>>> _parallel_ engine setup, and looking at the code, I wonder if we
>>>>>>> couldn't just flag the rq->flags with "kernel context request".
>>>>>>> The code in i915_fence_release claims the rq pool is only
>>>>>>> relevant for those so it sounds it would be safe to skip
>>>>>>> everything else based on that new flag.
>>>>>>>
>>>>>>> For the mutex_release path, presumable the bad deref is only
>>>>>>> _after_ the wait, right? (Only once the request has been retired.)
>>>>>>>
>>>>>>> In which case caching the gt pointer at the start of
>>>>>>> i915_request_wait_timeout would be sufficient.
>>>>>>>
>>>>>>> That should be a few lines fixup overall and then the idea of
>>>>>>> allowing rq->engine to be reset to NULL can be explored more
>>>>>>> leisurely.
>>>>>>
>>>>>> I guess:
>>>>>> - setting engine to NULL in remove_from_context,
>>>>>> - caching gt pointer,
>>>>>> - checking for null pointer in i915_fence_release
>>>>>>
>>>>>> should be enough to solve current issue. However I am not sure if
>>>>>> there are no more dragons hidden in other execution paths. I will
>>>>>> try inspect the code.
>>>>>
>>>>> What you have in this patch, cheat by replacing the engine,
>>>>> *might* work for the short term *if* you can make sure all
>>>>> parallel readers will see the updated rq->engine pointer in time,
>>>>> before the old one gets freed.
>>>>>
>>>>> For the longer term solution - maybe making the engine reference
>>>>> counted?
>>>> That was the point of the original solution - having the request
>>>> reference count the context. The context is what owns the virtual
>>>> engine. So ensuring that the context can't be destroyed while there
>>>> are requests outstanding on it ensured that rq->engine would always
>>>> be valid. Nice simple and clean solution.So why did that get
>>>> reverted? What is the problem with VM_BIND and having requests
>>>> ensure that their resources stay alive for the lifetime of the
>>>> request?
>>>
>>> Don't ask me, but it perhaps it does read a bit vague from the
>>> commit message on its own:
>>>
>>> commit bcb9aa45d5a0e11ef91245330c53cde214d15e8d (tag:
>>> intel/CI_DIGN_563)
>>> Author: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
>>> Date: Wed Jun 15 00:13:47 2022 +0530
>>>
>>> Revert "drm/i915: Hold reference to intel_context over life of
>>> i915_request"
>>> This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.
>>> The problem with this patch is that it makes i915_request to
>>> hold a
>>> reference to intel_context, which in turn holds a reference on
>>> the VM.
>>> This strong back referencing can lead to reference loops which
>>> leads
>>> to resource leak.
>>> An example is the upcoming VM_BIND work which requires VM to
>>> hold
>>> a reference to some shared VM specific BO. But this BO's dma-resv
>>> fences holds reference to the i915_request thus leading to
>>> reference
>>> loop.
>>> v2:
>>> Do not use reserved requests for virtual engines
>>>
>>> So I don't know what was the leak or was it permanent leak (?!) or not.
>>>
>>> Given VM_BIND has been abandoned maybe this could even be
>>> unreverted. I don't see a problem with holding a reference for the
>>> request lifetime right now but could be wrong..
>>
>> unrevert or alternatively hold reference to context only in case of
>> virtual engines, as in this case their lifetime is the same?
>
> IMO it is simpler to go for always, especially if we have doubts
> execlists virtual engines might have the same issue just harder to hit
> due the RCU free path. (I have doubts at least.)
>
> It also probably does not make sense to have both
> intel_engine_is_virtual and is_power_of_2 checks in
> i915_fence_release. Since intel_engine_is_virtual will be safe with a
> reference, then is_power_of_2 hack can go. So not a direct un-revert,
> but un-revert with edits/improvements.
Sounds good to me. The 'power of 2 means virtual' thing does sounds
quite hacky.
>
> First thing though would be to get hold of Niranjana and John to bless
> the whole plan, given they were involved in the original reference
> counting and the revert.
I believe it was actually Matthew Brost that wrote the original
reference counting patch. I recall that I reviewed it and it looked good
to me at the time. I was not involved in the revert. I only realised the
revert had happened because I saw this thread and got confused as to why
there was a problem at all!
John.
>
> Regards,
>
> Tvrtko
>
>>
>> Regards
>> Andrzej
>>
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>>> John.
>>>>
>>>>
>>>>>
>>>>> Or if setting rq->engine to NULL then evaluating the paths which
>>>>> derefence it. AFAIR these request retirement races have been
>>>>> generally tricky/annoying.
>>>>>
>>>>> For instance under the i915_request_wait_timeout chain.
>>>>>
>>>>> 1)
>>>>> __i915_spin_request - could be racy if request gets retired
>>>>> between i915_request_wait_timeout/dma_fence_is_signaled check and
>>>>> __i915_spin_request dereferencing rq->engine.props?
>>>>>
>>>>> 2)
>>>>> intel_rps_boost - claims to be safe by serialising via
>>>>> i915_request_retire/I915_FENCE_FLAG_BOOST but is it? What prevents
>>>>> retire tearing down the engine between:
>>>>>
>>>>> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>>>>>
>>>>> ---> HERE - if whole retirement happens here <----
>>>>>
>>>>> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>>>>>
>>>>> 3)
>>>>> __intel_engine_flush_submission - could be racy to? What if the
>>>>> whole process of consuming the request by the backend and
>>>>> retirement happens between these two lines:
>>>>>
>>>>> if (i915_request_is_ready(rq))
>>>>>
>>>>> ---> HERE <---
>>>>> __intel_engine_flush_submission(rq->engine, false);
>>>>>
>>>>> Then "is ready" can be true, but by the 2nd line request retired
>>>>> and rq->engine freed/NULL already.
>>>>>
>>>>> Lets hope I am just making unwarranted panic by being to away from
>>>>> this area of the driver for a while. :) But if I am not, then it
>>>>> could be that rq->engine is just overall too problematic and
>>>>> perhaps we should have a look into making it reference counted by
>>>>> the request.
>>>>>
>>>>>> Btw there is rq->i915 but code only uses "rq->engine->i915" which
>>>>>> way shall we go? remove former or latter?
>>>>>
>>>>> Simpler/shorter option should be better.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tvrtko
>>>>
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2023-07-24 19:40 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-05 16:08 [Intel-gfx] [PATCH] drm/i915/gt: update request engine before removing virtual GuC engine Andrzej Hajda
2023-07-05 17:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2023-07-05 17:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-05 19:11 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-07-06 15:16 ` [Intel-gfx] [PATCH v2] " Andrzej Hajda
2023-07-07 8:05 ` Nirmoy Das
2023-07-11 10:18 ` Andi Shyti
2023-07-11 11:12 ` Andrzej Hajda
2023-07-11 11:34 ` Andi Shyti
2023-07-11 13:58 ` Andrzej Hajda
2023-07-11 15:27 ` Tvrtko Ursulin
2023-07-12 12:18 ` Andrzej Hajda
2023-07-12 12:35 ` Tvrtko Ursulin
2023-07-12 16:27 ` Andrzej Hajda
2023-07-12 18:54 ` John Harrison
2023-07-13 7:39 ` Tvrtko Ursulin
2023-07-13 8:56 ` Tvrtko Ursulin
2023-07-13 11:59 ` Andrzej Hajda
2023-07-13 12:22 ` Tvrtko Ursulin
2023-07-13 11:09 ` Andrzej Hajda
2023-07-13 12:11 ` Tvrtko Ursulin
2023-07-17 18:03 ` John Harrison
2023-07-18 15:48 ` Tvrtko Ursulin
2023-07-19 10:41 ` Andrzej Hajda
2023-07-19 12:43 ` Tvrtko Ursulin
2023-07-24 19:40 ` John Harrison
2023-07-06 20:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: update request engine before removing virtual GuC engine (rev2) Patchwork
2023-07-06 20:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-07 2:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-07-10 12:51 ` Andrzej Hajda
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.