* [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest
@ 2021-10-11 23:47 Matthew Brost
2021-10-12 0:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Matthew Brost @ 2021-10-11 23:47 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: john.c.harrison, thomas.hellstrom
The hangcheck selftest blocks per engine resets by setting magic bits in
the reset flags. This is incorrect for GuC submission because if the GuC
fails to reset an engine we would like to do a full GT reset. Do no set
these magic bits when using GuC submission.
Side note this lockless algorithm with magic bits to block resets really
should be ripped out.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 7e2d99dd012d..90a03c60c80c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active)
reset_engine_count = i915_reset_engine_count(global, engine);
st_engine_heartbeat_disable(engine);
- set_bit(I915_RESET_ENGINE + id, >->reset.flags);
+ if (!using_guc)
+ set_bit(I915_RESET_ENGINE + id, >->reset.flags);
count = 0;
do {
struct i915_request *rq = NULL;
@@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active)
if (err)
break;
} while (time_before(jiffies, end_time));
- clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
+ if (!using_guc)
+ clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
st_engine_heartbeat_enable(engine);
pr_info("%s: Completed %lu %s resets\n",
engine->name, count, active ? "active" : "idle");
@@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt *gt,
yield(); /* start all threads before we begin */
st_engine_heartbeat_disable_no_pm(engine);
- set_bit(I915_RESET_ENGINE + id, >->reset.flags);
+ if (!using_guc)
+ set_bit(I915_RESET_ENGINE + id, >->reset.flags);
do {
struct i915_request *rq = NULL;
struct intel_selftest_saved_policy saved;
@@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt *gt,
if (err)
break;
} while (time_before(jiffies, end_time));
- clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
+ if (!using_guc)
+ clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
st_engine_heartbeat_enable_no_pm(engine);
pr_info("i915_reset_engine(%s:%s): %lu resets\n",
--
2.32.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-11 23:47 [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest Matthew Brost @ 2021-10-12 0:52 ` Patchwork 2021-10-12 4:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Patchwork @ 2021-10-12 0:52 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 2775 bytes --] == Series Details == Series: drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest URL : https://patchwork.freedesktop.org/series/95702/ State : success == Summary == CI Bug Log - changes from CI_DRM_10719 -> Patchwork_21313 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/index.html Known issues ------------ Here are the changes found in Patchwork_21313 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_selftest@live@hangcheck: - fi-snb-2600: [PASS][1] -> [INCOMPLETE][2] ([i915#3921]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/fi-snb-2600/igt@i915_selftest@live@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/fi-snb-2600/igt@i915_selftest@live@hangcheck.html #### Possible fixes #### * igt@i915_selftest@live@gt_heartbeat: - fi-bdw-5557u: [DMESG-FAIL][3] ([i915#541]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - {fi-hsw-gt1}: [DMESG-WARN][5] ([i915#3303]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/fi-hsw-gt1/igt@i915_selftest@live@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/fi-hsw-gt1/igt@i915_selftest@live@hangcheck.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (38 -> 34) ------------------------------ Missing (4): fi-bsw-cyan fi-elk-e7500 fi-kbl-guc fi-bsw-n3050 Build changes ------------- * Linux: CI_DRM_10719 -> Patchwork_21313 CI-20190529: 20190529 CI_DRM_10719: b138938ad4071c045a865977718019951186e322 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6242: 721fd85ee95225ed5df322f7182bdfa9b86a3e68 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21313: bad5ebd3f38295f5c7848973d023033c59390e4c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bad5ebd3f382 drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/index.html [-- Attachment #2: Type: text/html, Size: 3442 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-11 23:47 [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest Matthew Brost 2021-10-12 0:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork @ 2021-10-12 4:46 ` Patchwork 2021-10-21 6:15 ` [Intel-gfx] [PATCH] " Thomas Hellström 2021-10-26 19:48 ` John Harrison 3 siblings, 0 replies; 18+ messages in thread From: Patchwork @ 2021-10-12 4:46 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 30308 bytes --] == Series Details == Series: drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest URL : https://patchwork.freedesktop.org/series/95702/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10719_full -> Patchwork_21313_full ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_21313_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21313_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_21313_full: ### IGT changes ### #### Possible regressions #### * igt@gem_fenced_exec_thrash@no-spare-fences-interruptible: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-snb2/igt@gem_fenced_exec_thrash@no-spare-fences-interruptible.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-snb2/igt@gem_fenced_exec_thrash@no-spare-fences-interruptible.html * igt@kms_flip_tiling@flip-changes-tiling-yf: - shard-tglb: NOTRUN -> [SKIP][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_flip_tiling@flip-changes-tiling-yf.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][4] -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl3/igt@kms_frontbuffer_tracking@fbc-suspend.html Known issues ------------ Here are the changes found in Patchwork_21313_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][6] ([i915#3002]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@gem_create@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-snb7/igt@gem_ctx_persistence@legacy-engines-queued.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb6/igt@gem_exec_fair@basic-flow@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-glk7/igt@gem_exec_fair@basic-none-rrul@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-glk3/igt@gem_exec_fair@basic-none-rrul@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-iclb5/igt@gem_exec_fair@basic-none-share@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-iclb3/igt@gem_exec_fair@basic-none-share@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][14] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@gem_exec_fair@basic-pace-share@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-iclb4/igt@gem_exec_fair@basic-pace@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@gem_exec_fair@basic-pace@vecs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@gem_exec_fair@basic-pace@vecs0.html * igt@gem_pxp@reject-modify-context-protection-off-2: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#4270]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@gem_pxp@reject-modify-context-protection-off-2.html * igt@gem_userptr_blits@coherency-sync: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#110542]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@gem_userptr_blits@coherency-sync.html * igt@gem_workarounds@suspend-resume-context: - shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([i915#456]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-tglb3/igt@gem_workarounds@suspend-resume-context.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb7/igt@gem_workarounds@suspend-resume-context.html * igt@gen7_exec_parse@oacontrol-tracking: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109289]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@gen7_exec_parse@oacontrol-tracking.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1436] / [i915#716]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl2/igt@gen9_exec_parse@allowed-single.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl7/igt@gen9_exec_parse@allowed-single.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-tglb: NOTRUN -> [WARN][25] ([i915#2681]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@i915_pm_rc6_residency@rc6-fence.html * igt@i915_suspend@forcewake: - shard-kbl: NOTRUN -> [DMESG-WARN][26] ([i915#180]) [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@i915_suspend@forcewake.html * igt@kms_big_fb@linear-16bpp-rotate-90: - shard-apl: NOTRUN -> [SKIP][27] ([fdo#109271]) +177 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_big_fb@linear-16bpp-rotate-90.html * igt@kms_big_fb@linear-8bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][28] ([fdo#111614]) [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_big_fb@linear-8bpp-rotate-90.html * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip: - shard-kbl: NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#3777]) +1 similar issue [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111615]) [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0.html * igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-tglb: NOTRUN -> [SKIP][31] ([i915#3689] / [i915#3886]) [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3886]) +2 similar issues [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl9/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#3886]) +7 similar issues [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-kbl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#3886]) +1 similar issue [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-d-missing-ccs-buffer-yf_tiled_ccs: - shard-tglb: NOTRUN -> [SKIP][35] ([i915#3689]) +1 similar issue [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_ccs@pipe-d-missing-ccs-buffer-yf_tiled_ccs.html * igt@kms_chamelium@dp-hpd-fast: - shard-snb: NOTRUN -> [SKIP][36] ([fdo#109271] / [fdo#111827]) +6 similar issues [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-snb2/igt@kms_chamelium@dp-hpd-fast.html * igt@kms_chamelium@hdmi-crc-fast: - shard-skl: NOTRUN -> [SKIP][37] ([fdo#109271] / [fdo#111827]) +3 similar issues [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl9/igt@kms_chamelium@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][38] ([fdo#109271] / [fdo#111827]) +12 similar issues [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_chamelium@hdmi-edid-change-during-suspend.html * igt@kms_color_chamelium@pipe-b-ctm-limited-range: - shard-tglb: NOTRUN -> [SKIP][39] ([fdo#109284] / [fdo#111827]) +3 similar issues [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_color_chamelium@pipe-b-ctm-limited-range.html * igt@kms_color_chamelium@pipe-b-degamma: - shard-kbl: NOTRUN -> [SKIP][40] ([fdo#109271] / [fdo#111827]) +5 similar issues [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl1/igt@kms_color_chamelium@pipe-b-degamma.html * igt@kms_content_protection@atomic: - shard-apl: NOTRUN -> [TIMEOUT][41] ([i915#1319]) [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_content_protection@atomic.html * igt@kms_content_protection@srm: - shard-kbl: NOTRUN -> [TIMEOUT][42] ([i915#1319]) [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl3/igt@kms_content_protection@srm.html * igt@kms_cursor_crc@pipe-a-cursor-max-size-offscreen: - shard-tglb: NOTRUN -> [SKIP][43] ([i915#3359]) [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_cursor_crc@pipe-a-cursor-max-size-offscreen.html * igt@kms_cursor_crc@pipe-b-cursor-32x32-rapid-movement: - shard-tglb: NOTRUN -> [SKIP][44] ([i915#3319]) [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_cursor_crc@pipe-b-cursor-32x32-rapid-movement.html * igt@kms_cursor_crc@pipe-c-cursor-512x512-onscreen: - shard-tglb: NOTRUN -> [SKIP][45] ([fdo#109279] / [i915#3359]) [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_cursor_crc@pipe-c-cursor-512x512-onscreen.html * igt@kms_cursor_edge_walk@pipe-d-128x128-right-edge: - shard-snb: NOTRUN -> [SKIP][46] ([fdo#109271]) +147 similar issues [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-snb2/igt@kms_cursor_edge_walk@pipe-d-128x128-right-edge.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][47] -> [DMESG-WARN][48] ([i915#118]) +1 similar issue [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-glk7/igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-glk7/igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_cursor_legacy@pipe-d-single-bo: - shard-kbl: NOTRUN -> [SKIP][49] ([fdo#109271] / [i915#533]) [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@kms_cursor_legacy@pipe-d-single-bo.html * igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions-varying-size: - shard-tglb: NOTRUN -> [SKIP][50] ([i915#4103]) [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions-varying-size.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-kbl: [PASS][51] -> [INCOMPLETE][52] ([i915#180] / [i915#636]) [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html * igt@kms_flip@2x-nonexisting-fb-interruptible: - shard-tglb: NOTRUN -> [SKIP][53] ([fdo#111825]) +8 similar issues [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_flip@2x-nonexisting-fb-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1: - shard-tglb: [PASS][54] -> [INCOMPLETE][55] ([i915#2411] / [i915#456]) [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-tglb3/igt@kms_flip@flip-vs-suspend-interruptible@a-edp1.html [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb7/igt@kms_flip@flip-vs-suspend-interruptible@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][56] -> [DMESG-WARN][57] ([i915#180]) +3 similar issues [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl6/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html * igt@kms_flip@plain-flip-ts-check@b-edp1: - shard-skl: [PASS][58] -> [FAIL][59] ([i915#2122]) +2 similar issues [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl8/igt@kms_flip@plain-flip-ts-check@b-edp1.html [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl3/igt@kms_flip@plain-flip-ts-check@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack-mmap-gtt: - shard-skl: NOTRUN -> [SKIP][60] ([fdo#109271]) +41 similar issues [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl9/igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack-mmap-gtt.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc: - shard-kbl: NOTRUN -> [SKIP][61] ([fdo#109271]) +56 similar issues [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][62] -> [FAIL][63] ([i915#1188]) [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl1/igt@kms_hdr@bpc-switch-suspend.html [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl8/igt@kms_hdr@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes: - shard-apl: [PASS][64] -> [DMESG-WARN][65] ([i915#180]) +2 similar issues [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes.html [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-apl: NOTRUN -> [FAIL][66] ([fdo#108145] / [i915#265]) +2 similar issues [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][67] -> [FAIL][68] ([fdo#108145] / [i915#265]) [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb: - shard-kbl: NOTRUN -> [FAIL][69] ([i915#265]) +1 similar issue [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl1/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-skl: NOTRUN -> [FAIL][70] ([fdo#108145] / [i915#265]) [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max.html * igt@kms_plane_lowres@pipe-c-tiling-none: - shard-tglb: NOTRUN -> [SKIP][71] ([i915#3536]) [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_plane_lowres@pipe-c-tiling-none.html * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2: - shard-kbl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#658]) +1 similar issue [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4: - shard-apl: NOTRUN -> [SKIP][73] ([fdo#109271] / [i915#658]) +2 similar issues [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl7/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4.html * igt@kms_sysfs_edid_timing: - shard-apl: NOTRUN -> [FAIL][74] ([IGT#2]) [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@kms_sysfs_edid_timing.html * igt@kms_writeback@writeback-invalid-parameters: - shard-tglb: NOTRUN -> [SKIP][75] ([i915#2437]) [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_writeback@writeback-invalid-parameters.html * igt@perf@polling-parameterized: - shard-glk: [PASS][76] -> [FAIL][77] ([i915#1542]) [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-glk2/igt@perf@polling-parameterized.html [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-glk7/igt@perf@polling-parameterized.html - shard-skl: [PASS][78] -> [FAIL][79] ([i915#1542]) [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl9/igt@perf@polling-parameterized.html [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl7/igt@perf@polling-parameterized.html * igt@perf@short-reads: - shard-skl: [PASS][80] -> [FAIL][81] ([i915#51]) [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl2/igt@perf@short-reads.html [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl3/igt@perf@short-reads.html * igt@prime_nv_pcopy@test3_3: - shard-tglb: NOTRUN -> [SKIP][82] ([fdo#109291]) [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@prime_nv_pcopy@test3_3.html * igt@sysfs_clients@fair-1: - shard-kbl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#2994]) [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@sysfs_clients@fair-1.html * igt@sysfs_clients@sema-50: - shard-apl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#2994]) +2 similar issues [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@sysfs_clients@sema-50.html #### Possible fixes #### * igt@gem_eio@in-flight-suspend: - shard-apl: [DMESG-WARN][85] ([i915#180]) -> [PASS][86] [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-apl6/igt@gem_eio@in-flight-suspend.html [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl7/igt@gem_eio@in-flight-suspend.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [FAIL][87] ([i915#2842]) -> [PASS][88] [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-iclb5/igt@gem_exec_fair@basic-pace@bcs0.html [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-iclb4/igt@gem_exec_fair@basic-pace@bcs0.html * igt@gem_exec_gttfill@engines@rcs0: - shard-glk: [DMESG-WARN][89] ([i915#118]) -> [PASS][90] [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-glk2/igt@gem_exec_gttfill@engines@rcs0.html [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-glk9/igt@gem_exec_gttfill@engines@rcs0.html * igt@gem_exec_params@rel-constants-invalid-rel-gen5: - shard-skl: [DMESG-WARN][91] ([i915#1982]) -> [PASS][92] [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl7/igt@gem_exec_params@rel-constants-invalid-rel-gen5.html [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl4/igt@gem_exec_params@rel-constants-invalid-rel-gen5.html * igt@gem_exec_schedule@u-submit-golden-slice@vecs0: - shard-skl: [INCOMPLETE][93] ([i915#3797]) -> [PASS][94] [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl9/igt@gem_exec_schedule@u-submit-golden-slice@vecs0.html [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl7/igt@gem_exec_schedule@u-submit-golden-slice@vecs0.html * igt@i915_pm_dc@dc9-dpms: - shard-iclb: [SKIP][95] ([i915#4281]) -> [PASS][96] [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-iclb3/igt@i915_pm_dc@dc9-dpms.html [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-iclb1/igt@i915_pm_dc@dc9-dpms.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-tglb: [INCOMPLETE][97] ([i915#456] / [i915#750]) -> [PASS][98] [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-tglb7/igt@i915_suspend@fence-restore-tiled2untiled.html [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@i915_suspend@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [DMESG-WARN][99] ([i915#180]) -> [PASS][100] +3 similar issues [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl3/igt@kms_cursor_crc@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-d-cursor-suspend: - shard-tglb: [INCOMPLETE][101] ([i915#2411] / [i915#4211]) -> [PASS][102] [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-tglb7/igt@kms_cursor_crc@pipe-d-cursor-suspend.html [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-tglb3/igt@kms_cursor_crc@pipe-d-cursor-suspend.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1: - shard-glk: [FAIL][103] ([i915#2122]) -> [PASS][104] +1 similar issue [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-glk3/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1.html [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-glk3/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1.html * igt@kms_hdr@bpc-switch: - shard-skl: [FAIL][105] ([i915#1188]) -> [PASS][106] [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl7/igt@kms_hdr@bpc-switch.html [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl1/igt@kms_hdr@bpc-switch.html #### Warnings #### * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-iclb: [FAIL][107] ([i915#2852]) -> [FAIL][108] ([i915#2842]) [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-iclb1/igt@gem_exec_fair@basic-none-rrul@rcs0.html [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-iclb8/igt@gem_exec_fair@basic-none-rrul@rcs0.html * igt@runner@aborted: - shard-kbl: ([FAIL][109], [FAIL][110], [FAIL][111], [FAIL][112], [FAIL][113], [FAIL][114], [FAIL][115], [FAIL][116], [FAIL][117], [FAIL][118]) ([i915#180] / [i915#1814] / [i915#3002] / [i915#3363] / [i915#602]) -> ([FAIL][119], [FAIL][120], [FAIL][121], [FAIL][122], [FAIL][123], [FAIL][124], [FAIL][125], [FAIL][126], [FAIL][127], [FAIL][128]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#3363] / [i915#602] / [i915#92]) [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl4/igt@runner@aborted.html [110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl2/igt@runner@aborted.html [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl4/igt@runner@aborted.html [112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@runner@aborted.html [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl6/igt@runner@aborted.html [114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@runner@aborted.html [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@runner@aborted.html [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@runner@aborted.html [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl7/igt@runner@aborted.html [118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-kbl6/igt@runner@aborted.html [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl1/igt@runner@aborted.html [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl1/igt@runner@aborted.html [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@runner@aborted.html [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl6/igt@runner@aborted.html [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl7/igt@runner@aborted.html [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@runner@aborted.html [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl6/igt@runner@aborted.html [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@runner@aborted.html [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl7/igt@runner@aborted.html [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-kbl4/igt@runner@aborted.html - shard-apl: ([FAIL][129], [FAIL][130], [FAIL][131]) ([i915#1610] / [i915#180] / [i915#1814] / [i915#3002] / [i915#3363]) -> ([FAIL][132], [FAIL][133], [FAIL][134], [FAIL][135], [FAIL][136]) ([fdo#109271] / [i915#180] / [i915#3002] / [i915#3363]) [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-apl8/igt@runner@aborted.html [130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-apl8/igt@runner@aborted.html [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-apl6/igt@runner@aborted.html [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl1/igt@runner@aborted.html [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl6/igt@runner@aborted.html [134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl8/igt@runner@aborted.html [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl3/igt@runner@aborted.html [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-apl1/igt@runner@aborted.html - shard-skl: ([FAIL][137], [FAIL][138], [FAIL][139]) ([i915#2029] / [i915#3002] / [i915#3363]) -> ([FAIL][140], [FAIL][141], [FAIL][142]) ([i915#1436] / [i915#3002] / [i915#3363]) [137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl3/igt@runner@aborted.html [138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl2/igt@runner@aborted.html [139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10719/shard-skl5/igt@runner@aborted.html [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl7/igt@runner@aborted.html [141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl1/igt@runner@aborted.html [142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/shard-skl7/igt@runner@aborted.html [IGT#2]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/2 [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291 [fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542 [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614 [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615 [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1099]: https://gitlab.freedesktop.org/drm/intel/issues/1099 [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118 [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188 [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542 [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610 [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180 [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437 [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265 [i915#2681]: https://gitlab.free == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21313/index.html [-- Attachment #2: Type: text/html, Size: 36431 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-11 23:47 [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest Matthew Brost 2021-10-12 0:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork 2021-10-12 4:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork @ 2021-10-21 6:15 ` Thomas Hellström 2021-10-21 20:37 ` Matthew Brost 2021-10-26 19:48 ` John Harrison 3 siblings, 1 reply; 18+ messages in thread From: Thomas Hellström @ 2021-10-21 6:15 UTC (permalink / raw) To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison Hi, Matthew, On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: > The hangcheck selftest blocks per engine resets by setting magic bits > in > the reset flags. This is incorrect for GuC submission because if the > GuC > fails to reset an engine we would like to do a full GT reset. Do no > set > these magic bits when using GuC submission. > > Side note this lockless algorithm with magic bits to block resets > really > should be ripped out. > Lockless algorithm aside, from a quick look at the code in intel_reset.c it appears to me like the interface that falls back to a full GT reset is intel_gt_handle_error() whereas intel_engine_reset() is explicitly intended to not do that, so is there a discrepancy between GuC and non-GuC here? /Thomas > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > --- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > index 7e2d99dd012d..90a03c60c80c 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt > *gt, bool active) > reset_engine_count = i915_reset_engine_count(global, > engine); > > st_engine_heartbeat_disable(engine); > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + set_bit(I915_RESET_ENGINE + id, >- > >reset.flags); > count = 0; > do { > struct i915_request *rq = NULL; > @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt > *gt, bool active) > if (err) > break; > } while (time_before(jiffies, end_time)); > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + clear_bit(I915_RESET_ENGINE + id, >- > >reset.flags); > st_engine_heartbeat_enable(engine); > pr_info("%s: Completed %lu %s resets\n", > engine->name, count, active ? "active" : > "idle"); > @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt > *gt, > yield(); /* start all threads before we begin */ > > st_engine_heartbeat_disable_no_pm(engine); > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + set_bit(I915_RESET_ENGINE + id, >- > >reset.flags); > do { > struct i915_request *rq = NULL; > struct intel_selftest_saved_policy saved; > @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt > *gt, > if (err) > break; > } while (time_before(jiffies, end_time)); > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + clear_bit(I915_RESET_ENGINE + id, >- > >reset.flags); > st_engine_heartbeat_enable_no_pm(engine); > > pr_info("i915_reset_engine(%s:%s): %lu resets\n", ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-21 6:15 ` [Intel-gfx] [PATCH] " Thomas Hellström @ 2021-10-21 20:37 ` Matthew Brost 2021-10-22 6:23 ` Thomas Hellström 2021-10-26 8:22 ` Thomas Hellström 0 siblings, 2 replies; 18+ messages in thread From: Matthew Brost @ 2021-10-21 20:37 UTC (permalink / raw) To: Thomas Hellström; +Cc: intel-gfx, dri-devel, john.c.harrison On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: > Hi, Matthew, > > On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: > > The hangcheck selftest blocks per engine resets by setting magic bits > > in > > the reset flags. This is incorrect for GuC submission because if the > > GuC > > fails to reset an engine we would like to do a full GT reset. Do no > > set > > these magic bits when using GuC submission. > > > > Side note this lockless algorithm with magic bits to block resets > > really > > should be ripped out. > > > > Lockless algorithm aside, from a quick look at the code in > intel_reset.c it appears to me like the interface that falls back to a > full GT reset is intel_gt_handle_error() whereas intel_engine_reset() > is explicitly intended to not do that, so is there a discrepancy > between GuC and non-GuC here? > With GuC submission when an engine reset fails, we get an engine reset failure notification which triggers a full GT reset (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That reset is blocking by setting these magic bits. Clearing the bits in this function doesn't seem to unblock that reset either, the driver tries to unload with a worker blocked, and results in the blow up. Something with this lockless algorithm could be wrong as clear of the bit should unlblock the reset but it is doesn't. We can look into that but in the meantime we need to fix this test to be able to fail gracefully and not crash CI. Matt > /Thomas > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > --- > > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > index 7e2d99dd012d..90a03c60c80c 100644 > > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt > > *gt, bool active) > > reset_engine_count = i915_reset_engine_count(global, > > engine); > > > > st_engine_heartbeat_disable(engine); > > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > > + if (!using_guc) > > + set_bit(I915_RESET_ENGINE + id, >- > > >reset.flags); > > count = 0; > > do { > > struct i915_request *rq = NULL; > > @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt > > *gt, bool active) > > if (err) > > break; > > } while (time_before(jiffies, end_time)); > > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > > + if (!using_guc) > > + clear_bit(I915_RESET_ENGINE + id, >- > > >reset.flags); > > st_engine_heartbeat_enable(engine); > > pr_info("%s: Completed %lu %s resets\n", > > engine->name, count, active ? "active" : > > "idle"); > > @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt > > *gt, > > yield(); /* start all threads before we begin */ > > > > st_engine_heartbeat_disable_no_pm(engine); > > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > > + if (!using_guc) > > + set_bit(I915_RESET_ENGINE + id, >- > > >reset.flags); > > do { > > struct i915_request *rq = NULL; > > struct intel_selftest_saved_policy saved; > > @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt > > *gt, > > if (err) > > break; > > } while (time_before(jiffies, end_time)); > > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > > + if (!using_guc) > > + clear_bit(I915_RESET_ENGINE + id, >- > > >reset.flags); > > st_engine_heartbeat_enable_no_pm(engine); > > > > pr_info("i915_reset_engine(%s:%s): %lu resets\n", > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-21 20:37 ` Matthew Brost @ 2021-10-22 6:23 ` Thomas Hellström 2021-10-22 17:03 ` Matthew Brost 2021-10-26 19:55 ` John Harrison 2021-10-26 8:22 ` Thomas Hellström 1 sibling, 2 replies; 18+ messages in thread From: Thomas Hellström @ 2021-10-22 6:23 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-gfx, dri-devel, john.c.harrison On 10/21/21 22:37, Matthew Brost wrote: > On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >> Hi, Matthew, >> >> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>> The hangcheck selftest blocks per engine resets by setting magic bits >>> in >>> the reset flags. This is incorrect for GuC submission because if the >>> GuC >>> fails to reset an engine we would like to do a full GT reset. Do no >>> set >>> these magic bits when using GuC submission. >>> >>> Side note this lockless algorithm with magic bits to block resets >>> really >>> should be ripped out. >>> >> Lockless algorithm aside, from a quick look at the code in >> intel_reset.c it appears to me like the interface that falls back to a >> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >> is explicitly intended to not do that, so is there a discrepancy >> between GuC and non-GuC here? >> > With GuC submission when an engine reset fails, we get an engine reset > failure notification which triggers a full GT reset > (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That > reset is blocking by setting these magic bits. Clearing the bits in this > function doesn't seem to unblock that reset either, the driver tries to > unload with a worker blocked, and results in the blow up. Something with > this lockless algorithm could be wrong as clear of the bit should > unlblock the reset but it is doesn't. We can look into that but in the > meantime we need to fix this test to be able to fail gracefully and not > crash CI. Yeah, for that lockless algorithm if needed, we might want to use a ww_mutex per engine or something, but point was that AFAICT at least one of the tests that set those flags explicitly tested the functionality that no other engines than the intended one was reset when the intel_engine_reset() function was used, and then if GuC submission doesn't honor that, wouldn't a better approach be to make a code comment around intel_engine_reset() to explain the differences and disable that particular test for GuC?. Also wouldn't we for example we see a duplicated full GT reset with GuC if intel_engine_reset() fails as part of the intel_gt_handle_error() function? I guess we could live with the hangcheck test being disabled for guc submission until this is sorted out? /Thomas > > Matt > >> /Thomas >> >> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>> --- >>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- >>> 1 file changed, 8 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> index 7e2d99dd012d..90a03c60c80c 100644 >>> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt >>> *gt, bool active) >>> reset_engine_count = i915_reset_engine_count(global, >>> engine); >>> >>> st_engine_heartbeat_disable(engine); >>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + set_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> count = 0; >>> do { >>> struct i915_request *rq = NULL; >>> @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt >>> *gt, bool active) >>> if (err) >>> break; >>> } while (time_before(jiffies, end_time)); >>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + clear_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> st_engine_heartbeat_enable(engine); >>> pr_info("%s: Completed %lu %s resets\n", >>> engine->name, count, active ? "active" : >>> "idle"); >>> @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt >>> *gt, >>> yield(); /* start all threads before we begin */ >>> >>> st_engine_heartbeat_disable_no_pm(engine); >>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + set_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> do { >>> struct i915_request *rq = NULL; >>> struct intel_selftest_saved_policy saved; >>> @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt >>> *gt, >>> if (err) >>> break; >>> } while (time_before(jiffies, end_time)); >>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + clear_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> st_engine_heartbeat_enable_no_pm(engine); >>> >>> pr_info("i915_reset_engine(%s:%s): %lu resets\n", >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-22 6:23 ` Thomas Hellström @ 2021-10-22 17:03 ` Matthew Brost 2021-10-22 18:09 ` John Harrison 2021-10-26 19:55 ` John Harrison 1 sibling, 1 reply; 18+ messages in thread From: Matthew Brost @ 2021-10-22 17:03 UTC (permalink / raw) To: Thomas Hellström; +Cc: intel-gfx, dri-devel, john.c.harrison On Fri, Oct 22, 2021 at 08:23:55AM +0200, Thomas Hellström wrote: > > On 10/21/21 22:37, Matthew Brost wrote: > > On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: > > > Hi, Matthew, > > > > > > On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: > > > > The hangcheck selftest blocks per engine resets by setting magic bits > > > > in > > > > the reset flags. This is incorrect for GuC submission because if the > > > > GuC > > > > fails to reset an engine we would like to do a full GT reset. Do no > > > > set > > > > these magic bits when using GuC submission. > > > > > > > > Side note this lockless algorithm with magic bits to block resets > > > > really > > > > should be ripped out. > > > > > > > Lockless algorithm aside, from a quick look at the code in > > > intel_reset.c it appears to me like the interface that falls back to a > > > full GT reset is intel_gt_handle_error() whereas intel_engine_reset() > > > is explicitly intended to not do that, so is there a discrepancy > > > between GuC and non-GuC here? > > > > > With GuC submission when an engine reset fails, we get an engine reset > > failure notification which triggers a full GT reset > > (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That > > reset is blocking by setting these magic bits. Clearing the bits in this > > function doesn't seem to unblock that reset either, the driver tries to > > unload with a worker blocked, and results in the blow up. Something with > > this lockless algorithm could be wrong as clear of the bit should > > unlblock the reset but it is doesn't. We can look into that but in the > > meantime we need to fix this test to be able to fail gracefully and not > > crash CI. > > Yeah, for that lockless algorithm if needed, we might want to use a ww_mutex > per engine or something, Do ww_mutex sleep? From what I can tell this lockless algorithm was added because even though resets are protected by mutex, there are some places in the IRQ context where we need to prevent resets from happening, hence the lockless protection + the mutex - what a mess. Long term this needs to rethought. > but point was that AFAICT at least one of the tests that set those flags > explicitly tested the functionality that no other engines than the intended > one was reset when the intel_engine_reset() function was used, and then if > GuC submission doesn't honor that, wouldn't a better approach be to make a No. In execlists this test explictly calls the engine reset function and explictly prevents other parts of the i915 from calling the engine reset function - this is why it sets that bit. In GuC submission the i915 can't do engine resets, the GuC does. In this case the engine reset fails which triggers a G2H message which tells the i915 to do a GT reset. If this bit is set the worker blocks on this bit in the GT reset and the driver blows up on unload as this worker isn't complete (believe it has a PM ref or something). > code comment around intel_engine_reset() to explain the differences and intel_engine_reset() return -ENODEV in GuC submission as the i915 isn't allowed to engine resets. > disable that particular test for GuC?. Also wouldn't we for example we see a > duplicated full GT reset with GuC if intel_engine_reset() fails as part of > the intel_gt_handle_error() function? > Yes, but the GT reset in this test is done after clearing the bits by the test. In the case of the GuC the GT reset is async operation done by a worker that receives the G2H message saying the engine reset failed. > I guess we could live with the hangcheck test being disabled for guc > submission until this is sorted out? > Wouldn't help. See above this an async operation from G2H message. We can't disable the async G2H handler as without other G2H messages the world breaks. The only other possible fix would be add an IGT only variable that if set skips the handling this G2H only. I can assure with this patch, if the test fails, it fails gracefully which is what we want. Matt > /Thomas > > > > > > Matt > > > > > /Thomas > > > > > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > --- > > > > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- > > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > > > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > > > index 7e2d99dd012d..90a03c60c80c 100644 > > > > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > > > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > > > > @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt > > > > *gt, bool active) > > > > reset_engine_count = i915_reset_engine_count(global, > > > > engine); > > > > st_engine_heartbeat_disable(engine); > > > > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > > > > + if (!using_guc) > > > > + set_bit(I915_RESET_ENGINE + id, >- > > > > > reset.flags); > > > > count = 0; > > > > do { > > > > struct i915_request *rq = NULL; > > > > @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt > > > > *gt, bool active) > > > > if (err) > > > > break; > > > > } while (time_before(jiffies, end_time)); > > > > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > > > > + if (!using_guc) > > > > + clear_bit(I915_RESET_ENGINE + id, >- > > > > > reset.flags); > > > > st_engine_heartbeat_enable(engine); > > > > pr_info("%s: Completed %lu %s resets\n", > > > > engine->name, count, active ? "active" : > > > > "idle"); > > > > @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt > > > > *gt, > > > > yield(); /* start all threads before we begin */ > > > > st_engine_heartbeat_disable_no_pm(engine); > > > > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > > > > + if (!using_guc) > > > > + set_bit(I915_RESET_ENGINE + id, >- > > > > > reset.flags); > > > > do { > > > > struct i915_request *rq = NULL; > > > > struct intel_selftest_saved_policy saved; > > > > @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt > > > > *gt, > > > > if (err) > > > > break; > > > > } while (time_before(jiffies, end_time)); > > > > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > > > > + if (!using_guc) > > > > + clear_bit(I915_RESET_ENGINE + id, >- > > > > > reset.flags); > > > > st_engine_heartbeat_enable_no_pm(engine); > > > > pr_info("i915_reset_engine(%s:%s): %lu resets\n", > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-22 17:03 ` Matthew Brost @ 2021-10-22 18:09 ` John Harrison 2021-10-23 17:46 ` Thomas Hellström 0 siblings, 1 reply; 18+ messages in thread From: John Harrison @ 2021-10-22 18:09 UTC (permalink / raw) To: Matthew Brost, Thomas Hellström; +Cc: intel-gfx, dri-devel On 10/22/2021 10:03, Matthew Brost wrote: > On Fri, Oct 22, 2021 at 08:23:55AM +0200, Thomas Hellström wrote: >> On 10/21/21 22:37, Matthew Brost wrote: >>> On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >>>> Hi, Matthew, >>>> >>>> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>>>> The hangcheck selftest blocks per engine resets by setting magic bits >>>>> in >>>>> the reset flags. This is incorrect for GuC submission because if the >>>>> GuC >>>>> fails to reset an engine we would like to do a full GT reset. Do no >>>>> set >>>>> these magic bits when using GuC submission. >>>>> >>>>> Side note this lockless algorithm with magic bits to block resets >>>>> really >>>>> should be ripped out. >>>>> >>>> Lockless algorithm aside, from a quick look at the code in >>>> intel_reset.c it appears to me like the interface that falls back to a >>>> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >>>> is explicitly intended to not do that, so is there a discrepancy >>>> between GuC and non-GuC here? >>>> >>> With GuC submission when an engine reset fails, we get an engine reset >>> failure notification which triggers a full GT reset >>> (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That >>> reset is blocking by setting these magic bits. Clearing the bits in this >>> function doesn't seem to unblock that reset either, the driver tries to >>> unload with a worker blocked, and results in the blow up. Something with >>> this lockless algorithm could be wrong as clear of the bit should >>> unlblock the reset but it is doesn't. We can look into that but in the >>> meantime we need to fix this test to be able to fail gracefully and not >>> crash CI. >> Yeah, for that lockless algorithm if needed, we might want to use a ww_mutex >> per engine or something, > Do ww_mutex sleep? From what I can tell this lockless algorithm was > added because even though resets are protected by mutex, there are some > places in the IRQ context where we need to prevent resets from > happening, hence the lockless protection + the mutex - what a mess. Long > term this needs to rethought. > >> but point was that AFAICT at least one of the tests that set those flags >> explicitly tested the functionality that no other engines than the intended >> one was reset when the intel_engine_reset() function was used, and then if >> GuC submission doesn't honor that, wouldn't a better approach be to make a > No. In execlists this test explictly calls the engine reset function and > explictly prevents other parts of the i915 from calling the engine reset > function - this is why it sets that bit. > > In GuC submission the i915 can't do engine resets, the GuC does. In this > case the engine reset fails which triggers a G2H message which tells the > i915 to do a GT reset. If this bit is set the worker blocks on this bit > in the GT reset and the driver blows up on unload as this worker isn't > complete (believe it has a PM ref or something). > >> code comment around intel_engine_reset() to explain the differences and > intel_engine_reset() return -ENODEV in GuC submission as the i915 isn't > allowed to engine resets. > >> disable that particular test for GuC?. Also wouldn't we for example we see a >> duplicated full GT reset with GuC if intel_engine_reset() fails as part of >> the intel_gt_handle_error() function? >> > Yes, but the GT reset in this test is done after clearing the bits by > the test. In the case of the GuC the GT reset is async operation done by > a worker that receives the G2H message saying the engine reset failed. > >> I guess we could live with the hangcheck test being disabled for guc >> submission until this is sorted out? >> > Wouldn't help. See above this an async operation from G2H message. We > can't disable the async G2H handler as without other G2H messages the > world breaks. The only other possible fix would be add an IGT only > variable that if set skips the handling this G2H only. And to be clear, the engine reset is not supposed to fail. Whether issued by GuC or i915, the GDRST register is supposed to self clear according to the bspec. If we are being sent the G2H notification for an engine reset failure then the assumption is that the hardware is broken. This is not a situation that is ever intended to occur in a production system. Therefore, it is not something we should spend huge amounts of effort on making a perfect selftest for. The current theory is that the timeout in GuC is not quite long enough for DG1. Given that the bspec does not specify any kind of timeout, it is only a best guess anyway! Once that has been tuned correctly, we should never hit this case again. Not ever, Not in a selftest, not in an end user use case, just not ever. John. > > I can assure with this patch, if the test fails, it fails gracefully > which is what we want. > > Matt > >> /Thomas >> >> >>> Matt >>> >>>> /Thomas >>>> >>>> >>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>>>> --- >>>>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- >>>>> 1 file changed, 8 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>>> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>>> index 7e2d99dd012d..90a03c60c80c 100644 >>>>> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>>> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>>> @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt >>>>> *gt, bool active) >>>>> reset_engine_count = i915_reset_engine_count(global, >>>>> engine); >>>>> st_engine_heartbeat_disable(engine); >>>>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>>> + if (!using_guc) >>>>> + set_bit(I915_RESET_ENGINE + id, >- >>>>>> reset.flags); >>>>> count = 0; >>>>> do { >>>>> struct i915_request *rq = NULL; >>>>> @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt >>>>> *gt, bool active) >>>>> if (err) >>>>> break; >>>>> } while (time_before(jiffies, end_time)); >>>>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>>> + if (!using_guc) >>>>> + clear_bit(I915_RESET_ENGINE + id, >- >>>>>> reset.flags); >>>>> st_engine_heartbeat_enable(engine); >>>>> pr_info("%s: Completed %lu %s resets\n", >>>>> engine->name, count, active ? "active" : >>>>> "idle"); >>>>> @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt >>>>> *gt, >>>>> yield(); /* start all threads before we begin */ >>>>> st_engine_heartbeat_disable_no_pm(engine); >>>>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>>> + if (!using_guc) >>>>> + set_bit(I915_RESET_ENGINE + id, >- >>>>>> reset.flags); >>>>> do { >>>>> struct i915_request *rq = NULL; >>>>> struct intel_selftest_saved_policy saved; >>>>> @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt >>>>> *gt, >>>>> if (err) >>>>> break; >>>>> } while (time_before(jiffies, end_time)); >>>>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>>> + if (!using_guc) >>>>> + clear_bit(I915_RESET_ENGINE + id, >- >>>>>> reset.flags); >>>>> st_engine_heartbeat_enable_no_pm(engine); >>>>> pr_info("i915_reset_engine(%s:%s): %lu resets\n", ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-22 18:09 ` John Harrison @ 2021-10-23 17:46 ` Thomas Hellström 2021-10-23 18:18 ` Matthew Brost 0 siblings, 1 reply; 18+ messages in thread From: Thomas Hellström @ 2021-10-23 17:46 UTC (permalink / raw) To: John Harrison, Matthew Brost; +Cc: intel-gfx, dri-devel On 10/22/21 20:09, John Harrison wrote: > And to be clear, the engine reset is not supposed to fail. Whether > issued by GuC or i915, the GDRST register is supposed to self clear > according to the bspec. If we are being sent the G2H notification for > an engine reset failure then the assumption is that the hardware is > broken. This is not a situation that is ever intended to occur in a > production system. Therefore, it is not something we should spend huge > amounts of effort on making a perfect selftest for. I don't agree. Selftests are there to verify that assumptions made and contracts in the code hold and that hardware behaves as intended / assumed. No selftest should ideally trigger in a production driver / system. That doesn't mean we can remove all selftests or ignore updating them for altered assumptions / contracts. I think it's important here to acknowledge the fact that this and the perf selftest have found two problems that need consideration for fixing for a production system. > > The current theory is that the timeout in GuC is not quite long enough > for DG1. Given that the bspec does not specify any kind of timeout, it > is only a best guess anyway! Once that has been tuned correctly, we > should never hit this case again. Not ever, Not in a selftest, not in > an end user use case, just not ever. ..until we introduce new hardware for which the tuning doesn't hold anymore or somebody in a two years wants to lower the timeout wondering why it was set so long? /Thomas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-23 17:46 ` Thomas Hellström @ 2021-10-23 18:18 ` Matthew Brost 2021-10-23 18:36 ` Thomas Hellström 0 siblings, 1 reply; 18+ messages in thread From: Matthew Brost @ 2021-10-23 18:18 UTC (permalink / raw) To: Thomas Hellström; +Cc: John Harrison, intel-gfx, dri-devel On Sat, Oct 23, 2021 at 07:46:48PM +0200, Thomas Hellström wrote: > > On 10/22/21 20:09, John Harrison wrote: > > And to be clear, the engine reset is not supposed to fail. Whether > > issued by GuC or i915, the GDRST register is supposed to self clear > > according to the bspec. If we are being sent the G2H notification for an > > engine reset failure then the assumption is that the hardware is broken. > > This is not a situation that is ever intended to occur in a production > > system. Therefore, it is not something we should spend huge amounts of > > effort on making a perfect selftest for. > > I don't agree. Selftests are there to verify that assumptions made and > contracts in the code hold and that hardware behaves as intended / assumed. > No selftest should ideally trigger in a production driver / system. That > doesn't mean we can remove all selftests or ignore updating them for altered > assumptions / contracts. I think it's important here to acknowledge the fact > that this and the perf selftest have found two problems that need > consideration for fixing for a production system. > I'm confused - we are going down the rabbit hole here. Back to this patch. This test was written for very specific execlists behavior. It was updated to also support the GuC. In that update we missed fixing the failure path, well because it always passed. Now it has failed, we see that it doesn't fail gracefully, and takes down the machine. This patch fixes that. It also openned my eyes to the horror show reset locking that needs to be fixed long term. > > > > The current theory is that the timeout in GuC is not quite long enough > > for DG1. Given that the bspec does not specify any kind of timeout, it > > is only a best guess anyway! Once that has been tuned correctly, we > > should never hit this case again. Not ever, Not in a selftest, not in an > > end user use case, just not ever. > > ..until we introduce new hardware for which the tuning doesn't hold anymore > or somebody in a two years wants to lower the timeout wondering why it was > set so long? If an engine reset fails in the GuC, the GuC signals the i915 via a G2H that the engine reset has failed and i915 initiates a full GT reset. After this patch (which removes hacky behavior to block foreign, relative to the test, resets) we can see the i915 behaving correctly and the GPU recovering. This path in the code is working as designed. Do you have test for that behavior, no. Can we? No at the moment as we would need a way for the GuC to intentionally fail a engine reset. Right now all we have is either flaky HW or GuC isn't waiting long enough. As far as why the engine reset fails - I am currently working with the GuC team to get a firmware with a configurable timeout period so we can root cause the engine failure. Figures crossed we are just not waiting long enough rather than a HW issue. Regardless of everything above, this patch is correct to unblock CI in the short term and is correct in the long term too as this test shouldn't bring down CI when it fails. Matt > > /Thomas > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-23 18:18 ` Matthew Brost @ 2021-10-23 18:36 ` Thomas Hellström 2021-10-25 17:32 ` John Harrison 0 siblings, 1 reply; 18+ messages in thread From: Thomas Hellström @ 2021-10-23 18:36 UTC (permalink / raw) To: Matthew Brost; +Cc: John Harrison, intel-gfx, dri-devel On 10/23/21 20:18, Matthew Brost wrote: > On Sat, Oct 23, 2021 at 07:46:48PM +0200, Thomas Hellström wrote: >> On 10/22/21 20:09, John Harrison wrote: >>> And to be clear, the engine reset is not supposed to fail. Whether >>> issued by GuC or i915, the GDRST register is supposed to self clear >>> according to the bspec. If we are being sent the G2H notification for an >>> engine reset failure then the assumption is that the hardware is broken. >>> This is not a situation that is ever intended to occur in a production >>> system. Therefore, it is not something we should spend huge amounts of >>> effort on making a perfect selftest for. >> I don't agree. Selftests are there to verify that assumptions made and >> contracts in the code hold and that hardware behaves as intended / assumed. >> No selftest should ideally trigger in a production driver / system. That >> doesn't mean we can remove all selftests or ignore updating them for altered >> assumptions / contracts. I think it's important here to acknowledge the fact >> that this and the perf selftest have found two problems that need >> consideration for fixing for a production system. >> > I'm confused - we are going down the rabbit hole here. > > Back to this patch. This test was written for very specific execlists > behavior. It was updated to also support the GuC. In that update we > missed fixing the failure path, well because it always passed. Now it > has failed, we see that it doesn't fail gracefully, and takes down the > machine. This patch fixes that. It also openned my eyes to the horror > show reset locking that needs to be fixed long term. Well the email above wasn't really about the correctness of this particular patch (I should probably have altered the subject to reflect that) but rather about the assumption that failures that should never occur in a production system are not worth spending time on selftests for. For the patch itself, I'll take a deeper look at the patch and get back. /Thomas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-23 18:36 ` Thomas Hellström @ 2021-10-25 17:32 ` John Harrison 0 siblings, 0 replies; 18+ messages in thread From: John Harrison @ 2021-10-25 17:32 UTC (permalink / raw) To: Thomas Hellström, Matthew Brost; +Cc: intel-gfx, dri-devel On 10/23/2021 11:36, Thomas Hellström wrote: > On 10/23/21 20:18, Matthew Brost wrote: >> On Sat, Oct 23, 2021 at 07:46:48PM +0200, Thomas Hellström wrote: >>> On 10/22/21 20:09, John Harrison wrote: >>>> And to be clear, the engine reset is not supposed to fail. Whether >>>> issued by GuC or i915, the GDRST register is supposed to self clear >>>> according to the bspec. If we are being sent the G2H notification >>>> for an >>>> engine reset failure then the assumption is that the hardware is >>>> broken. >>>> This is not a situation that is ever intended to occur in a production >>>> system. Therefore, it is not something we should spend huge amounts of >>>> effort on making a perfect selftest for. >>> I don't agree. Selftests are there to verify that assumptions made and >>> contracts in the code hold and that hardware behaves as intended / >>> assumed. >>> No selftest should ideally trigger in a production driver / system. >>> That >>> doesn't mean we can remove all selftests or ignore updating them for >>> altered >>> assumptions / contracts. I think it's important here to acknowledge >>> the fact >>> that this and the perf selftest have found two problems that need >>> consideration for fixing for a production system. >>> >> I'm confused - we are going down the rabbit hole here. >> >> Back to this patch. This test was written for very specific execlists >> behavior. It was updated to also support the GuC. In that update we >> missed fixing the failure path, well because it always passed. Now it >> has failed, we see that it doesn't fail gracefully, and takes down the >> machine. This patch fixes that. It also openned my eyes to the horror >> show reset locking that needs to be fixed long term. > > Well the email above wasn't really about the correctness of this > particular patch (I should probably have altered the subject to > reflect that) but rather about the assumption that failures that > should never occur in a production system are not worth spending time > on selftests for. My point is that we have to make assumptions that the hardware is basically functional. Otherwise, where do you stop? Do you write a selftest for every conceivable operation of the hardware and prove that it still works every single day? No. That is pointless and we don't have the resources to test everything that the hardware can possibly do. We have to cope as gracefully as possible in the case where the hardware does not behave as intended, such as not killing the entire OS when a selftest fails. But I don't think we should be spending time on writing a perfect test for something that is supposed to be impossible at the hardware level. The purpose of the selftests is to test the driver behaviour, not the hardware. John. > > For the patch itself, I'll take a deeper look at the patch and get back. > > /Thomas > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-22 6:23 ` Thomas Hellström 2021-10-22 17:03 ` Matthew Brost @ 2021-10-26 19:55 ` John Harrison 2021-10-27 6:36 ` Thomas Hellström 1 sibling, 1 reply; 18+ messages in thread From: John Harrison @ 2021-10-26 19:55 UTC (permalink / raw) To: Thomas Hellström, Matthew Brost; +Cc: intel-gfx, dri-devel On 10/21/2021 23:23, Thomas Hellström wrote: > On 10/21/21 22:37, Matthew Brost wrote: >> On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >>> Hi, Matthew, >>> >>> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>>> The hangcheck selftest blocks per engine resets by setting magic bits >>>> in >>>> the reset flags. This is incorrect for GuC submission because if the >>>> GuC >>>> fails to reset an engine we would like to do a full GT reset. Do no >>>> set >>>> these magic bits when using GuC submission. >>>> >>>> Side note this lockless algorithm with magic bits to block resets >>>> really >>>> should be ripped out. >>>> >>> Lockless algorithm aside, from a quick look at the code in >>> intel_reset.c it appears to me like the interface that falls back to a >>> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >>> is explicitly intended to not do that, so is there a discrepancy >>> between GuC and non-GuC here? >>> >> With GuC submission when an engine reset fails, we get an engine reset >> failure notification which triggers a full GT reset >> (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That >> reset is blocking by setting these magic bits. Clearing the bits in this >> function doesn't seem to unblock that reset either, the driver tries to >> unload with a worker blocked, and results in the blow up. Something with >> this lockless algorithm could be wrong as clear of the bit should >> unlblock the reset but it is doesn't. We can look into that but in the >> meantime we need to fix this test to be able to fail gracefully and not >> crash CI. > > Yeah, for that lockless algorithm if needed, we might want to use a > ww_mutex per engine or something, > but point was that AFAICT at least one of the tests that set those > flags explicitly tested the functionality that no other engines than > the intended one was reset when the intel_engine_reset() function was > used, and then if GuC submission doesn't honor that, wouldn't a better > approach be to make a code comment around intel_engine_reset() to > explain the differences and disable that particular test for GuC?. > Also wouldn't we for example we see a duplicated full GT reset with > GuC if intel_engine_reset() fails as part of the > intel_gt_handle_error() function? Re-reading this thread, I think there is a misunderstanding. The selftests themselves have already been updated to support GuC based engine resets. That is done by submitting a hanging context and letting the GuC detect the hang and issue a reset. There is no mechanism available for i915 to directly issue or request an engine based reset (because i915 does not know what is running on any given engine at any given time, being disconnected from the scheduler). So the tests are already correctly testing per engine resets and do not go anywhere near either intel_engine_reset() or intel_gt_handle_error() when GuC submission is used. The problem is what happens if the engine reset fails (which supposedly can only happen with broken hardware). In that scenario, there is an asynchronous message from GuC to i915 to notify us of the failure. The KMD receives that notification and then (eventually) calls intel_gt_handle_error() to issue a full GT reset. However, that is blocked because the selftest is not expecting it and has vetoed the possibility. A fix is required to allow that full GT reset to proceed and recover the hardware. At that point, the selftest should indeed fail because the reset was larger than expected. That should be handled by the fact the selftest issued work to other engines beside the target and expects those requests to complete successfully. In the case of the escalated GT reset, all those requests will be killed off as well. Thus the test will correctly fail. John. > > I guess we could live with the hangcheck test being disabled for guc > submission until this is sorted out? > > /Thomas > > >> >> Matt >> >>> /Thomas >>> >>> >>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>>> --- >>>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- >>>> 1 file changed, 8 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>> index 7e2d99dd012d..90a03c60c80c 100644 >>>> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>>> @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt >>>> *gt, bool active) >>>> reset_engine_count = i915_reset_engine_count(global, >>>> engine); >>>> st_engine_heartbeat_disable(engine); >>>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>> + if (!using_guc) >>>> + set_bit(I915_RESET_ENGINE + id, >- >>>>> reset.flags); >>>> count = 0; >>>> do { >>>> struct i915_request *rq = NULL; >>>> @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt >>>> *gt, bool active) >>>> if (err) >>>> break; >>>> } while (time_before(jiffies, end_time)); >>>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>> + if (!using_guc) >>>> + clear_bit(I915_RESET_ENGINE + id, >- >>>>> reset.flags); >>>> st_engine_heartbeat_enable(engine); >>>> pr_info("%s: Completed %lu %s resets\n", >>>> engine->name, count, active ? "active" : >>>> "idle"); >>>> @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt >>>> *gt, >>>> yield(); /* start all threads before we begin */ >>>> st_engine_heartbeat_disable_no_pm(engine); >>>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>> + if (!using_guc) >>>> + set_bit(I915_RESET_ENGINE + id, >- >>>>> reset.flags); >>>> do { >>>> struct i915_request *rq = NULL; >>>> struct intel_selftest_saved_policy saved; >>>> @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt >>>> *gt, >>>> if (err) >>>> break; >>>> } while (time_before(jiffies, end_time)); >>>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>>> + if (!using_guc) >>>> + clear_bit(I915_RESET_ENGINE + id, >- >>>>> reset.flags); >>>> st_engine_heartbeat_enable_no_pm(engine); >>>> pr_info("i915_reset_engine(%s:%s): %lu resets\n", >>> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-26 19:55 ` John Harrison @ 2021-10-27 6:36 ` Thomas Hellström 2021-10-27 20:34 ` John Harrison 0 siblings, 1 reply; 18+ messages in thread From: Thomas Hellström @ 2021-10-27 6:36 UTC (permalink / raw) To: John Harrison, Matthew Brost; +Cc: intel-gfx, dri-devel Hi, John, On 10/26/21 21:55, John Harrison wrote: > On 10/21/2021 23:23, Thomas Hellström wrote: >> On 10/21/21 22:37, Matthew Brost wrote: >>> On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >>>> Hi, Matthew, >>>> >>>> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>>>> The hangcheck selftest blocks per engine resets by setting magic bits >>>>> in >>>>> the reset flags. This is incorrect for GuC submission because if the >>>>> GuC >>>>> fails to reset an engine we would like to do a full GT reset. Do no >>>>> set >>>>> these magic bits when using GuC submission. >>>>> >>>>> Side note this lockless algorithm with magic bits to block resets >>>>> really >>>>> should be ripped out. >>>>> >>>> Lockless algorithm aside, from a quick look at the code in >>>> intel_reset.c it appears to me like the interface that falls back to a >>>> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >>>> is explicitly intended to not do that, so is there a discrepancy >>>> between GuC and non-GuC here? >>>> >>> With GuC submission when an engine reset fails, we get an engine reset >>> failure notification which triggers a full GT reset >>> (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That >>> reset is blocking by setting these magic bits. Clearing the bits in >>> this >>> function doesn't seem to unblock that reset either, the driver tries to >>> unload with a worker blocked, and results in the blow up. Something >>> with >>> this lockless algorithm could be wrong as clear of the bit should >>> unlblock the reset but it is doesn't. We can look into that but in the >>> meantime we need to fix this test to be able to fail gracefully and not >>> crash CI. >> >> Yeah, for that lockless algorithm if needed, we might want to use a >> ww_mutex per engine or something, >> but point was that AFAICT at least one of the tests that set those >> flags explicitly tested the functionality that no other engines than >> the intended one was reset when the intel_engine_reset() function was >> used, and then if GuC submission doesn't honor that, wouldn't a >> better approach be to make a code comment around intel_engine_reset() >> to explain the differences and disable that particular test for GuC?. >> Also wouldn't we for example we see a duplicated full GT reset with >> GuC if intel_engine_reset() fails as part of the >> intel_gt_handle_error() function? > Re-reading this thread, I think there is a misunderstanding. > > The selftests themselves have already been updated to support GuC > based engine resets. That is done by submitting a hanging context and > letting the GuC detect the hang and issue a reset. There is no > mechanism available for i915 to directly issue or request an engine > based reset (because i915 does not know what is running on any given > engine at any given time, being disconnected from the scheduler). > > So the tests are already correctly testing per engine resets and do > not go anywhere near either intel_engine_reset() or > intel_gt_handle_error() when GuC submission is used. The problem is > what happens if the engine reset fails (which supposedly can only > happen with broken hardware). In that scenario, there is an > asynchronous message from GuC to i915 to notify us of the failure. The > KMD receives that notification and then (eventually) calls > intel_gt_handle_error() to issue a full GT reset. However, that is > blocked because the selftest is not expecting it and has vetoed the > possibility. This is where my understanding of the discussion differs. According to Matthew, the selftest actually proceeds to clear the bits, but the worker that calls into intel_gt_handle_error() never wakes up. (and that's probably due to clear_bit() being used instead of clear_and_wake_up_bit()). And my problem with this particular patch is that it adds even more "if (!guc_submission)" which is already sprinkled all over the place in the selftests to the point that it becomes difficult to see what (if anything) the tests are really testing. For example igt_reset_nop_engine() from a cursory look looks like it's doing something but inside the engine loop it becomes clear that the test doesn't do *anything* except iterate over engines. Same for igt_reset_engines() in the !TEST_ACTIVE case and for igt_reset_idle_engine(). For some other tests the reset_count checks are gone, leaving only a test that we actually do a reset. So if possible, as previously mentioned, I think a solution without adding more of this in the selftests is preferrable. To me the best option is probably be the one you suggest in your previous email: Don't wait on the I915_RESET_ENGINE bits with GuC in intel_gt_handle_error(), (or perhaps extract what's left in a separate function called from the GuC handler). Thanks, Thomas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-27 6:36 ` Thomas Hellström @ 2021-10-27 20:34 ` John Harrison 2021-10-27 20:47 ` Thomas Hellström 0 siblings, 1 reply; 18+ messages in thread From: John Harrison @ 2021-10-27 20:34 UTC (permalink / raw) To: Thomas Hellström, Matthew Brost; +Cc: intel-gfx, dri-devel On 10/26/2021 23:36, Thomas Hellström wrote: > Hi, John, > > On 10/26/21 21:55, John Harrison wrote: >> On 10/21/2021 23:23, Thomas Hellström wrote: >>> On 10/21/21 22:37, Matthew Brost wrote: >>>> On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >>>>> Hi, Matthew, >>>>> >>>>> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>>>>> The hangcheck selftest blocks per engine resets by setting magic >>>>>> bits >>>>>> in >>>>>> the reset flags. This is incorrect for GuC submission because if the >>>>>> GuC >>>>>> fails to reset an engine we would like to do a full GT reset. Do no >>>>>> set >>>>>> these magic bits when using GuC submission. >>>>>> >>>>>> Side note this lockless algorithm with magic bits to block resets >>>>>> really >>>>>> should be ripped out. >>>>>> >>>>> Lockless algorithm aside, from a quick look at the code in >>>>> intel_reset.c it appears to me like the interface that falls back >>>>> to a >>>>> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >>>>> is explicitly intended to not do that, so is there a discrepancy >>>>> between GuC and non-GuC here? >>>>> >>>> With GuC submission when an engine reset fails, we get an engine reset >>>> failure notification which triggers a full GT reset >>>> (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That >>>> reset is blocking by setting these magic bits. Clearing the bits in >>>> this >>>> function doesn't seem to unblock that reset either, the driver >>>> tries to >>>> unload with a worker blocked, and results in the blow up. Something >>>> with >>>> this lockless algorithm could be wrong as clear of the bit should >>>> unlblock the reset but it is doesn't. We can look into that but in the >>>> meantime we need to fix this test to be able to fail gracefully and >>>> not >>>> crash CI. >>> >>> Yeah, for that lockless algorithm if needed, we might want to use a >>> ww_mutex per engine or something, >>> but point was that AFAICT at least one of the tests that set those >>> flags explicitly tested the functionality that no other engines than >>> the intended one was reset when the intel_engine_reset() function >>> was used, and then if GuC submission doesn't honor that, wouldn't a >>> better approach be to make a code comment around >>> intel_engine_reset() to explain the differences and disable that >>> particular test for GuC?. Also wouldn't we for example we see a >>> duplicated full GT reset with GuC if intel_engine_reset() fails as >>> part of the intel_gt_handle_error() function? >> Re-reading this thread, I think there is a misunderstanding. >> >> The selftests themselves have already been updated to support GuC >> based engine resets. That is done by submitting a hanging context and >> letting the GuC detect the hang and issue a reset. There is no >> mechanism available for i915 to directly issue or request an engine >> based reset (because i915 does not know what is running on any given >> engine at any given time, being disconnected from the scheduler). >> >> So the tests are already correctly testing per engine resets and do >> not go anywhere near either intel_engine_reset() or >> intel_gt_handle_error() when GuC submission is used. The problem is >> what happens if the engine reset fails (which supposedly can only >> happen with broken hardware). In that scenario, there is an >> asynchronous message from GuC to i915 to notify us of the failure. >> The KMD receives that notification and then (eventually) calls >> intel_gt_handle_error() to issue a full GT reset. However, that is >> blocked because the selftest is not expecting it and has vetoed the >> possibility. > > This is where my understanding of the discussion differs. According to > Matthew, the selftest actually proceeds to clear the bits, but the > worker that calls into intel_gt_handle_error() never wakes up. (and > that's probably due to clear_bit() being used instead of > clear_and_wake_up_bit()). Hmm, missed that point. Yeah, sounds like the missing wake_up suffix is what is causing the deadlock. I can't see any other reason why the reset handler would not proceed once the flags are cleared. And it looks like the selftest should timeout out waiting for the request and continue on to clear the bits just fine. > > And my problem with this particular patch is that it adds even more > "if (!guc_submission)" which is already sprinkled all over the place > in the selftests to the point that it becomes difficult to see what > (if anything) the tests are really testing. I agree with this. Fixing the problem at source seems like a better solution than hacking lots of different bits in different tests. > For example igt_reset_nop_engine() from a cursory look looks like it's > doing something but inside the engine loop it becomes clear that the > test doesn't do *anything* except iterate over engines. Same for > igt_reset_engines() in the !TEST_ACTIVE case and for > igt_reset_idle_engine(). For some other tests the reset_count checks > are gone, leaving only a test that we actually do a reset. The nop_engine test is meant to be a no-op. It is testing what happens when you reset an idle engine. That is not something we can do with GuC based engine resets - there are no debug hooks into GuC specifically to trigger an engine reset when there is no hang. The same applies to the !TEST_ACTIVE case (which is igt_reset_idle_engine). Hence those are skipped for GuC. The reset_count tests are still present. They are looking for global resets occurring when they should not. It is the reset_engine_count check that is disabled for GuC. Again, because GuC is handling the reset not i915. GuC tells us when a context is reset, it does not report any specifics about engines. So this is not a count we can maintain when using GuC submission. > > So if possible, as previously mentioned, I think a solution without > adding more of this in the selftests is preferrable. To me the best > option is probably be the one you suggest in your previous email: > Don't wait on the I915_RESET_ENGINE bits with GuC in > intel_gt_handle_error(), (or perhaps extract what's left in a separate > function called from the GuC handler). I don't like the idea of splitting intel_gt_handle_error() apart. It is meant to be the top level reset handler that manages all resets - per engine and full GT (and potentially FLR in the future). Certainly, none of it should be pulled out into GuC specific code. One less than ideal aspect of the current reset support is that 'intel_has_reset_engine()' is ambiguous. With GuC submission, we have per engine reset. It's just not managed by i915. So code that wants to know if engines can be reset individual wants a true response. But code such as intel_gt_handle_error() needs to know *who* is doing that reset. Hence it needs the GuC specific check on top to differentiate. Ideally, there would be separate intel_has_reset_engine() and intel_does_i915_do_engine_reset() queries. Then the reset code itself would not need to query GuC submission. However, that seems like overkill to remove a couple of GuC tests. Maybe it could be done as future work, but it is certainly not in the scope of making this selftest not hang the system. John. > > Thanks, > > Thomas > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-27 20:34 ` John Harrison @ 2021-10-27 20:47 ` Thomas Hellström 0 siblings, 0 replies; 18+ messages in thread From: Thomas Hellström @ 2021-10-27 20:47 UTC (permalink / raw) To: John Harrison, Matthew Brost; +Cc: intel-gfx, dri-devel On 10/27/21 22:34, John Harrison wrote: > On 10/26/2021 23:36, Thomas Hellström wrote: >> Hi, John, >> >> On 10/26/21 21:55, John Harrison wrote: >>> On 10/21/2021 23:23, Thomas Hellström wrote: >>>> On 10/21/21 22:37, Matthew Brost wrote: >>>>> On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >>>>>> Hi, Matthew, >>>>>> >>>>>> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>>>>>> The hangcheck selftest blocks per engine resets by setting magic >>>>>>> bits >>>>>>> in >>>>>>> the reset flags. This is incorrect for GuC submission because if >>>>>>> the >>>>>>> GuC >>>>>>> fails to reset an engine we would like to do a full GT reset. Do no >>>>>>> set >>>>>>> these magic bits when using GuC submission. >>>>>>> >>>>>>> Side note this lockless algorithm with magic bits to block resets >>>>>>> really >>>>>>> should be ripped out. >>>>>>> >>>>>> Lockless algorithm aside, from a quick look at the code in >>>>>> intel_reset.c it appears to me like the interface that falls back >>>>>> to a >>>>>> full GT reset is intel_gt_handle_error() whereas >>>>>> intel_engine_reset() >>>>>> is explicitly intended to not do that, so is there a discrepancy >>>>>> between GuC and non-GuC here? >>>>>> >>>>> With GuC submission when an engine reset fails, we get an engine >>>>> reset >>>>> failure notification which triggers a full GT reset >>>>> (intel_guc_engine_failure_process_msg in intel_guc_submission.c). >>>>> That >>>>> reset is blocking by setting these magic bits. Clearing the bits >>>>> in this >>>>> function doesn't seem to unblock that reset either, the driver >>>>> tries to >>>>> unload with a worker blocked, and results in the blow up. >>>>> Something with >>>>> this lockless algorithm could be wrong as clear of the bit should >>>>> unlblock the reset but it is doesn't. We can look into that but in >>>>> the >>>>> meantime we need to fix this test to be able to fail gracefully >>>>> and not >>>>> crash CI. >>>> >>>> Yeah, for that lockless algorithm if needed, we might want to use a >>>> ww_mutex per engine or something, >>>> but point was that AFAICT at least one of the tests that set those >>>> flags explicitly tested the functionality that no other engines >>>> than the intended one was reset when the intel_engine_reset() >>>> function was used, and then if GuC submission doesn't honor that, >>>> wouldn't a better approach be to make a code comment around >>>> intel_engine_reset() to explain the differences and disable that >>>> particular test for GuC?. Also wouldn't we for example we see a >>>> duplicated full GT reset with GuC if intel_engine_reset() fails as >>>> part of the intel_gt_handle_error() function? >>> Re-reading this thread, I think there is a misunderstanding. >>> >>> The selftests themselves have already been updated to support GuC >>> based engine resets. That is done by submitting a hanging context >>> and letting the GuC detect the hang and issue a reset. There is no >>> mechanism available for i915 to directly issue or request an engine >>> based reset (because i915 does not know what is running on any given >>> engine at any given time, being disconnected from the scheduler). >>> >>> So the tests are already correctly testing per engine resets and do >>> not go anywhere near either intel_engine_reset() or >>> intel_gt_handle_error() when GuC submission is used. The problem is >>> what happens if the engine reset fails (which supposedly can only >>> happen with broken hardware). In that scenario, there is an >>> asynchronous message from GuC to i915 to notify us of the failure. >>> The KMD receives that notification and then (eventually) calls >>> intel_gt_handle_error() to issue a full GT reset. However, that is >>> blocked because the selftest is not expecting it and has vetoed the >>> possibility. >> >> This is where my understanding of the discussion differs. According >> to Matthew, the selftest actually proceeds to clear the bits, but the >> worker that calls into intel_gt_handle_error() never wakes up. (and >> that's probably due to clear_bit() being used instead of >> clear_and_wake_up_bit()). > Hmm, missed that point. Yeah, sounds like the missing wake_up suffix > is what is causing the deadlock. I can't see any other reason why the > reset handler would not proceed once the flags are cleared. And it > looks like the selftest should timeout out waiting for the request and > continue on to clear the bits just fine. > > >> >> And my problem with this particular patch is that it adds even more >> "if (!guc_submission)" which is already sprinkled all over the place >> in the selftests to the point that it becomes difficult to see what >> (if anything) the tests are really testing. > I agree with this. Fixing the problem at source seems like a better > solution than hacking lots of different bits in different tests. > OK, so if we can fix this in intel_gt_handle_error() that'd be great. Thanks, Thomas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-21 20:37 ` Matthew Brost 2021-10-22 6:23 ` Thomas Hellström @ 2021-10-26 8:22 ` Thomas Hellström 1 sibling, 0 replies; 18+ messages in thread From: Thomas Hellström @ 2021-10-26 8:22 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-gfx, dri-devel, john.c.harrison Hi, On 10/21/21 22:37, Matthew Brost wrote: > On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: >> Hi, Matthew, >> >> On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: >>> The hangcheck selftest blocks per engine resets by setting magic bits >>> in >>> the reset flags. This is incorrect for GuC submission because if the >>> GuC >>> fails to reset an engine we would like to do a full GT reset. Do no >>> set >>> these magic bits when using GuC submission. >>> >>> Side note this lockless algorithm with magic bits to block resets >>> really >>> should be ripped out. >>> >> Lockless algorithm aside, from a quick look at the code in >> intel_reset.c it appears to me like the interface that falls back to a >> full GT reset is intel_gt_handle_error() whereas intel_engine_reset() >> is explicitly intended to not do that, so is there a discrepancy >> between GuC and non-GuC here? >> > With GuC submission when an engine reset fails, we get an engine reset > failure notification which triggers a full GT reset > (intel_guc_engine_failure_process_msg in intel_guc_submission.c). That > reset is blocking by setting these magic bits. Clearing the bits in this > function doesn't seem to unblock that reset either, the driver tries to > unload with a worker blocked, and results in the blow up. Something with > this lockless algorithm could be wrong as clear of the bit should > unlblock the reset but it is doesn't. We can look into that but in the > meantime we need to fix this test to be able to fail gracefully and not > crash CI. > > Matt Hmm, OK I think the situation is a bit unfortunate with the selftest hangcheck as the code is sprinkled with "using_guc" to disable anything that manually does per-engine resets or verifies the per-engine reset count, leaving it very difficult to understand what the test actually does except perhaps checking that GuC actually did a reset. A better approach would probably be to disable all tests that doesn't do anything exept iterating through the engines with GuC, and for the other tests, extract what's left to test into GuC specific tests. The bit-locks are obviously there to verify that we don't do concurrent per-engine resets or global resets while a per-engine reset is happening. Even in the GuC case it appears at least the latter is true for this particular self-test, but at the same time the selftest doesn't assume anything is trying to reset concurrently and therefore doesn't use clear_and_wake_up_bit() when releasing the bit-locks. But as much as I want the selftests to start running again, TBH I don't think I can contribute to even more code being conditioned on GuC with an R-B here. Could we disable the per-engine reset tests when GuC is enabled for now or try a clear_and_wake_up_bit() instead. /Thomas >> /Thomas >> >> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>> --- >>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- >>> 1 file changed, 8 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> index 7e2d99dd012d..90a03c60c80c 100644 >>> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >>> @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt >>> *gt, bool active) >>> reset_engine_count = i915_reset_engine_count(global, >>> engine); >>> >>> st_engine_heartbeat_disable(engine); >>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + set_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> count = 0; >>> do { >>> struct i915_request *rq = NULL; >>> @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt >>> *gt, bool active) >>> if (err) >>> break; >>> } while (time_before(jiffies, end_time)); >>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + clear_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> st_engine_heartbeat_enable(engine); >>> pr_info("%s: Completed %lu %s resets\n", >>> engine->name, count, active ? "active" : >>> "idle"); >>> @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt >>> *gt, >>> yield(); /* start all threads before we begin */ >>> >>> st_engine_heartbeat_disable_no_pm(engine); >>> - set_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + set_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> do { >>> struct i915_request *rq = NULL; >>> struct intel_selftest_saved_policy saved; >>> @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt >>> *gt, >>> if (err) >>> break; >>> } while (time_before(jiffies, end_time)); >>> - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); >>> + if (!using_guc) >>> + clear_bit(I915_RESET_ENGINE + id, >- >>>> reset.flags); >>> st_engine_heartbeat_enable_no_pm(engine); >>> >>> pr_info("i915_reset_engine(%s:%s): %lu resets\n", >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest 2021-10-11 23:47 [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest Matthew Brost ` (2 preceding siblings ...) 2021-10-21 6:15 ` [Intel-gfx] [PATCH] " Thomas Hellström @ 2021-10-26 19:48 ` John Harrison 3 siblings, 0 replies; 18+ messages in thread From: John Harrison @ 2021-10-26 19:48 UTC (permalink / raw) To: Matthew Brost, intel-gfx, dri-devel; +Cc: thomas.hellstrom On 10/11/2021 16:47, Matthew Brost wrote: > The hangcheck selftest blocks per engine resets by setting magic bits in > the reset flags. This is incorrect for GuC submission because if the GuC > fails to reset an engine we would like to do a full GT reset. Do no set > these magic bits when using GuC submission. > > Side note this lockless algorithm with magic bits to block resets really > should be ripped out. As a first step, I am seeing a pointless BUILD_BUG but no BUILD_BUG at all for what really needs to be verified. Specifically, in intel_gt_handle_error, inside the engine reset loop, there is: BUILD_BUG_ON(I915_RESET_MODESET >= I915_RESET_ENGINE); Given that the above two values are explicit #defines of '1' and '2'. I'm not seeing any value to this assert. On the other hand, what I am not seeing anywhere is an assert that 'I915_RESET_ENGINE + max_engine_id < I915_WEDGED_ON_INIT'. That being the thing that would actually go horribly wrong if the engine count increased too far. Seems like there should be one of those in intel_engines_init_mmio, using ARRAY_SIZE(intel_engines) as the max id. It looks like 'busy-reset' and 'reset-idle' parts of 'igt_ctx_sseu' in gem/selftests/i915_gem_context.c also mess around with these flags and then try to issue a manual engine reset. Presumably those tests are also going to have issues with GuC submission. The workarounds, mocs and reset selftests also do strange things. Those ones did get updated to support GuC submission by not attempting manual engine resets but using the GuC based hang detection instead. However, it seems like they would also suffer the same deadlock scenario if the GuC based reset were to fail. I'm wondering if the better fix is to remove the use of the I915_RESET_ENGINE flags completely when using GuC submission. So far as I can tell, they are only used (outside of selftest hackery) in intel_gt_handle_error to guard against multiple concurrent resets within i915. Guarding against multiple concurrent resets in GuC is the GuC's job. That leaves GuC based engine reset concurrent with i915 based full GT reset. But that is fine because the full GT reset toasts all engines AND the GuC. So it doesn't matter what GuC might or might not have been doing at the time. The only other issue is multiple concurrent full GT resets, but that is protected against by I915_RESET_BACKOFF. So my thought is to add an 'if(!guc_submission)' wrapper around the set and clear of the reset flags immediately before/after the call to intel_gt_reset_global(). Fixing it there means the selftests can do what they like with the flags without causing problems for GuC submission. It also means being one step closer to removing the dodgy lockless locking completely, at least when using GuC submission. John. > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > --- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > index 7e2d99dd012d..90a03c60c80c 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > @@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active) > reset_engine_count = i915_reset_engine_count(global, engine); > > st_engine_heartbeat_disable(engine); > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + set_bit(I915_RESET_ENGINE + id, >->reset.flags); > count = 0; > do { > struct i915_request *rq = NULL; > @@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active) > if (err) > break; > } while (time_before(jiffies, end_time)); > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > st_engine_heartbeat_enable(engine); > pr_info("%s: Completed %lu %s resets\n", > engine->name, count, active ? "active" : "idle"); > @@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt *gt, > yield(); /* start all threads before we begin */ > > st_engine_heartbeat_disable_no_pm(engine); > - set_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + set_bit(I915_RESET_ENGINE + id, >->reset.flags); > do { > struct i915_request *rq = NULL; > struct intel_selftest_saved_policy saved; > @@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt *gt, > if (err) > break; > } while (time_before(jiffies, end_time)); > - clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > + if (!using_guc) > + clear_bit(I915_RESET_ENGINE + id, >->reset.flags); > st_engine_heartbeat_enable_no_pm(engine); > > pr_info("i915_reset_engine(%s:%s): %lu resets\n", ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-10-27 20:47 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-10-11 23:47 [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest Matthew Brost 2021-10-12 0:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork 2021-10-12 4:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-10-21 6:15 ` [Intel-gfx] [PATCH] " Thomas Hellström 2021-10-21 20:37 ` Matthew Brost 2021-10-22 6:23 ` Thomas Hellström 2021-10-22 17:03 ` Matthew Brost 2021-10-22 18:09 ` John Harrison 2021-10-23 17:46 ` Thomas Hellström 2021-10-23 18:18 ` Matthew Brost 2021-10-23 18:36 ` Thomas Hellström 2021-10-25 17:32 ` John Harrison 2021-10-26 19:55 ` John Harrison 2021-10-27 6:36 ` Thomas Hellström 2021-10-27 20:34 ` John Harrison 2021-10-27 20:47 ` Thomas Hellström 2021-10-26 8:22 ` Thomas Hellström 2021-10-26 19:48 ` John Harrison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox