* [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads
@ 2022-07-26 10:13 Karolina Drobnik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
` (5 more replies)
0 siblings, 6 replies; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-26 10:13 UTC (permalink / raw)
To: igt-dev; +Cc: Tvrtko Ursulin, Chris Wilson
This patch series fixes test_fence_await for failing gem_exec_fence
subtests that inject GPU hangs (await-hang and nb-await-hang). The test
assumed that the error notification happens after a hang is declared,
which would be enough for the next set of fences to be submitted,
making this test pass. But as we use the error-interrupt, we get immediate
reset for the invalid command stream. This means that when the test checks
for active fences, none can be found, leading to the test failure.
To address this problem, the active fences check is only done for valid
workloads. In addition to the fix, the series adds spinning before
usleep() call to coordinate sleep with the start of the request.
v2:
No functional changes, fixed styling issues pointed out by Kamil:
- Moved comment for fence_busy(spin->out_fence) assertion
- Fixed formatting for flags assignment in spin definition
Chris Wilson (2):
tests/gem_exec_fence: Check stored values only for valid workloads
tests/gem_exec_fence: Coordinate sleep with the start of the request
tests/i915/gem_exec_fence.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 20+ messages in thread
* [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
@ 2022-07-26 10:13 ` Karolina Drobnik
2022-07-26 14:27 ` Kamil Konieczny
2022-07-28 16:56 ` Janusz Krzysztofik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request Karolina Drobnik
` (4 subsequent siblings)
5 siblings, 2 replies; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-26 10:13 UTC (permalink / raw)
To: igt-dev; +Cc: Tvrtko Ursulin, Chris Wilson
From: Chris Wilson <chris@chris-wilson.co.uk>
test_fence_await verifies if a fence used to pipeline work signals
correctly. await-hang and nb-await-hang test cases inject GPU hang,
which causes an erroneous state, meaning the fence will be signaled
without execution. The error causes an instant reset of the command
streamer for the hanging workload. This revealed a problem with how
we verify the fence state and results. The test assumes that the
error notification happens after a hang is declared, which takes
longer than submitting the next set of fences, making the test pass
every time. With the immediate reset, this might not happen, so the
assertion fails, as there are no active fences in the GPU hang case.
Move the check for active fence to the path for non-hanging workload,
and verify results only in this scenario.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
---
tests/i915/gem_exec_fence.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
index d46914c2..260aa82c 100644
--- a/tests/i915/gem_exec_fence.c
+++ b/tests/i915/gem_exec_fence.c
@@ -350,18 +350,20 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
/* Long, but not too long to anger preemption disable checks */
usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
- /* Check for invalidly completing the task early */
- igt_assert(fence_busy(spin->out_fence));
- for (int n = 0; n < i; n++)
- igt_assert_eq_u32(out[n], 0);
+ if ((flags & HANG) == 0) {
+ /* Check for invalidly completing the task early */
+ igt_assert(fence_busy(spin->out_fence));
+ for (int n = 0; n < i; n++)
+ igt_assert_eq_u32(out[n], 0);
- if ((flags & HANG) == 0)
igt_spin_end(spin);
+ }
igt_waitchildren();
gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
- while (i--)
+ igt_assert(!fence_busy(spin->out_fence));
+ while ((flags & HANG) == 0 && i--)
igt_assert_eq_u32(out[i], i);
munmap(out, 4096);
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
@ 2022-07-26 10:13 ` Karolina Drobnik
2022-07-26 14:28 ` Kamil Konieczny
2022-07-26 10:54 ` [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2) Patchwork
` (3 subsequent siblings)
5 siblings, 1 reply; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-26 10:13 UTC (permalink / raw)
To: igt-dev; +Cc: Tvrtko Ursulin, Chris Wilson
From: Chris Wilson <chris@chris-wilson.co.uk>
Wait until we know the request is running on the GPU before sleeping
and giving a chance for other fences to run ahead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
---
tests/i915/gem_exec_fence.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
index 260aa82c..7ff7614d 100644
--- a/tests/i915/gem_exec_fence.c
+++ b/tests/i915/gem_exec_fence.c
@@ -324,7 +324,9 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
.ahnd = ahnd,
.ctx = ctx,
.engine = e->flags,
- .flags = IGT_SPIN_FENCE_OUT | spin_hang(flags));
+ .flags = IGT_SPIN_FENCE_OUT |
+ IGT_SPIN_POLL_RUN |
+ spin_hang(flags));
igt_assert(spin->out_fence != -1);
i = 0;
@@ -347,6 +349,7 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
i++;
}
+ igt_spin_busywait_until_started(spin);
/* Long, but not too long to anger preemption disable checks */
usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request Karolina Drobnik
@ 2022-07-26 10:54 ` Patchwork
2022-07-26 11:06 ` Karolina Drobnik
2022-07-28 15:17 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
` (2 subsequent siblings)
5 siblings, 1 reply; 20+ messages in thread
From: Patchwork @ 2022-07-26 10:54 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev
[-- Attachment #1: Type: text/plain, Size: 9274 bytes --]
== Series Details ==
Series: tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
URL : https://patchwork.freedesktop.org/series/106531/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11943 -> IGTPW_7563
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_7563 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_7563, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
Participating hosts (33 -> 38)
------------------------------
Additional (8): fi-kbl-soraka bat-dg2-8 bat-adlm-1 bat-adlp-6 fi-snb-2520m bat-rplp-1 bat-rpls-1 bat-rpls-2
Missing (3): fi-hsw-4770 fi-bdw-samus bat-dg1-5
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_7563:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@slpc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@slpc.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-rpls-1}: NOTRUN -> [INCOMPLETE][2]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-rpls-1/igt@i915_selftest@live@migrate.html
Known issues
------------
Here are the changes found in IGTPW_7563 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_exec_gttfill@basic.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][4] ([i915#6179])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@gem_exec_suspend@basic-s3@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [PASS][7] -> [INCOMPLETE][8] ([i915#2940])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-5557u/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2520m: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@kms_chamelium@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +7 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_vgem@basic-fence-flip:
- fi-snb-2520m: NOTRUN -> [SKIP][13] ([fdo#109271]) +21 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@prime_vgem@basic-fence-flip.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][14] ([i915#4312])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_selftest@live@coherency:
- {bat-dg2-9}: [DMESG-WARN][15] ([i915#5763]) -> [PASS][16] +7 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/bat-dg2-9/igt@i915_selftest@live@coherency.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-dg2-9/igt@i915_selftest@live@coherency.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][17] ([i915#5153] / [i915#6106]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-ehl-2/igt@i915_selftest@live@hangcheck.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-ehl-2/igt@i915_selftest@live@hangcheck.html
#### Warnings ####
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][19] ([i915#5982]) -> [FAIL][20] ([fdo#103375])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4093]: https://gitlab.freedesktop.org/drm/intel/issues/4093
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
[i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
[i915#5950]: https://gitlab.freedesktop.org/drm/intel/issues/5950
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6106]: https://gitlab.freedesktop.org/drm/intel/issues/6106
[i915#6179]: https://gitlab.freedesktop.org/drm/intel/issues/6179
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_6598 -> IGTPW_7563
CI-20190529: 20190529
CI_DRM_11943: fedf33eeec77c1a0dfb243eacdbce82ca0ffa704 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_7563: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
IGT_6598: 97e103419021d0863db527e3f2cf39ccdd132db5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
[-- Attachment #2: Type: text/html, Size: 8579 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
2022-07-26 10:54 ` [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2) Patchwork
@ 2022-07-26 11:06 ` Karolina Drobnik
0 siblings, 0 replies; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-26 11:06 UTC (permalink / raw)
To: igt-dev
On 26.07.2022 12:54, Patchwork wrote:
> *Patch Details*
> *Series:* tests/gem_exec_fence: Fix test_fence_await for hanging
> workloads (rev2)
> *URL:* https://patchwork.freedesktop.org/series/106531/
> <https://patchwork.freedesktop.org/series/106531/>
> *State:* failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html>
>
>
> CI Bug Log - changes from CI_DRM_11943 -> IGTPW_7563
>
>
> Summary
>
> *FAILURE*
>
> Serious unknown changes coming with IGTPW_7563 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in IGTPW_7563, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
>
>
> Participating hosts (33 -> 38)
>
> Additional (8): fi-kbl-soraka bat-dg2-8 bat-adlm-1 bat-adlp-6
> fi-snb-2520m bat-rplp-1 bat-rpls-1 bat-rpls-2
> Missing (3): fi-hsw-4770 fi-bdw-samus bat-dg1-5
>
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in IGTPW_7563:
>
>
> IGT changes
>
>
> Possible regressions
>
> * igt@i915_selftest@live@slpc:
> o fi-kbl-soraka: NOTRUN -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@slpc.html>
Not related to the patch
Thanks,
Karolina
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_selftest@live@migrate:
> o {bat-rpls-1}: NOTRUN -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-rpls-1/igt@i915_selftest@live@migrate.html>
>
>
> Known issues
>
> Here are the changes found in IGTPW_7563 that come from known issues:
>
>
> IGT changes
>
>
> Issues hit
>
> *
>
> igt@gem_exec_gttfill@basic:
>
> o fi-kbl-soraka: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_exec_gttfill@basic.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +8
> similar issues
> *
>
> igt@gem_exec_suspend@basic-s3@smem:
>
> o fi-rkl-11600: NOTRUN -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@gem_exec_suspend@basic-s3@smem.html>
> (i915#6179 <https://gitlab.freedesktop.org/drm/intel/issues/6179>)
> *
>
> igt@gem_huc_copy@huc-copy:
>
> o fi-kbl-soraka: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> i915#2190 <https://gitlab.freedesktop.org/drm/intel/issues/2190>)
> *
>
> igt@gem_lmem_swapping@basic:
>
> o fi-kbl-soraka: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> i915#4613
> <https://gitlab.freedesktop.org/drm/intel/issues/4613>) +3
> similar issues
> *
>
> igt@i915_selftest@live@execlists:
>
> o fi-bdw-gvtdvm: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html>
> -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html>
> (i915#2940 <https://gitlab.freedesktop.org/drm/intel/issues/2940>)
> *
>
> igt@i915_selftest@live@gt_pm:
>
> o fi-kbl-soraka: NOTRUN -> DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html>
> (i915#1886 <https://gitlab.freedesktop.org/drm/intel/issues/1886>)
> *
>
> igt@kms_chamelium@common-hpd-after-suspend:
>
> o fi-bdw-5557u: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-5557u/igt@kms_chamelium@common-hpd-after-suspend.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> fdo#111827 <https://bugs.freedesktop.org/show_bug.cgi?id=111827>)
> *
>
> igt@kms_chamelium@hdmi-crc-fast:
>
> o fi-snb-2520m: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@kms_chamelium@hdmi-crc-fast.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> fdo#111827
> <https://bugs.freedesktop.org/show_bug.cgi?id=111827>) +8
> similar issues
> *
>
> igt@kms_chamelium@hdmi-hpd-fast:
>
> o fi-kbl-soraka: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@kms_chamelium@hdmi-hpd-fast.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
> fdo#111827
> <https://bugs.freedesktop.org/show_bug.cgi?id=111827>) +7
> similar issues
> *
>
> igt@prime_vgem@basic-fence-flip:
>
> o fi-snb-2520m: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@prime_vgem@basic-fence-flip.html>
> (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +21
> similar issues
> *
>
> igt@runner@aborted:
>
> o fi-bdw-gvtdvm: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@runner@aborted.html>
> (i915#4312 <https://gitlab.freedesktop.org/drm/intel/issues/4312>)
>
>
> Possible fixes
>
> *
>
> igt@i915_selftest@live@coherency:
>
> o {bat-dg2-9}: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/bat-dg2-9/igt@i915_selftest@live@coherency.html>
> (i915#5763
> <https://gitlab.freedesktop.org/drm/intel/issues/5763>) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-dg2-9/igt@i915_selftest@live@coherency.html>
> +7 similar issues
> *
>
> igt@i915_selftest@live@hangcheck:
>
> o {fi-ehl-2}: INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-ehl-2/igt@i915_selftest@live@hangcheck.html>
> (i915#5153
> <https://gitlab.freedesktop.org/drm/intel/issues/5153> /
> i915#6106
> <https://gitlab.freedesktop.org/drm/intel/issues/6106>) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-ehl-2/igt@i915_selftest@live@hangcheck.html>
>
>
> Warnings
>
> * igt@i915_suspend@basic-s3-without-i915:
> o fi-rkl-11600: INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html>
> (i915#5982
> <https://gitlab.freedesktop.org/drm/intel/issues/5982>) -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html>
> (fdo#103375 <https://bugs.freedesktop.org/show_bug.cgi?id=103375>)
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
>
> Build changes
>
> * CI: CI-20190529 -> None
> * IGT: IGT_6598 -> IGTPW_7563
>
> CI-20190529: 20190529
> CI_DRM_11943: fedf33eeec77c1a0dfb243eacdbce82ca0ffa704 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGTPW_7563: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
> IGT_6598: 97e103419021d0863db527e3f2cf39ccdd132db5 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
@ 2022-07-26 14:27 ` Kamil Konieczny
2022-07-28 16:56 ` Janusz Krzysztofik
1 sibling, 0 replies; 20+ messages in thread
From: Kamil Konieczny @ 2022-07-26 14:27 UTC (permalink / raw)
To: igt-dev; +Cc: Chris Wilson
Hi Karolina,
On 2022-07-26 at 12:13:11 +0200, Karolina Drobnik wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
>
> test_fence_await verifies if a fence used to pipeline work signals
> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> which causes an erroneous state, meaning the fence will be signaled
> without execution. The error causes an instant reset of the command
> streamer for the hanging workload. This revealed a problem with how
> we verify the fence state and results. The test assumes that the
> error notification happens after a hang is declared, which takes
> longer than submitting the next set of fences, making the test pass
> every time. With the immediate reset, this might not happen, so the
As I understand it, reset can happen only after hang was detected ?
> assertion fails, as there are no active fences in the GPU hang case.
>
> Move the check for active fence to the path for non-hanging workload,
> and verify results only in this scenario.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> ---
> tests/i915/gem_exec_fence.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> index d46914c2..260aa82c 100644
> --- a/tests/i915/gem_exec_fence.c
> +++ b/tests/i915/gem_exec_fence.c
> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
> /* Long, but not too long to anger preemption disable checks */
> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
>
> - /* Check for invalidly completing the task early */
> - igt_assert(fence_busy(spin->out_fence));
I tested this on drm-tip and this assert here did not trigger.
It is not blocker (it can be moved into hang-only block), so
Reviewed-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
Regards,
Kamil
> - for (int n = 0; n < i; n++)
> - igt_assert_eq_u32(out[n], 0);
> + if ((flags & HANG) == 0) {
> + /* Check for invalidly completing the task early */
> + igt_assert(fence_busy(spin->out_fence));
> + for (int n = 0; n < i; n++)
> + igt_assert_eq_u32(out[n], 0);
>
> - if ((flags & HANG) == 0)
> igt_spin_end(spin);
> + }
>
> igt_waitchildren();
>
> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> - while (i--)
> + igt_assert(!fence_busy(spin->out_fence));
> + while ((flags & HANG) == 0 && i--)
> igt_assert_eq_u32(out[i], i);
> munmap(out, 4096);
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request Karolina Drobnik
@ 2022-07-26 14:28 ` Kamil Konieczny
0 siblings, 0 replies; 20+ messages in thread
From: Kamil Konieczny @ 2022-07-26 14:28 UTC (permalink / raw)
To: igt-dev; +Cc: Chris Wilson
On 2022-07-26 at 12:13:12 +0200, Karolina Drobnik wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
>
> Wait until we know the request is running on the GPU before sleeping
> and giving a chance for other fences to run ahead.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
Reviewed-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
--
Kamil
> ---
> tests/i915/gem_exec_fence.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> index 260aa82c..7ff7614d 100644
> --- a/tests/i915/gem_exec_fence.c
> +++ b/tests/i915/gem_exec_fence.c
> @@ -324,7 +324,9 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
> .ahnd = ahnd,
> .ctx = ctx,
> .engine = e->flags,
> - .flags = IGT_SPIN_FENCE_OUT | spin_hang(flags));
> + .flags = IGT_SPIN_FENCE_OUT |
> + IGT_SPIN_POLL_RUN |
> + spin_hang(flags));
> igt_assert(spin->out_fence != -1);
>
> i = 0;
> @@ -347,6 +349,7 @@ static void test_fence_await(int fd, const intel_ctx_t *ctx,
> i++;
> }
>
> + igt_spin_busywait_until_started(spin);
> /* Long, but not too long to anger preemption disable checks */
> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [igt-dev] ✓ Fi.CI.BAT: success for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
` (2 preceding siblings ...)
2022-07-26 10:54 ` [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2) Patchwork
@ 2022-07-28 15:17 ` Patchwork
2022-07-28 21:20 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
[not found] ` <6459819.4vTCxPXJkl@jkrzyszt-mobl1.ger.corp.intel.com>
5 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2022-07-28 15:17 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev
[-- Attachment #1: Type: text/plain, Size: 9030 bytes --]
== Series Details ==
Series: tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
URL : https://patchwork.freedesktop.org/series/106531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11943 -> IGTPW_7563
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
Participating hosts (33 -> 38)
------------------------------
Additional (8): fi-kbl-soraka bat-dg2-8 bat-adlm-1 fi-snb-2520m bat-adlp-6 bat-rplp-1 bat-rpls-1 bat-rpls-2
Missing (3): fi-hsw-4770 fi-bdw-samus bat-dg1-5
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_7563:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-rpls-1}: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-rpls-1/igt@i915_selftest@live@migrate.html
Known issues
------------
Here are the changes found in IGTPW_7563 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_exec_gttfill@basic.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][3] ([i915#6179])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@gem_exec_suspend@basic-s3@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [PASS][6] -> [INCOMPLETE][7] ([i915#2940])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@slpc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#6491])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@i915_selftest@live@slpc.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-5557u/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2520m: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@kms_chamelium@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +7 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-kbl-soraka/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_vgem@basic-fence-flip:
- fi-snb-2520m: NOTRUN -> [SKIP][13] ([fdo#109271]) +21 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-snb-2520m/igt@prime_vgem@basic-fence-flip.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][14] ([i915#4312])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-bdw-gvtdvm/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_selftest@live@coherency:
- {bat-dg2-9}: [DMESG-WARN][15] ([i915#5763]) -> [PASS][16] +7 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/bat-dg2-9/igt@i915_selftest@live@coherency.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/bat-dg2-9/igt@i915_selftest@live@coherency.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][17] ([i915#5153] / [i915#6106]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-ehl-2/igt@i915_selftest@live@hangcheck.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-ehl-2/igt@i915_selftest@live@hangcheck.html
#### Warnings ####
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][19] ([i915#5982]) -> [FAIL][20] ([fdo#103375])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4093]: https://gitlab.freedesktop.org/drm/intel/issues/4093
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
[i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
[i915#5950]: https://gitlab.freedesktop.org/drm/intel/issues/5950
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6106]: https://gitlab.freedesktop.org/drm/intel/issues/6106
[i915#6179]: https://gitlab.freedesktop.org/drm/intel/issues/6179
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6491]: https://gitlab.freedesktop.org/drm/intel/issues/6491
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_6598 -> IGTPW_7563
CI-20190529: 20190529
CI_DRM_11943: fedf33eeec77c1a0dfb243eacdbce82ca0ffa704 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_7563: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
IGT_6598: 97e103419021d0863db527e3f2cf39ccdd132db5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
[-- Attachment #2: Type: text/html, Size: 8315 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
2022-07-26 14:27 ` Kamil Konieczny
@ 2022-07-28 16:56 ` Janusz Krzysztofik
2022-07-29 7:38 ` Karolina Drobnik
1 sibling, 1 reply; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-07-28 16:56 UTC (permalink / raw)
To: igt-dev; +Cc: Chris Wilson, Tvrtko Ursulin
On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
>
> test_fence_await verifies if a fence used to pipeline work signals
> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> which causes an erroneous state, meaning the fence will be signaled
> without execution. The error causes an instant reset of the command
> streamer for the hanging workload. This revealed a problem with how
> we verify the fence state and results. The test assumes that the
> error notification happens after a hang is declared, which takes
> longer than submitting the next set of fences, making the test pass
> every time. With the immediate reset, this might not happen, so the
> assertion fails, as there are no active fences in the GPU hang case.
>
> Move the check for active fence to the path for non-hanging workload,
> and verify results only in this scenario.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> ---
> tests/i915/gem_exec_fence.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> index d46914c2..260aa82c 100644
> --- a/tests/i915/gem_exec_fence.c
> +++ b/tests/i915/gem_exec_fence.c
> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const intel_ctx_t
*ctx,
> /* Long, but not too long to anger preemption disable checks */
> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
>
> - /* Check for invalidly completing the task early */
> - igt_assert(fence_busy(spin->out_fence));
> - for (int n = 0; n < i; n++)
> - igt_assert_eq_u32(out[n], 0);
> + if ((flags & HANG) == 0) {
> + /* Check for invalidly completing the task early */
> + igt_assert(fence_busy(spin->out_fence));
> + for (int n = 0; n < i; n++)
> + igt_assert_eq_u32(out[n], 0);
AFAICU, in the 'hang' variant of the scenario we skip the above asserts
because the spin batch could have already hanged, then its out fence already
signalled and store batches waiting for that signal already executed. If
that's the case, how do this variant of gem_exec_fence test asserts that the
fence actually worked as expected?
>
> - if ((flags & HANG) == 0)
> igt_spin_end(spin);
> + }
>
> igt_waitchildren();
>
> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> - while (i--)
> + igt_assert(!fence_busy(spin->out_fence));
We only check that the out fence of the presumably hanged spin batch no longer
blocks execution of store batches.
> + while ((flags & HANG) == 0 && i--)
Besides, why don't we at least assert successful results of store batches? Do
we expect them not having their job done correctly when completed after the
hang of the spin batch have occurred?
Am I missing something?
Thanks,
Janusz
> igt_assert_eq_u32(out[i], i);
> munmap(out, 4096);
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [igt-dev] ✓ Fi.CI.IGT: success for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
` (3 preceding siblings ...)
2022-07-28 15:17 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
@ 2022-07-28 21:20 ` Patchwork
[not found] ` <6459819.4vTCxPXJkl@jkrzyszt-mobl1.ger.corp.intel.com>
5 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2022-07-28 21:20 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev
[-- Attachment #1: Type: text/plain, Size: 58979 bytes --]
== Series Details ==
Series: tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)
URL : https://patchwork.freedesktop.org/series/106531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11943_full -> IGTPW_7563_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
Participating hosts (13 -> 10)
------------------------------
Missing (3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
------------
Here are the changes found in IGTPW_7563_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@api_intel_bb@crc32:
- shard-tglb: NOTRUN -> [SKIP][1] ([i915#6230])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@api_intel_bb@crc32.html
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#6230])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb8/igt@api_intel_bb@crc32.html
* igt@api_intel_bb@object-noreloc-keep-cache-simple:
- shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271]) +63 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-snb2/igt@api_intel_bb@object-noreloc-keep-cache-simple.html
* igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][4] ([fdo#111827])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@feature_discovery@chamelium.html
- shard-iclb: NOTRUN -> [SKIP][5] ([fdo#111827])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@feature_discovery@chamelium.html
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][6] ([i915#1839])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb5/igt@feature_discovery@display-4x.html
* igt@gem_busy@close-race:
- shard-snb: [PASS][7] -> [TIMEOUT][8] ([i915#5748])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-snb6/igt@gem_busy@close-race.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-snb5/igt@gem_busy@close-race.html
* igt@gem_create@create-massive:
- shard-kbl: NOTRUN -> [DMESG-WARN][9] ([i915#4991])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@gem_create@create-massive.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) +1 similar issue
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb1/igt@gem_exec_balancer@parallel-bb-first.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb8/igt@gem_exec_balancer@parallel-bb-first.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl: [PASS][14] -> [SKIP][15] ([fdo#109271])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl1/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl6/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl4/igt@gem_exec_fair@basic-none-solo@rcs0.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl7/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl1/igt@gem_exec_fair@basic-none@vcs1.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][20] -> [FAIL][21] ([i915#2842]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-glk2/igt@gem_exec_fair@basic-none@vecs0.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk1/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][22] ([i915#2842]) +2 similar issues
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: NOTRUN -> [FAIL][23] ([i915#2842]) +4 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb5/igt@gem_exec_fair@basic-pace@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][24] ([i915#2842])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb4/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglb: NOTRUN -> [SKIP][25] ([fdo#109283])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@gem_exec_params@rsvd2-dirt.html
* igt@gem_exec_suspend@basic-s3@smem:
- shard-apl: [PASS][26] -> [DMESG-WARN][27] ([i915#180]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl3/igt@gem_exec_suspend@basic-s3@smem.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl8/igt@gem_exec_suspend@basic-s3@smem.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-apl: NOTRUN -> [SKIP][28] ([fdo#109271] / [i915#4613])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl4/igt@gem_lmem_swapping@heavy-multi.html
- shard-glk: NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#4613])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk2/igt@gem_lmem_swapping@heavy-multi.html
- shard-iclb: NOTRUN -> [SKIP][30] ([i915#4613])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb6/igt@gem_lmem_swapping@heavy-multi.html
* igt@gem_lmem_swapping@parallel-multi:
- shard-kbl: NOTRUN -> [SKIP][31] ([fdo#109271] / [i915#4613]) +4 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@gem_lmem_swapping@parallel-multi.html
* igt@gem_lmem_swapping@verify:
- shard-tglb: NOTRUN -> [SKIP][32] ([i915#4613]) +1 similar issue
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb7/igt@gem_lmem_swapping@verify.html
* igt@gem_pxp@reject-modify-context-protection-off-3:
- shard-tglb: NOTRUN -> [SKIP][33] ([i915#4270])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@gem_pxp@reject-modify-context-protection-off-3.html
* igt@gem_render_copy@y-tiled-mc-ccs-to-yf-tiled-ccs:
- shard-iclb: NOTRUN -> [SKIP][34] ([i915#768])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@gem_render_copy@y-tiled-mc-ccs-to-yf-tiled-ccs.html
* igt@gem_userptr_blits@unsync-unmap-after-close:
- shard-tglb: NOTRUN -> [SKIP][35] ([i915#3297])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@gem_userptr_blits@unsync-unmap-after-close.html
* igt@gen7_exec_parse@basic-rejected:
- shard-tglb: NOTRUN -> [SKIP][36] ([fdo#109289])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@gen7_exec_parse@basic-rejected.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- shard-tglb: NOTRUN -> [SKIP][37] ([fdo#111644] / [i915#1397] / [i915#2411])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@i915_pm_rpm@dpms-mode-unset-non-lpsp.html
* igt@i915_selftest@live@gt_lrc:
- shard-tglb: NOTRUN -> [DMESG-FAIL][38] ([i915#2373])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- shard-tglb: NOTRUN -> [DMESG-FAIL][39] ([i915#1759])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@i915_selftest@live@gt_pm.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1:
- shard-tglb: [PASS][40] -> [FAIL][41] ([i915#2521])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglb3/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb7/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-tglb: NOTRUN -> [SKIP][42] ([i915#5286]) +1 similar issue
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb5/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
- shard-iclb: NOTRUN -> [SKIP][43] ([i915#5286]) +1 similar issue
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@linear-8bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][44] ([fdo#110725] / [fdo#111614])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_big_fb@linear-8bpp-rotate-270.html
* igt@kms_big_fb@linear-8bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][45] ([fdo#111614]) +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb7/igt@kms_big_fb@linear-8bpp-rotate-90.html
* igt@kms_big_fb@yf-tiled-16bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][46] ([fdo#111615])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@kms_big_fb@yf-tiled-16bpp-rotate-270.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#3886]) +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl7/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
- shard-glk: NOTRUN -> [SKIP][48] ([fdo#109271] / [i915#3886]) +1 similar issue
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][49] ([fdo#111615] / [i915#3689])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb5/igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs.html
* igt@kms_ccs@pipe-b-bad-pixel-format-4_tiled_dg2_rc_ccs_cc:
- shard-tglb: NOTRUN -> [SKIP][50] ([i915#3689] / [i915#6095])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@kms_ccs@pipe-b-bad-pixel-format-4_tiled_dg2_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][51] ([i915#6095])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_mc_ccs.html
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-iclb: NOTRUN -> [SKIP][52] ([fdo#109278] / [i915#3886]) +1 similar issue
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][53] ([i915#3689] / [i915#3886])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-kbl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#3886]) +11 similar issues
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][55] ([i915#3689]) +3 similar issues
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs.html
* igt@kms_ccs@pipe-d-crc-sprite-planes-basic-yf_tiled_ccs:
- shard-apl: NOTRUN -> [SKIP][56] ([fdo#109271]) +47 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl8/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-yf_tiled_ccs.html
* igt@kms_chamelium@vga-frame-dump:
- shard-apl: NOTRUN -> [SKIP][57] ([fdo#109271] / [fdo#111827]) +3 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl8/igt@kms_chamelium@vga-frame-dump.html
- shard-tglb: NOTRUN -> [SKIP][58] ([fdo#109284] / [fdo#111827]) +4 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@kms_chamelium@vga-frame-dump.html
- shard-glk: NOTRUN -> [SKIP][59] ([fdo#109271] / [fdo#111827]) +2 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk5/igt@kms_chamelium@vga-frame-dump.html
- shard-iclb: NOTRUN -> [SKIP][60] ([fdo#109284] / [fdo#111827]) +2 similar issues
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb5/igt@kms_chamelium@vga-frame-dump.html
* igt@kms_color_chamelium@pipe-a-ctm-0-25:
- shard-snb: NOTRUN -> [SKIP][61] ([fdo#109271] / [fdo#111827]) +3 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-snb2/igt@kms_color_chamelium@pipe-a-ctm-0-25.html
* igt@kms_color_chamelium@pipe-a-gamma:
- shard-kbl: NOTRUN -> [SKIP][62] ([fdo#109271] / [fdo#111827]) +21 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_color_chamelium@pipe-a-gamma.html
* igt@kms_content_protection@dp-mst-type-0:
- shard-tglb: NOTRUN -> [SKIP][63] ([i915#3116] / [i915#3299])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@kms_content_protection@dp-mst-type-0.html
- shard-iclb: NOTRUN -> [SKIP][64] ([i915#3116])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_content_protection@dp-mst-type-0.html
* igt@kms_content_protection@legacy:
- shard-kbl: NOTRUN -> [TIMEOUT][65] ([i915#1319])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_content_protection@legacy.html
* igt@kms_content_protection@uevent:
- shard-kbl: NOTRUN -> [FAIL][66] ([i915#2105])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@kms_content_protection@uevent.html
* igt@kms_cursor_crc@cursor-rapid-movement@pipe-c-edp-1-32x10:
- shard-tglb: NOTRUN -> [SKIP][67] ([i915#4462]) +7 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_cursor_crc@cursor-rapid-movement@pipe-c-edp-1-32x10.html
* igt@kms_cursor_crc@cursor-rapid-movement@pipe-d-edp-1-512x170:
- shard-tglb: NOTRUN -> [SKIP][68] ([i915#3359]) +7 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_cursor_crc@cursor-rapid-movement@pipe-d-edp-1-512x170.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-tglb: NOTRUN -> [SKIP][69] ([fdo#109274] / [fdo#111825]) +1 similar issue
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-4tiled:
- shard-tglb: NOTRUN -> [SKIP][70] ([i915#5287])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-4tiled.html
- shard-iclb: NOTRUN -> [SKIP][71] ([i915#5287])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-4tiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [PASS][72] -> [FAIL][73] ([i915#4767])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl4/igt@kms_fbcon_fbt@fbc-suspend.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl4/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@2x-absolute-wf_vblank:
- shard-tglb: NOTRUN -> [SKIP][74] ([fdo#109274] / [fdo#111825] / [i915#3637] / [i915#3966])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@kms_flip@2x-absolute-wf_vblank.html
* igt@kms_flip@2x-nonexisting-fb-interruptible:
- shard-tglb: NOTRUN -> [SKIP][75] ([fdo#109274] / [fdo#111825] / [i915#3637]) +3 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@kms_flip@2x-nonexisting-fb-interruptible.html
* igt@kms_flip@2x-plain-flip-ts-check-interruptible:
- shard-iclb: NOTRUN -> [SKIP][76] ([fdo#109274]) +4 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@kms_flip@2x-plain-flip-ts-check-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-kbl: NOTRUN -> [DMESG-WARN][77] ([i915#180]) +5 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
- shard-tglb: NOTRUN -> [SKIP][78] ([i915#2672])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb2/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling@pipe-a-default-mode:
- shard-iclb: [PASS][79] -> [SKIP][80] ([i915#3555])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling@pipe-a-default-mode.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling@pipe-a-default-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-downscaling@pipe-a-valid-mode:
- shard-iclb: NOTRUN -> [SKIP][81] ([i915#2672]) +7 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-downscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-default-mode:
- shard-iclb: NOTRUN -> [SKIP][82] ([i915#2672] / [i915#3555])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-default-mode.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-iclb: [PASS][83] -> [FAIL][84] ([i915#1888] / [i915#2546])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html
* igt@kms_frontbuffer_tracking@fbcpsr-slowdraw:
- shard-tglb: NOTRUN -> [FAIL][85] ([i915#160]) +2 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb6/igt@kms_frontbuffer_tracking@fbcpsr-slowdraw.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-tglb: NOTRUN -> [SKIP][86] ([fdo#109280] / [fdo#111825]) +8 similar issues
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: NOTRUN -> [SKIP][87] ([fdo#109271]) +27 similar issues
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu.html
- shard-iclb: NOTRUN -> [SKIP][88] ([fdo#109280]) +3 similar issues
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_hdr@bpc-switch@pipe-a-dp-1:
- shard-kbl: [PASS][89] -> [FAIL][90] ([i915#1188])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@kms_hdr@bpc-switch@pipe-a-dp-1.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@kms_hdr@bpc-switch@pipe-a-dp-1.html
* igt@kms_hdr@static-toggle:
- shard-iclb: NOTRUN -> [SKIP][91] ([i915#3555])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_hdr@static-toggle.html
- shard-tglb: NOTRUN -> [SKIP][92] ([i915#3555])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@kms_hdr@static-toggle.html
* igt@kms_lease@multimaster-lease:
- shard-apl: [PASS][93] -> [DMESG-WARN][94] ([i915#62]) +5 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl8/igt@kms_lease@multimaster-lease.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl4/igt@kms_lease@multimaster-lease.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl: NOTRUN -> [FAIL][95] ([fdo#108145] / [i915#265])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-kbl: NOTRUN -> [FAIL][96] ([i915#265]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-d-constant-alpha-min:
- shard-iclb: NOTRUN -> [SKIP][97] ([fdo#109278]) +5 similar issues
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb5/igt@kms_plane_alpha_blend@pipe-d-constant-alpha-min.html
* igt@kms_plane_multiple@atomic-pipe-b-tiling-4:
- shard-tglb: NOTRUN -> [SKIP][98] ([i915#5288])
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb6/igt@kms_plane_multiple@atomic-pipe-b-tiling-4.html
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: [PASS][99] -> [FAIL][100] ([i915#1888])
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-glk2/igt@kms_plane_multiple@atomic-pipe-c-tiling-x.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk2/igt@kms_plane_multiple@atomic-pipe-c-tiling-x.html
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-a-edp-1:
- shard-iclb: [PASS][101] -> [SKIP][102] ([i915#5176]) +2 similar issues
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb7/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-a-edp-1.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb2/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-a-edp-1.html
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-25@pipe-c-edp-1:
- shard-tglb: NOTRUN -> [SKIP][103] ([i915#5235]) +3 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb7/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-25@pipe-c-edp-1.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1:
- shard-iclb: [PASS][104] -> [SKIP][105] ([i915#5235]) +2 similar issues
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb1/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb2/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html
* igt@kms_psr2_su@page_flip-p010:
- shard-tglb: NOTRUN -> [SKIP][106] ([i915#1911])
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@kms_psr2_su@page_flip-p010.html
- shard-kbl: NOTRUN -> [SKIP][107] ([fdo#109271] / [i915#658]) +2 similar issues
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_psr2_su@page_flip-p010.html
* igt@kms_psr@psr2_dpms:
- shard-iclb: [PASS][108] -> [SKIP][109] ([fdo#109441])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb2/igt@kms_psr@psr2_dpms.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_psr@psr2_dpms.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: NOTRUN -> [SKIP][110] ([fdo#109441])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_psr@psr2_suspend:
- shard-tglb: NOTRUN -> [FAIL][111] ([i915#132] / [i915#3467]) +1 similar issue
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@kms_psr@psr2_suspend.html
* igt@kms_psr_stress_test@flip-primary-invalidate-overlay:
- shard-tglb: [PASS][112] -> [SKIP][113] ([i915#5519])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglb8/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb7/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
* igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0:
- shard-tglb: NOTRUN -> [SKIP][114] ([fdo#111615] / [i915#5289])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb8/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl: [PASS][115] -> [DMESG-WARN][116] ([i915#180])
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl6/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
* igt@kms_writeback@writeback-check-output:
- shard-apl: NOTRUN -> [SKIP][117] ([fdo#109271] / [i915#2437])
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl3/igt@kms_writeback@writeback-check-output.html
- shard-tglb: NOTRUN -> [SKIP][118] ([i915#2437])
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb6/igt@kms_writeback@writeback-check-output.html
- shard-glk: NOTRUN -> [SKIP][119] ([fdo#109271] / [i915#2437])
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk3/igt@kms_writeback@writeback-check-output.html
- shard-iclb: NOTRUN -> [SKIP][120] ([i915#2437])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb3/igt@kms_writeback@writeback-check-output.html
- shard-kbl: NOTRUN -> [SKIP][121] ([fdo#109271] / [i915#2437])
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_writeback@writeback-check-output.html
* igt@nouveau_crc@pipe-d-source-outp-complete:
- shard-tglb: NOTRUN -> [SKIP][122] ([i915#2530])
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@nouveau_crc@pipe-d-source-outp-complete.html
* igt@prime_nv_pcopy@test2:
- shard-kbl: NOTRUN -> [SKIP][123] ([fdo#109271]) +272 similar issues
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@prime_nv_pcopy@test2.html
- shard-tglb: NOTRUN -> [SKIP][124] ([fdo#109291])
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@prime_nv_pcopy@test2.html
* igt@sysfs_clients@recycle-many:
- shard-apl: NOTRUN -> [SKIP][125] ([fdo#109271] / [i915#2994])
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl8/igt@sysfs_clients@recycle-many.html
- shard-tglb: NOTRUN -> [SKIP][126] ([i915#2994])
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@sysfs_clients@recycle-many.html
- shard-glk: NOTRUN -> [SKIP][127] ([fdo#109271] / [i915#2994])
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk3/igt@sysfs_clients@recycle-many.html
- shard-iclb: NOTRUN -> [SKIP][128] ([i915#2994])
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb5/igt@sysfs_clients@recycle-many.html
- shard-kbl: NOTRUN -> [SKIP][129] ([fdo#109271] / [i915#2994])
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@sysfs_clients@recycle-many.html
#### Possible fixes ####
* igt@fbdev@unaligned-write:
- {shard-rkl}: [SKIP][130] ([i915#2582]) -> [PASS][131]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-2/igt@fbdev@unaligned-write.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-4/igt@fbdev@unaligned-write.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][132] ([i915#6268]) -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglu-3/igt@gem_ctx_exec@basic-nohangcheck.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglu-3/igt@gem_ctx_exec@basic-nohangcheck.html
* igt@gem_eio@unwedge-stress:
- {shard-dg1}: [FAIL][134] ([i915#5784]) -> [PASS][135]
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-dg1-12/igt@gem_eio@unwedge-stress.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-dg1-19/igt@gem_eio@unwedge-stress.html
- {shard-tglu}: [TIMEOUT][136] ([i915#3063]) -> [PASS][137]
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglu-2/igt@gem_eio@unwedge-stress.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglu-1/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}: [SKIP][138] ([i915#6247]) -> [PASS][139]
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@gem_exec_endless@dispatch@bcs0.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-1/igt@gem_exec_endless@dispatch@bcs0.html
* igt@gem_exec_endless@dispatch@vecs0:
- {shard-tglu}: [INCOMPLETE][140] ([i915#3778]) -> [PASS][141]
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglu-8/igt@gem_exec_endless@dispatch@vecs0.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglu-8/igt@gem_exec_endless@dispatch@vecs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: [FAIL][142] ([i915#2846]) -> [PASS][143]
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@gem_exec_fair@basic-deadline.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-tglu}: [FAIL][144] ([i915#2842]) -> [PASS][145] +1 similar issue
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglu-4/igt@gem_exec_fair@basic-none-share@rcs0.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglu-5/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: [FAIL][146] ([i915#2842]) -> [PASS][147] +2 similar issues
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-glk2/igt@gem_exec_fair@basic-pace@rcs0.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk9/igt@gem_exec_fair@basic-pace@rcs0.html
* igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}: [SKIP][148] ([i915#3281]) -> [PASS][149] +5 similar issues
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-2/igt@gem_exec_reloc@basic-write-read-noreloc.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-5/igt@gem_exec_reloc@basic-write-read-noreloc.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [SKIP][150] ([i915#2190]) -> [PASS][151]
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglb7/igt@gem_huc_copy@huc-copy.html
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb3/igt@gem_huc_copy@huc-copy.html
* igt@gem_set_tiling_vs_pwrite:
- {shard-rkl}: [SKIP][152] ([i915#3282]) -> [PASS][153] +3 similar issues
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-6/igt@gem_set_tiling_vs_pwrite.html
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-5/igt@gem_set_tiling_vs_pwrite.html
* igt@gem_softpin@evict-single-offset:
- {shard-rkl}: [FAIL][154] ([i915#4171]) -> [PASS][155]
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@gem_softpin@evict-single-offset.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@gem_softpin@evict-single-offset.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [DMESG-WARN][156] ([i915#180]) -> [PASS][157] +9 similar issues
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@gem_workarounds@suspend-resume-fd.html
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@gem_workarounds@suspend-resume-fd.html
* igt@gen9_exec_parse@cmd-crossing-page:
- {shard-rkl}: [SKIP][158] ([i915#2527]) -> [PASS][159]
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-2/igt@gen9_exec_parse@cmd-crossing-page.html
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-5/igt@gen9_exec_parse@cmd-crossing-page.html
* igt@i915_hangman@engine-engine-error@bcs0:
- {shard-rkl}: [SKIP][160] ([i915#6258]) -> [PASS][161] +1 similar issue
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@i915_hangman@engine-engine-error@bcs0.html
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-2/igt@i915_hangman@engine-engine-error@bcs0.html
* igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [FAIL][162] ([i915#454]) -> [PASS][163]
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb5/igt@i915_pm_dc@dc6-dpms.html
- {shard-rkl}: [SKIP][164] ([i915#3361]) -> [PASS][165]
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@i915_pm_dc@dc6-dpms.html
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-1/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-apl: [WARN][166] ([i915#6405]) -> [PASS][167]
[166]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl8/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html
[167]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl3/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html
- shard-glk: [WARN][168] ([i915#6405]) -> [PASS][169]
[168]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-glk5/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html
[169]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk5/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html
* igt@i915_suspend@debugfs-reader:
- shard-kbl: [INCOMPLETE][170] ([i915#3614] / [i915#4939]) -> [PASS][171]
[170]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl4/igt@i915_suspend@debugfs-reader.html
[171]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@i915_suspend@debugfs-reader.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-tglb: [FAIL][172] ([i915#2346]) -> [PASS][173] +1 similar issue
[172]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-tglb2/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html
[173]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- {shard-rkl}: [SKIP][174] ([fdo#111314] / [i915#4098] / [i915#4369]) -> [PASS][175] +1 similar issue
[174]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-1/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled.html
[175]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled.html
* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-apl: [DMESG-WARN][176] ([i915#180]) -> [PASS][177]
[176]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl4/igt@kms_flip@flip-vs-suspend@a-dp1.html
[177]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl4/igt@kms_flip@flip-vs-suspend@a-dp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling@pipe-a-valid-mode:
- shard-glk: [DMESG-FAIL][178] ([i915#118] / [i915#1888]) -> [PASS][179]
[178]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-glk9/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling@pipe-a-valid-mode.html
[179]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-glk2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling@pipe-a-valid-mode.html
* igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary:
- {shard-rkl}: [SKIP][180] ([i915#1849] / [i915#4098]) -> [PASS][181] +4 similar issues
[180]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary.html
[181]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary.html
* igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
- shard-kbl: [FAIL][182] ([i915#1188]) -> [PASS][183]
[182]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl1/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html
[183]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl7/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
- {shard-rkl}: [SKIP][184] ([i915#1849] / [i915#3546] / [i915#4098]) -> [PASS][185]
[184]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html
[185]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- {shard-rkl}: [SKIP][186] ([i915#1849] / [i915#3546] / [i915#4070] / [i915#4098]) -> [PASS][187]
[186]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-1/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
[187]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_psr@cursor_render:
- {shard-rkl}: [SKIP][188] ([i915#1072]) -> [PASS][189]
[188]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-1/igt@kms_psr@cursor_render.html
[189]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_psr@cursor_render.html
* igt@kms_psr@psr2_sprite_render:
- shard-iclb: [SKIP][190] ([fdo#109441]) -> [PASS][191]
[190]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb6/igt@kms_psr@psr2_sprite_render.html
[191]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb2/igt@kms_psr@psr2_sprite_render.html
* igt@kms_universal_plane@universal-plane-gen9-features-pipe-b:
- {shard-rkl}: [SKIP][192] ([i915#1845] / [i915#4070] / [i915#4098]) -> [PASS][193]
[192]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-2/igt@kms_universal_plane@universal-plane-gen9-features-pipe-b.html
[193]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_universal_plane@universal-plane-gen9-features-pipe-b.html
* igt@kms_vblank@pipe-b-wait-forked-hang:
- {shard-rkl}: [SKIP][194] ([i915#1845] / [i915#4098]) -> [PASS][195] +12 similar issues
[194]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-5/igt@kms_vblank@pipe-b-wait-forked-hang.html
[195]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-6/igt@kms_vblank@pipe-b-wait-forked-hang.html
* igt@perf@gen8-unprivileged-single-ctx-counters:
- {shard-rkl}: [SKIP][196] ([i915#2436]) -> [PASS][197]
[196]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-rkl-1/igt@perf@gen8-unprivileged-single-ctx-counters.html
[197]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-rkl-5/igt@perf@gen8-unprivileged-single-ctx-counters.html
#### Warnings ####
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: [FAIL][198] ([i915#2842]) -> [FAIL][199] ([i915#2852])
[198]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb3/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[199]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb7/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@i915_pm_dc@dc9-dpms:
- shard-apl: [FAIL][200] ([i915#4275]) -> [SKIP][201] ([fdo#109271])
[200]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-apl7/igt@i915_pm_dc@dc9-dpms.html
[201]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-apl6/igt@i915_pm_dc@dc9-dpms.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-iclb: [SKIP][202] ([i915#2920]) -> [SKIP][203] ([fdo#111068] / [i915#658])
[202]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
[203]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb4/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb:
- shard-iclb: [SKIP][204] ([i915#658]) -> [SKIP][205] ([i915#2920]) +1 similar issue
[204]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb3/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html
[205]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html
* igt@kms_psr2_su@page_flip-nv12:
- shard-iclb: [FAIL][206] ([i915#5939]) -> [SKIP][207] ([fdo#109642] / [fdo#111068] / [i915#658])
[206]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
[207]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-iclb5/igt@kms_psr2_su@page_flip-nv12.html
* igt@runner@aborted:
- shard-kbl: ([FAIL][208], [FAIL][209], [FAIL][210], [FAIL][211], [FAIL][212], [FAIL][213], [FAIL][214], [FAIL][215], [FAIL][216], [FAIL][217], [FAIL][218], [FAIL][219]) ([fdo#109271] / [i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][220], [FAIL][221], [FAIL][222], [FAIL][223], [FAIL][224], [FAIL][225], [FAIL][226]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257])
[208]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl6/igt@runner@aborted.html
[209]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl6/igt@runner@aborted.html
[210]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@runner@aborted.html
[211]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl4/igt@runner@aborted.html
[212]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl6/igt@runner@aborted.html
[213]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl6/igt@runner@aborted.html
[214]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl1/igt@runner@aborted.html
[215]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@runner@aborted.html
[216]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl1/igt@runner@aborted.html
[217]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@runner@aborted.html
[218]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@runner@aborted.html
[219]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11943/shard-kbl7/igt@runner@aborted.html
[220]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@runner@aborted.html
[221]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl1/igt@runner@aborted.html
[222]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@runner@aborted.html
[223]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@runner@aborted.html
[224]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@runner@aborted.html
[225]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@runner@aborted.html
[226]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/shard-kbl4/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[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#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
[fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312
[fdo#109313]: https://bugs.freedesktop.org/show_bug.cgi?id=109313
[fdo#109314]: https://bugs.freedesktop.org/show_bug.cgi?id=109314
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110254]: https://bugs.freedesktop.org/show_bug.cgi?id=110254
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#110725]: https://bugs.freedesktop.org/show_bug.cgi?id=110725
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
[fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
[i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[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#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#160]: https://gitlab.freedesktop.org/drm/intel/issues/160
[i915#1755]: https://gitlab.freedesktop.org/drm/intel/issues/1755
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1911]: https://gitlab.freedesktop.org/drm/intel/issues/1911
[i915#2105]: https://gitlab.freedesktop.org/drm/intel/issues/2105
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2410]: https://gitlab.freedesktop.org/drm/intel/issues/2410
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2436]: https://gitlab.freedesktop.org/drm/intel/issues/2436
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
[i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2705]: https://gitlab.freedesktop.org/drm/intel/issues/2705
[i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2846]: https://gitlab.freedesktop.org/drm/intel/issues/2846
[i915#2852]: https://gitlab.freedesktop.org/drm/intel/issues/2852
[i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
[i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
[i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
[i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
[i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
[i915#3323]: https://gitlab.freedesktop.org/drm/intel/issues/3323
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3361]: https://gitlab.freedesktop.org/drm/intel/issues/3361
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3467]: https://gitlab.freedesktop.org/drm/intel/issues/3467
[i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469
[i915#3528]: https://gitlab.freedesktop.org/drm/intel/issues/3528
[i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
[i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
[i915#3614]: https://gitlab.freedesktop.org/drm/intel/issues/3614
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
[i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742
[i915#3778]: https://gitlab.freedesktop.org/drm/intel/issues/3778
[i915#3828]: https://gitlab.freedesktop.org/drm/intel/issues/3828
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#3966]: https://gitlab.freedesktop.org/drm/intel/issues/3966
[i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
[i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989
[i915#4036]: https://gitlab.freedesktop.org/drm/intel/issues/4036
[i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4171]: https://gitlab.freedesktop.org/drm/intel/issues/4171
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4275]: https://gitlab.freedesktop.org/drm/intel/issues/4275
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4349]: https://gitlab.freedesktop.org/drm/intel/issues/4349
[i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
[i915#4462]: https://gitlab.freedesktop.org/drm/intel/issues/4462
[i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
[i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#4565]: https://gitlab.freedesktop.org/drm/intel/issues/4565
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4767]: https://gitlab.freedesktop.org/drm/intel/issues/4767
[i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
[i915#4833]: https://gitlab.freedesktop.org/drm/intel/issues/4833
[i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
[i915#4853]: https://gitlab.freedesktop.org/drm/intel/issues/4853
[i915#4854]: https://gitlab.freedesktop.org/drm/intel/issues/4854
[i915#4859]: https://gitlab.freedesktop.org/drm/intel/issues/4859
[i915#4860]: https://gitlab.freedesktop.org/drm/intel/issues/4860
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#4879]: https://gitlab.freedesktop.org/drm/intel/issues/4879
[i915#4881]: https://gitlab.freedesktop.org/drm/intel/issues/4881
[i915#4883]: https://gitlab.freedesktop.org/drm/intel/issues/4883
[i915#4885]: https://gitlab.freedesktop.org/drm/intel/issues/4885
[i915#4893]: https://gitlab.freedesktop.org/drm/intel/issues/4893
[i915#4904]: https://gitlab.freedesktop.org/drm/intel/issues/4904
[i915#4939]: https://gitlab.freedesktop.org/drm/intel/issues/4939
[i915#4958]: https://gitlab.freedesktop.org/drm/intel/issues/4958
[i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
[i915#5030]: https://gitlab.freedesktop.org/drm/intel/issues/5030
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#5287]: https://gitlab.freedesktop.org/drm/intel/issues/5287
[i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288
[i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
[i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
[i915#5327]: https://gitlab.freedesktop.org/drm/intel/issues/5327
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461
[i915#5519]: https://gitlab.freedesktop.org/drm/intel/issues/5519
[i915#5563]: https://gitlab.freedesktop.org/drm/intel/issues/5563
[i915#5748]: https://gitlab.freedesktop.org/drm/intel/issues/5748
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#5939]: https://gitlab.freedesktop.org/drm/intel/issues/5939
[i915#6011]: https://gitlab.freedesktop.org/drm/intel/issues/6011
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#6117]: https://gitlab.freedesktop.org/drm/intel/issues/6117
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#6227]: https://gitlab.freedesktop.org/drm/intel/issues/6227
[i915#6230]: https://gitlab.freedesktop.org/drm/intel/issues/6230
[i915#6247]: https://gitlab.freedesktop.org/drm/intel/issues/6247
[i915#6248]: https://gitlab.freedesktop.org/drm/intel/issues/6248
[i915#6258]: https://gitlab.freedesktop.org/drm/intel/issues/6258
[i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
[i915#6335]: https://gitlab.freedesktop.org/drm/intel/issues/6335
[i915#6344]: https://gitlab.freedesktop.org/drm/intel/issues/6344
[i915#6355]: https://gitlab.freedesktop.org/drm/intel/issues/6355
[i915#6405]: https://gitlab.freedesktop.org/drm/intel/issues/6405
[i915#6433]: https://gitlab.freedesktop.org/drm/intel/issues/6433
[i915#6474]: https://gitlab.freedesktop.org/drm/intel/issues/6474
[i915#6496]: https://gitlab.freedesktop.org/drm/intel/issues/6496
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#768]: https://gitlab.freedesktop.org/drm/intel/issues/768
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_6598 -> IGTPW_7563
* Piglit: piglit_4509 -> None
CI-20190529: 20190529
CI_DRM_11943: fedf33eeec77c1a0dfb243eacdbce82ca0ffa704 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_7563: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
IGT_6598: 97e103419021d0863db527e3f2cf39ccdd132db5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7563/index.html
[-- Attachment #2: Type: text/html, Size: 65658 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-28 16:56 ` Janusz Krzysztofik
@ 2022-07-29 7:38 ` Karolina Drobnik
2022-07-29 8:24 ` Janusz Krzysztofik
0 siblings, 1 reply; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-29 7:38 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi Janusz,
Thanks a lot for taking a look at the patch.
On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> test_fence_await verifies if a fence used to pipeline work signals
>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
>> which causes an erroneous state, meaning the fence will be signaled
>> without execution. The error causes an instant reset of the command
>> streamer for the hanging workload. This revealed a problem with how
>> we verify the fence state and results. The test assumes that the
>> error notification happens after a hang is declared, which takes
>> longer than submitting the next set of fences, making the test pass
>> every time. With the immediate reset, this might not happen, so the
>> assertion fails, as there are no active fences in the GPU hang case.
>>
>> Move the check for active fence to the path for non-hanging workload,
>> and verify results only in this scenario.
>>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
>> ---
>> tests/i915/gem_exec_fence.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
>> index d46914c2..260aa82c 100644
>> --- a/tests/i915/gem_exec_fence.c
>> +++ b/tests/i915/gem_exec_fence.c
>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const intel_ctx_t
> *ctx,
>> /* Long, but not too long to anger preemption disable checks */
>> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
>>
>> - /* Check for invalidly completing the task early */
>> - igt_assert(fence_busy(spin->out_fence));
>> - for (int n = 0; n < i; n++)
>> - igt_assert_eq_u32(out[n], 0);
>> + if ((flags & HANG) == 0) {
>> + /* Check for invalidly completing the task early */
>> + igt_assert(fence_busy(spin->out_fence));
>> + for (int n = 0; n < i; n++)
>> + igt_assert_eq_u32(out[n], 0);
>
> AFAICU, in the 'hang' variant of the scenario we skip the above asserts
> because the spin batch could have already hanged, then its out fence already
> signalled and store batches waiting for that signal already executed. If
> that's the case, how do this variant of gem_exec_fence test asserts that the
> fence actually worked as expected?
With this change, yes, we would skip them. Still, the store batches
wouldn't be executed, as we reset the CS on hang as a part of the error
handling. For valid jobs, we expect to (1) see an active fence at the
beginning of the request, (2) get a signaled fence after the wait, (3)
store out[i] == i. With a hang, (1) and (3) would be false.
In this particular loop, we could have garbage here with hang, not 0s
(although, from my tests it looks like they are zeroed, but maybe I got
lucky)
>>
>> - if ((flags & HANG) == 0)
>> igt_spin_end(spin);
>> + }
>>
>> igt_waitchildren();
>>
>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
>> - while (i--)
>> + igt_assert(!fence_busy(spin->out_fence));
>
> We only check that the out fence of the presumably hanged spin batch no longer
> blocks execution of store batches.
This check applies to all workloads, all of them should be done with
work at this point
>> + while ((flags & HANG) == 0 && i--)
>
> Besides, why don't we at least assert successful results of store batches? Do
> we expect them not having their job done correctly when completed after the
> hang of the spin batch have occurred?
We don't expect them to store anything meaningful, because we get a
reset. So, this check only applies to well-behaved jobs.
All the best,
Karolina
> Am I missing something?
>
> Thanks,
> Janusz
>
>
>> igt_assert_eq_u32(out[i], i);
>> munmap(out, 4096);
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-29 7:38 ` Karolina Drobnik
@ 2022-07-29 8:24 ` Janusz Krzysztofik
2022-07-29 11:32 ` Karolina Drobnik
0 siblings, 1 reply; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-07-29 8:24 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi Karolina,
On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
> Hi Janusz,
>
> Thanks a lot for taking a look at the patch.
>
> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> > On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> >> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>
> >> test_fence_await verifies if a fence used to pipeline work signals
> >> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> >> which causes an erroneous state, meaning the fence will be signaled
> >> without execution. The error causes an instant reset of the command
> >> streamer for the hanging workload. This revealed a problem with how
> >> we verify the fence state and results. The test assumes that the
> >> error notification happens after a hang is declared, which takes
> >> longer than submitting the next set of fences, making the test pass
> >> every time. With the immediate reset, this might not happen, so the
> >> assertion fails, as there are no active fences in the GPU hang case.
> >>
> >> Move the check for active fence to the path for non-hanging workload,
> >> and verify results only in this scenario.
> >>
> >> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> >> ---
> >> tests/i915/gem_exec_fence.c | 14 ++++++++------
> >> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> >> index d46914c2..260aa82c 100644
> >> --- a/tests/i915/gem_exec_fence.c
> >> +++ b/tests/i915/gem_exec_fence.c
> >> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
intel_ctx_t
> > *ctx,
> >> /* Long, but not too long to anger preemption disable checks */
> >> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
> >>
> >> - /* Check for invalidly completing the task early */
> >> - igt_assert(fence_busy(spin->out_fence));
> >> - for (int n = 0; n < i; n++)
> >> - igt_assert_eq_u32(out[n], 0);
> >> + if ((flags & HANG) == 0) {
> >> + /* Check for invalidly completing the task early */
> >> + igt_assert(fence_busy(spin->out_fence));
> >> + for (int n = 0; n < i; n++)
> >> + igt_assert_eq_u32(out[n], 0);
> >
> > AFAICU, in the 'hang' variant of the scenario we skip the above asserts
> > because the spin batch could have already hanged, then its out fence
already
> > signalled and store batches waiting for that signal already executed. If
> > that's the case, how do this variant of gem_exec_fence test asserts that
the
> > fence actually worked as expected?
>
> With this change, yes, we would skip them. Still, the store batches
> wouldn't be executed, as we reset the CS on hang as a part of the error
> handling. For valid jobs, we expect to (1) see an active fence at the
> beginning of the request, (2) get a signaled fence after the wait, (3)
> store out[i] == i. With a hang, (1) and (3) would be false.
>
> In this particular loop, we could have garbage here with hang, not 0s
> (although, from my tests it looks like they are zeroed, but maybe I got
> lucky)
OK, so I missed the fact that the store batches won't be executed at all due
to reset of the whole command stream that also kills those batches. But my
question is still valid: as soon as we omit those checks as not valid from
*await-hang variants, how do those variants still exercise fencing? IOW, how
are those variants supposed to ever fail should something be wrong with i915
implementation of fencing specifically?
>
> >>
> >> - if ((flags & HANG) == 0)
> >> igt_spin_end(spin);
> >> + }
> >>
> >> igt_waitchildren();
> >>
> >> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> >> - while (i--)
> >> + igt_assert(!fence_busy(spin->out_fence));
> >
> > We only check that the out fence of the presumably hanged spin batch no
longer
> > blocks execution of store batches.
>
> This check applies to all workloads, all of them should be done with
> work at this point
OK, but since that's the only explicit assert in the *-hang processing path,
does it tell us anything about fencing working or not? I think it doesn't,
and as long as I'm not wrong, I think such scenarios hardly belong to
gem_exec_fence. Otherwise, I think we should at least add descriptions of
those subtests, providing some information on what is actually exercised.
Thanks,
Janusz
>
> >> + while ((flags & HANG) == 0 && i--)
> >
> > Besides, why don't we at least assert successful results of store batches?
Do
> > we expect them not having their job done correctly when completed after
the
> > hang of the spin batch have occurred?
>
> We don't expect them to store anything meaningful, because we get a
> reset. So, this check only applies to well-behaved jobs.
>
> All the best,
> Karolina
>
> > Am I missing something?
> >
> > Thanks,
> > Janusz
> >
> >
> >> igt_assert_eq_u32(out[i], i);
> >> munmap(out, 4096);
> >>
> >>
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-29 8:24 ` Janusz Krzysztofik
@ 2022-07-29 11:32 ` Karolina Drobnik
2022-07-29 15:23 ` Janusz Krzysztofik
0 siblings, 1 reply; 20+ messages in thread
From: Karolina Drobnik @ 2022-07-29 11:32 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi Janusz,
On 29.07.2022 10:24, Janusz Krzysztofik wrote:
> Hi Karolina,
>
> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
>> Hi Janusz,
>>
>> Thanks a lot for taking a look at the patch.
>>
>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>>>
>>>> test_fence_await verifies if a fence used to pipeline work signals
>>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
>>>> which causes an erroneous state, meaning the fence will be signaled
>>>> without execution. The error causes an instant reset of the command
>>>> streamer for the hanging workload. This revealed a problem with how
>>>> we verify the fence state and results. The test assumes that the
>>>> error notification happens after a hang is declared, which takes
>>>> longer than submitting the next set of fences, making the test pass
>>>> every time. With the immediate reset, this might not happen, so the
>>>> assertion fails, as there are no active fences in the GPU hang case.
>>>>
>>>> Move the check for active fence to the path for non-hanging workload,
>>>> and verify results only in this scenario.
>>>>
>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
>>>> ---
>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
>>>> index d46914c2..260aa82c 100644
>>>> --- a/tests/i915/gem_exec_fence.c
>>>> +++ b/tests/i915/gem_exec_fence.c
>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
> intel_ctx_t
>>> *ctx,
>>>> /* Long, but not too long to anger preemption disable checks */
>>>> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
>>>>
>>>> - /* Check for invalidly completing the task early */
>>>> - igt_assert(fence_busy(spin->out_fence));
>>>> - for (int n = 0; n < i; n++)
>>>> - igt_assert_eq_u32(out[n], 0);
>>>> + if ((flags & HANG) == 0) {
>>>> + /* Check for invalidly completing the task early */
>>>> + igt_assert(fence_busy(spin->out_fence));
>>>> + for (int n = 0; n < i; n++)
>>>> + igt_assert_eq_u32(out[n], 0);
>>>
>>> AFAICU, in the 'hang' variant of the scenario we skip the above asserts
>>> because the spin batch could have already hanged, then its out fence
> already
>>> signalled and store batches waiting for that signal already executed. If
>>> that's the case, how do this variant of gem_exec_fence test asserts that
> the
>>> fence actually worked as expected?
>>
>> With this change, yes, we would skip them. Still, the store batches
>> wouldn't be executed, as we reset the CS on hang as a part of the error
>> handling. For valid jobs, we expect to (1) see an active fence at the
>> beginning of the request, (2) get a signaled fence after the wait, (3)
>> store out[i] == i. With a hang, (1) and (3) would be false.
>>
>> In this particular loop, we could have garbage here with hang, not 0s
>> (although, from my tests it looks like they are zeroed, but maybe I got
>> lucky)
>
> OK, so I missed the fact that the store batches won't be executed at all due
> to reset of the whole command stream that also kills those batches. But my
> question is still valid: as soon as we omit those checks as not valid from
> *await-hang variants, how do those variants still exercise fencing? IOW, how
> are those variants supposed to ever fail should something be wrong with i915
> implementation of fencing specifically?
They would fail in the case where a hang happened but the fence is still
active, so it's this last assert you're referring to.
>>
>>>>
>>>> - if ((flags & HANG) == 0)
>>>> igt_spin_end(spin);
>>>> + }
>>>>
>>>> igt_waitchildren();
>>>>
>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
>>>> - while (i--)
>>>> + igt_assert(!fence_busy(spin->out_fence));
>>>
>>> We only check that the out fence of the presumably hanged spin batch no
> longer
>>> blocks execution of store batches.
>>
>> This check applies to all workloads, all of them should be done with
>> work at this point
>
> OK, but since that's the only explicit assert in the *-hang processing path,
> does it tell us anything about fencing working or not?
It says that we were given an active fence, we wait at it and hope it
signals when an error is reported. Like I said, we can't check the
results itself, as they are meaningless with the reset. If we have an
active fence at this point, that's bad, and the test should fail.
> I think it doesn't,
> and as long as I'm not wrong, I think such scenarios hardly belong to
> gem_exec_fence.
Hm, I'm not sure if I follow, but this exact transition (from active ->
(record error) -> signal) is one of the possible scenarios we wish to
test. Or, do you mean that this test case doesn't test
drm_i915_gem_exec_fence? This test suite exercises different scenarios
of using fences implemented with sync_files. Maybe this could be split
up, but these seem to be connected, so they ended up in one file.
> Otherwise, I think we should at least add descriptions of
> those subtests, providing some information on what is actually exercised.
The hang cases reuse test_fence_await which has _some_ description in
the basic cases. But I agree, it would be nice to have more
documentation for other subtests, but it's out of scope of this fix.
Many thanks,
Karolina
> Thanks,
> Janusz
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-07-29 11:32 ` Karolina Drobnik
@ 2022-07-29 15:23 ` Janusz Krzysztofik
0 siblings, 0 replies; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-07-29 15:23 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
> Hi Janusz,
>
> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
> > Hi Karolina,
> >
> > On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
> >> Hi Janusz,
> >>
> >> Thanks a lot for taking a look at the patch.
> >>
> >> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> >>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> >>>> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>
> >>>> test_fence_await verifies if a fence used to pipeline work signals
> >>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> >>>> which causes an erroneous state, meaning the fence will be signaled
> >>>> without execution. The error causes an instant reset of the command
> >>>> streamer for the hanging workload. This revealed a problem with how
> >>>> we verify the fence state and results. The test assumes that the
> >>>> error notification happens after a hang is declared, which takes
> >>>> longer than submitting the next set of fences, making the test pass
> >>>> every time. With the immediate reset, this might not happen, so the
> >>>> assertion fails, as there are no active fences in the GPU hang case.
> >>>>
> >>>> Move the check for active fence to the path for non-hanging workload,
> >>>> and verify results only in this scenario.
> >>>>
> >>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> >>>> ---
> >>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
> >>>> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>>>
> >>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> >>>> index d46914c2..260aa82c 100644
> >>>> --- a/tests/i915/gem_exec_fence.c
> >>>> +++ b/tests/i915/gem_exec_fence.c
> >>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
> > intel_ctx_t
> >>> *ctx,
> >>>> /* Long, but not too long to anger preemption disable checks */
> >>>> usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
> >>>>
> >>>> - /* Check for invalidly completing the task early */
> >>>> - igt_assert(fence_busy(spin->out_fence));
> >>>> - for (int n = 0; n < i; n++)
> >>>> - igt_assert_eq_u32(out[n], 0);
> >>>> + if ((flags & HANG) == 0) {
> >>>> + /* Check for invalidly completing the task early */
> >>>> + igt_assert(fence_busy(spin->out_fence));
> >>>> + for (int n = 0; n < i; n++)
> >>>> + igt_assert_eq_u32(out[n], 0);
> >>>
> >>> AFAICU, in the 'hang' variant of the scenario we skip the above asserts
> >>> because the spin batch could have already hanged, then its out fence
> > already
> >>> signalled and store batches waiting for that signal already executed. If
> >>> that's the case, how do this variant of gem_exec_fence test asserts that
> > the
> >>> fence actually worked as expected?
> >>
> >> With this change, yes, we would skip them. Still, the store batches
> >> wouldn't be executed, as we reset the CS on hang as a part of the error
> >> handling. For valid jobs, we expect to (1) see an active fence at the
> >> beginning of the request, (2) get a signaled fence after the wait, (3)
> >> store out[i] == i. With a hang, (1) and (3) would be false.
> >>
> >> In this particular loop, we could have garbage here with hang, not 0s
> >> (although, from my tests it looks like they are zeroed, but maybe I got
> >> lucky)
> >
> > OK, so I missed the fact that the store batches won't be executed at all due
> > to reset of the whole command stream that also kills those batches. But my
> > question is still valid: as soon as we omit those checks as not valid from
> > *await-hang variants, how do those variants still exercise fencing? IOW, how
> > are those variants supposed to ever fail should something be wrong with i915
> > implementation of fencing specifically?
>
> They would fail in the case where a hang happened but the fence is still
> active, so it's this last assert you're referring to.
>
> >>
> >>>>
> >>>> - if ((flags & HANG) == 0)
> >>>> igt_spin_end(spin);
> >>>> + }
> >>>>
> >>>> igt_waitchildren();
> >>>>
> >>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> >>>> - while (i--)
> >>>> + igt_assert(!fence_busy(spin->out_fence));
> >>>
> >>> We only check that the out fence of the presumably hanged spin batch no
> > longer
> >>> blocks execution of store batches.
> >>
> >> This check applies to all workloads, all of them should be done with
> >> work at this point
> >
> > OK, but since that's the only explicit assert in the *-hang processing path,
> > does it tell us anything about fencing working or not?
>
> It says that we were given an active fence, we wait at it and hope it
> signals when an error is reported. Like I said, we can't check the
> results itself, as they are meaningless with the reset. If we have an
> active fence at this point, that's bad, and the test should fail.
>
> > I think it doesn't,
> > and as long as I'm not wrong, I think such scenarios hardly belong to
> > gem_exec_fence.
>
> Hm, I'm not sure if I follow, but this exact transition (from active ->
> (record error) -> signal) is one of the possible scenarios we wish to
> test.
OK, so we check if an active fence is signalled on error. But then, what does
'active' mean here? Do we consider a fence active as soon as it has been
exported to userspace? Or only after it has been imported back from userspace
by at least one consumer? Assuming the former (as I guess), what do we need
the store batches for in these now modified *await-hang scenarios? What extra
value do those scenarios provide compared to (nb-)?wait-hang ?
Thanks,
Janusz
> Or, do you mean that this test case doesn't test
> drm_i915_gem_exec_fence? This test suite exercises different scenarios
> of using fences implemented with sync_files. Maybe this could be split
> up, but these seem to be connected, so they ended up in one file.
>
> > Otherwise, I think we should at least add descriptions of
> > those subtests, providing some information on what is actually exercised.
>
> The hang cases reuse test_fence_await which has _some_ description in
> the basic cases. But I agree, it would be nice to have more
> documentation for other subtests, but it's out of scope of this fix.
>
> Many thanks,
> Karolina
>
> > Thanks,
> > Janusz
> >
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
[not found] ` <fb564118-4afb-6f4a-03cc-34e255b871ef@intel.com>
@ 2022-08-01 11:54 ` Janusz Krzysztofik
2022-08-01 13:39 ` Karolina Drobnik
0 siblings, 1 reply; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-08-01 11:54 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
On Monday, 1 August 2022 11:51:27 CEST Karolina Drobnik wrote:
> Hi,
>
> On 01.08.2022 10:11, Janusz Krzysztofik wrote:
> > On Monday, 1 August 2022 07:53:54 CEST Karolina Drobnik wrote:
> >> Hi,
> >>
> >> On 29.07.2022 17:23, Janusz Krzysztofik wrote:
> >>> On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
> >>>> Hi Janusz,
> >>>>
> >>>> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
> >>>>> Hi Karolina,
> >>>>>
> >>>>> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
> >>>>>> Hi Janusz,
> >>>>>>
> >>>>>> Thanks a lot for taking a look at the patch.
> >>>>>>
> >>>>>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> >>>>>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> >>>>>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>>
> >>>>>>>> test_fence_await verifies if a fence used to pipeline work signals
> >>>>>>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> >>>>>>>> which causes an erroneous state, meaning the fence will be signaled
> >>>>>>>> without execution. The error causes an instant reset of the command
> >>>>>>>> streamer for the hanging workload. This revealed a problem with how
> >>>>>>>> we verify the fence state and results. The test assumes that the
> >>>>>>>> error notification happens after a hang is declared, which takes
> >>>>>>>> longer than submitting the next set of fences, making the test pass
> >>>>>>>> every time. With the immediate reset, this might not happen, so the
> >>>>>>>> assertion fails, as there are no active fences in the GPU hang case.
> >>>>>>>>
> >>>>>>>> Move the check for active fence to the path for non-hanging workload,
> >>>>>>>> and verify results only in this scenario.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> >>>>>>>> ---
> >>>>>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
> >>>>>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/
> > gem_exec_fence.c
> >>>>>>>> index d46914c2..260aa82c 100644
> >>>>>>>> --- a/tests/i915/gem_exec_fence.c
> >>>>>>>> +++ b/tests/i915/gem_exec_fence.c
> >>>>>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
> >>>>> intel_ctx_t
> >>>>>>> *ctx,
> >> (...)
> >>>>>>>>
> >>>>>>>> - if ((flags & HANG) == 0)
> >>>>>>>> igt_spin_end(spin);
> >>>>>>>> + }
> >>>>>>>>
> >>>>>>>> igt_waitchildren();
> >>>>>>>>
> >>>>>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> >>>>>>>> - while (i--)
> >>>>>>>> + igt_assert(!fence_busy(spin->out_fence));
> >>>>>>>
> >>>>>>> We only check that the out fence of the presumably hanged spin batch
> > no
> >>>>> longer
> >>>>>>> blocks execution of store batches.
> >>>>>>
> >>>>>> This check applies to all workloads, all of them should be done with
> >>>>>> work at this point
> >>>>>
> >>>>> OK, but since that's the only explicit assert in the *-hang processing
> > path,
> >>>>> does it tell us anything about fencing working or not?
> >>>>
> >>>> It says that we were given an active fence, we wait at it and hope it
> >>>> signals when an error is reported. Like I said, we can't check the
> >>>> results itself, as they are meaningless with the reset. If we have an
> >>>> active fence at this point, that's bad, and the test should fail.
> >>>>
> >>>>> I think it doesn't,
> >>>>> and as long as I'm not wrong, I think such scenarios hardly belong to
> >>>>> gem_exec_fence.
> >>>>
> >>>> Hm, I'm not sure if I follow, but this exact transition (from active ->
> >>>> (record error) -> signal) is one of the possible scenarios we wish to
> >>>> test.
> >>>
> >>> OK, so we check if an active fence is signalled on error. But then, what
> > does
> >>> 'active' mean here?
> >>
> >> Active means that the fence was sent and we wait to hear back from the
> >> GPU. If you'd like to see what are the state transitions in fences, you
> >> can check out Mainline Explicit Fencing series of blog posts/presentation.
> >>
> >>> Do we consider a fence active as soon as it has been
> >>> exported to userspace? Or only after it has been imported back from
> > userspace
> >>> by at least one consumer?
> >>
> >> We assume them to be active as soon as the fence's fd is returned from
> >> the driver to userspace (we deal with out-fences here).
> >>
> >>> Assuming the former (as I guess), what do we need
> >>> the store batches for in these now modified *await-hang scenarios? What
> > extra
> >>> value do those scenarios provide compared to (nb-)?wait-hang ?
> >>
> >> Hm, I don't quite understand the question here -- are you asking why do
> >> we check the store results? test_fence_await is reused by other
> >> subtests, not only the hanging cases, and we expect to see the stores.
> >
> > The patch introduces two processing paths to test_fence_await(), one of them
> > for *-hang variants. In that *-hang processing path, why do we still submit
> > batches that depend on the fence if we don't examine their execution and
> > results, only their completion?
>
> Ah, OK, now I get it. Do you suggest that we should also add a check for
> HANG flag for igt_store_word block? But we still need to send something
> to test this case.
Why do we need to send something? What that something should look like? IOW,
what are we trying to exercise with this case? How is it supposed to be
different from wait-hang scenario?
>
> > They get completed regardless of fencing working or not, I believe, > then that part of the *-hang processing path
> > related to store batches seems useless for me in a test focused on fencing.
>
> Do they get completed? We'll get a CS reset and this batch won't
> complete.
OK, by completed I meant no longer queued nor running.
> Yes, in the case of hangs we just check the fence,
Again, how this is supposed to be different from wait-hang scenario?
Thanks,
Janusz
> but in
> general we do care about these stores. This patch aims to fix the
> problem uncovered during manual testing (*-hang variants are not run in
> CI), it does not try to rewrite the test (because that's what would be
> required to completely separate these two test cases).
>
> Many thanks,
> Karolina
>
> > Thanks,
> > Janusz
> >
> >>
> >> Many thanks,
> >> Karolina
> >>
> >>> Thanks,
> >>> Janusz
> >>
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-08-01 11:54 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Janusz Krzysztofik
@ 2022-08-01 13:39 ` Karolina Drobnik
2022-08-01 14:43 ` Janusz Krzysztofik
0 siblings, 1 reply; 20+ messages in thread
From: Karolina Drobnik @ 2022-08-01 13:39 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi,
On 01.08.2022 13:54, Janusz Krzysztofik wrote:
> On Monday, 1 August 2022 11:51:27 CEST Karolina Drobnik wrote:
>> Hi,
>>
>> On 01.08.2022 10:11, Janusz Krzysztofik wrote:
>>> On Monday, 1 August 2022 07:53:54 CEST Karolina Drobnik wrote:
>>>> Hi,
>>>>
>>>> On 29.07.2022 17:23, Janusz Krzysztofik wrote:
>>>>> On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
>>>>>> Hi Janusz,
>>>>>>
>>>>>> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
>>>>>>> Hi Karolina,
>>>>>>>
>>>>>>> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
>>>>>>>> Hi Janusz,
>>>>>>>>
>>>>>>>> Thanks a lot for taking a look at the patch.
>>>>>>>>
>>>>>>>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
>>>>>>>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
>>>>>>>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>>>>>
>>>>>>>>>> test_fence_await verifies if a fence used to pipeline work signals
>>>>>>>>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
>>>>>>>>>> which causes an erroneous state, meaning the fence will be signaled
>>>>>>>>>> without execution. The error causes an instant reset of the command
>>>>>>>>>> streamer for the hanging workload. This revealed a problem with how
>>>>>>>>>> we verify the fence state and results. The test assumes that the
>>>>>>>>>> error notification happens after a hang is declared, which takes
>>>>>>>>>> longer than submitting the next set of fences, making the test pass
>>>>>>>>>> every time. With the immediate reset, this might not happen, so the
>>>>>>>>>> assertion fails, as there are no active fences in the GPU hang case.
>>>>>>>>>>
>>>>>>>>>> Move the check for active fence to the path for non-hanging workload,
>>>>>>>>>> and verify results only in this scenario.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
>>>>>>>>>> ---
>>>>>>>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
>>>>>>>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/
>>> gem_exec_fence.c
>>>>>>>>>> index d46914c2..260aa82c 100644
>>>>>>>>>> --- a/tests/i915/gem_exec_fence.c
>>>>>>>>>> +++ b/tests/i915/gem_exec_fence.c
>>>>>>>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
>>>>>>> intel_ctx_t
>>>>>>>>> *ctx,
>>>> (...)
>>>>>>>>>>
>>>>>>>>>> - if ((flags & HANG) == 0)
>>>>>>>>>> igt_spin_end(spin);
>>>>>>>>>> + }
>>>>>>>>>>
>>>>>>>>>> igt_waitchildren();
>>>>>>>>>>
>>>>>>>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
>>>>>>>>>> - while (i--)
>>>>>>>>>> + igt_assert(!fence_busy(spin->out_fence));
>>>>>>>>>
>>>>>>>>> We only check that the out fence of the presumably hanged spin batch
>>> no
>>>>>>> longer
>>>>>>>>> blocks execution of store batches.
>>>>>>>>
>>>>>>>> This check applies to all workloads, all of them should be done with
>>>>>>>> work at this point
>>>>>>>
>>>>>>> OK, but since that's the only explicit assert in the *-hang processing
>>> path,
>>>>>>> does it tell us anything about fencing working or not?
>>>>>>
>>>>>> It says that we were given an active fence, we wait at it and hope it
>>>>>> signals when an error is reported. Like I said, we can't check the
>>>>>> results itself, as they are meaningless with the reset. If we have an
>>>>>> active fence at this point, that's bad, and the test should fail.
>>>>>>
>>>>>>> I think it doesn't,
>>>>>>> and as long as I'm not wrong, I think such scenarios hardly belong to
>>>>>>> gem_exec_fence.
>>>>>>
>>>>>> Hm, I'm not sure if I follow, but this exact transition (from active ->
>>>>>> (record error) -> signal) is one of the possible scenarios we wish to
>>>>>> test.
>>>>>
>>>>> OK, so we check if an active fence is signalled on error. But then, what
>>> does
>>>>> 'active' mean here?
>>>>
>>>> Active means that the fence was sent and we wait to hear back from the
>>>> GPU. If you'd like to see what are the state transitions in fences, you
>>>> can check out Mainline Explicit Fencing series of blog posts/presentation.
>>>>
>>>>> Do we consider a fence active as soon as it has been
>>>>> exported to userspace? Or only after it has been imported back from
>>> userspace
>>>>> by at least one consumer?
>>>>
>>>> We assume them to be active as soon as the fence's fd is returned from
>>>> the driver to userspace (we deal with out-fences here).
>>>>
>>>>> Assuming the former (as I guess), what do we need
>>>>> the store batches for in these now modified *await-hang scenarios? What
>>> extra
>>>>> value do those scenarios provide compared to (nb-)?wait-hang ?
>>>>
>>>> Hm, I don't quite understand the question here -- are you asking why do
>>>> we check the store results? test_fence_await is reused by other
>>>> subtests, not only the hanging cases, and we expect to see the stores.
>>>
>>> The patch introduces two processing paths to test_fence_await(), one of them
>>> for *-hang variants. In that *-hang processing path, why do we still submit
>>> batches that depend on the fence if we don't examine their execution and
>>> results, only their completion?
>>
>> Ah, OK, now I get it. Do you suggest that we should also add a check for
>> HANG flag for igt_store_word block? But we still need to send something
>> to test this case.
>
> Why do we need to send something? What that something should look like? IOW,
> what are we trying to exercise with this case? How is it supposed to be
> different from wait-hang scenario?
test_fence_await tests pipelining work (here, writing something to
memory in parallel) and cross-checks its status with what's reported by
the fence, whereas test_fence_busy checks if the fence signals to
userspace after hang (a more general case). I'm sorry, I didn't make
this distinction clear in the beginning.
>>
>>> They get completed regardless of fencing working or not, I believe, > then that part of the *-hang processing path
>>> related to store batches seems useless for me in a test focused on fencing.
>>
>> Do they get completed? We'll get a CS reset and this batch won't
>> complete.
>
> OK, by completed I meant no longer queued nor running.
OK, I see -- yes, that's correct
Thanks,
Karolina
>> Yes, in the case of hangs we just check the fence,
>
> Again, how this is supposed to be different from wait-hang scenario?
>
> Thanks,
> Janusz
>
>> but in
>> general we do care about these stores. This patch aims to fix the
>> problem uncovered during manual testing (*-hang variants are not run in
>> CI), it does not try to rewrite the test (because that's what would be
>> required to completely separate these two test cases).
>>
>> Many thanks,
>> Karolina
>>
>>> Thanks,
>>> Janusz
>>>
>>>>
>>>> Many thanks,
>>>> Karolina
>>>>
>>>>> Thanks,
>>>>> Janusz
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-08-01 13:39 ` Karolina Drobnik
@ 2022-08-01 14:43 ` Janusz Krzysztofik
2022-08-02 10:20 ` Karolina Drobnik
0 siblings, 1 reply; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-08-01 14:43 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
On Monday, 1 August 2022 15:39:36 CEST Karolina Drobnik wrote:
> Hi,
>
> On 01.08.2022 13:54, Janusz Krzysztofik wrote:
> > On Monday, 1 August 2022 11:51:27 CEST Karolina Drobnik wrote:
> >> Hi,
> >>
> >> On 01.08.2022 10:11, Janusz Krzysztofik wrote:
> >>> On Monday, 1 August 2022 07:53:54 CEST Karolina Drobnik wrote:
> >>>> Hi,
> >>>>
> >>>> On 29.07.2022 17:23, Janusz Krzysztofik wrote:
> >>>>> On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
> >>>>>> Hi Janusz,
> >>>>>>
> >>>>>> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
> >>>>>>> Hi Karolina,
> >>>>>>>
> >>>>>>> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
> >>>>>>>> Hi Janusz,
> >>>>>>>>
> >>>>>>>> Thanks a lot for taking a look at the patch.
> >>>>>>>>
> >>>>>>>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> >>>>>>>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> >>>>>>>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>>>>
> >>>>>>>>>> test_fence_await verifies if a fence used to pipeline work signals
> >>>>>>>>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
> >>>>>>>>>> which causes an erroneous state, meaning the fence will be signaled
> >>>>>>>>>> without execution. The error causes an instant reset of the command
> >>>>>>>>>> streamer for the hanging workload. This revealed a problem with how
> >>>>>>>>>> we verify the fence state and results. The test assumes that the
> >>>>>>>>>> error notification happens after a hang is declared, which takes
> >>>>>>>>>> longer than submitting the next set of fences, making the test pass
> >>>>>>>>>> every time. With the immediate reset, this might not happen, so the
> >>>>>>>>>> assertion fails, as there are no active fences in the GPU hang case.
> >>>>>>>>>>
> >>>>>>>>>> Move the check for active fence to the path for non-hanging workload,
> >>>>>>>>>> and verify results only in this scenario.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> >>>>>>>>>> ---
> >>>>>>>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
> >>>>>>>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/
> >>> gem_exec_fence.c
> >>>>>>>>>> index d46914c2..260aa82c 100644
> >>>>>>>>>> --- a/tests/i915/gem_exec_fence.c
> >>>>>>>>>> +++ b/tests/i915/gem_exec_fence.c
> >>>>>>>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
> >>>>>>> intel_ctx_t
> >>>>>>>>> *ctx,
> >>>> (...)
> >>>>>>>>>>
> >>>>>>>>>> - if ((flags & HANG) == 0)
> >>>>>>>>>> igt_spin_end(spin);
> >>>>>>>>>> + }
> >>>>>>>>>>
> >>>>>>>>>> igt_waitchildren();
> >>>>>>>>>>
> >>>>>>>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> >>>>>>>>>> - while (i--)
> >>>>>>>>>> + igt_assert(!fence_busy(spin->out_fence));
> >>>>>>>>>
> >>>>>>>>> We only check that the out fence of the presumably hanged spin batch
> >>> no
> >>>>>>> longer
> >>>>>>>>> blocks execution of store batches.
> >>>>>>>>
> >>>>>>>> This check applies to all workloads, all of them should be done with
> >>>>>>>> work at this point
> >>>>>>>
> >>>>>>> OK, but since that's the only explicit assert in the *-hang processing
> >>> path,
> >>>>>>> does it tell us anything about fencing working or not?
> >>>>>>
> >>>>>> It says that we were given an active fence, we wait at it and hope it
> >>>>>> signals when an error is reported. Like I said, we can't check the
> >>>>>> results itself, as they are meaningless with the reset. If we have an
> >>>>>> active fence at this point, that's bad, and the test should fail.
> >>>>>>
> >>>>>>> I think it doesn't,
> >>>>>>> and as long as I'm not wrong, I think such scenarios hardly belong to
> >>>>>>> gem_exec_fence.
> >>>>>>
> >>>>>> Hm, I'm not sure if I follow, but this exact transition (from active ->
> >>>>>> (record error) -> signal) is one of the possible scenarios we wish to
> >>>>>> test.
> >>>>>
> >>>>> OK, so we check if an active fence is signalled on error. But then, what
> >>> does
> >>>>> 'active' mean here?
> >>>>
> >>>> Active means that the fence was sent and we wait to hear back from the
> >>>> GPU. If you'd like to see what are the state transitions in fences, you
> >>>> can check out Mainline Explicit Fencing series of blog posts/presentation.
> >>>>
> >>>>> Do we consider a fence active as soon as it has been
> >>>>> exported to userspace? Or only after it has been imported back from
> >>> userspace
> >>>>> by at least one consumer?
> >>>>
> >>>> We assume them to be active as soon as the fence's fd is returned from
> >>>> the driver to userspace (we deal with out-fences here).
> >>>>
> >>>>> Assuming the former (as I guess), what do we need
> >>>>> the store batches for in these now modified *await-hang scenarios? What
> >>> extra
> >>>>> value do those scenarios provide compared to (nb-)?wait-hang ?
> >>>>
> >>>> Hm, I don't quite understand the question here -- are you asking why do
> >>>> we check the store results? test_fence_await is reused by other
> >>>> subtests, not only the hanging cases, and we expect to see the stores.
> >>>
> >>> The patch introduces two processing paths to test_fence_await(), one of them
> >>> for *-hang variants. In that *-hang processing path, why do we still submit
> >>> batches that depend on the fence if we don't examine their execution and
> >>> results, only their completion?
> >>
> >> Ah, OK, now I get it. Do you suggest that we should also add a check for
> >> HANG flag for igt_store_word block? But we still need to send something
> >> to test this case.
> >
> > Why do we need to send something? What that something should look like? IOW,
> > what are we trying to exercise with this case? How is it supposed to be
> > different from wait-hang scenario?
>
> test_fence_await tests pipelining work (here, writing something to
> memory in parallel) and cross-checks its status with what's reported by
> the fence,
True for *await (no HANG) subtests, but in *await-hang variants I still can't
recognize checks in place as cross-checks and what value they add compared to
wait-hang. Does a check for invalidated work no longer queued nor running
tell us anything about the fence behavior, i.e., if and how it affected /
interacted with that work? I think it doesn't, then, I'm not sure if we still
need such limited scenarios. Please convince me that we do and I'll be happy
to push the series with my S-o-b: added.
Thanks,
Janusz
> whereas test_fence_busy checks if the fence signals to
> userspace after hang (a more general case). I'm sorry, I didn't make
> this distinction clear in the beginning.
>
> >>
> >>> They get completed regardless of fencing working or not, I believe, > then that part of the *-hang processing path
> >>> related to store batches seems useless for me in a test focused on fencing.
> >>
> >> Do they get completed? We'll get a CS reset and this batch won't
> >> complete.
> >
> > OK, by completed I meant no longer queued nor running.
>
> OK, I see -- yes, that's correct
>
> Thanks,
> Karolina
>
> >> Yes, in the case of hangs we just check the fence,
> >
> > Again, how this is supposed to be different from wait-hang scenario?
> >
> > Thanks,
> > Janusz
> >
> >> but in
> >> general we do care about these stores. This patch aims to fix the
> >> problem uncovered during manual testing (*-hang variants are not run in
> >> CI), it does not try to rewrite the test (because that's what would be
> >> required to completely separate these two test cases).
> >>
> >> Many thanks,
> >> Karolina
> >>
> >>> Thanks,
> >>> Janusz
> >>>
> >>>>
> >>>> Many thanks,
> >>>> Karolina
> >>>>
> >>>>> Thanks,
> >>>>> Janusz
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-08-01 14:43 ` Janusz Krzysztofik
@ 2022-08-02 10:20 ` Karolina Drobnik
2022-08-03 7:21 ` Janusz Krzysztofik
0 siblings, 1 reply; 20+ messages in thread
From: Karolina Drobnik @ 2022-08-02 10:20 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi,
On 01.08.2022 16:43, Janusz Krzysztofik wrote:
> On Monday, 1 August 2022 15:39:36 CEST Karolina Drobnik wrote:
>> Hi,
>>
>> On 01.08.2022 13:54, Janusz Krzysztofik wrote:
>>> On Monday, 1 August 2022 11:51:27 CEST Karolina Drobnik wrote:
>>>> Hi,
>>>>
>>>> On 01.08.2022 10:11, Janusz Krzysztofik wrote:
>>>>> On Monday, 1 August 2022 07:53:54 CEST Karolina Drobnik wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 29.07.2022 17:23, Janusz Krzysztofik wrote:
>>>>>>> On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
>>>>>>>> Hi Janusz,
>>>>>>>>
>>>>>>>> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
>>>>>>>>> Hi Karolina,
>>>>>>>>>
>>>>>>>>> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
>>>>>>>>>> Hi Janusz,
>>>>>>>>>>
>>>>>>>>>> Thanks a lot for taking a look at the patch.
>>>>>>>>>>
>>>>>>>>>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
>>>>>>>>>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
>>>>>>>>>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>>>>>>>
>>>>>>>>>>>> test_fence_await verifies if a fence used to pipeline work signals
>>>>>>>>>>>> correctly. await-hang and nb-await-hang test cases inject GPU hang,
>>>>>>>>>>>> which causes an erroneous state, meaning the fence will be signaled
>>>>>>>>>>>> without execution. The error causes an instant reset of the command
>>>>>>>>>>>> streamer for the hanging workload. This revealed a problem with how
>>>>>>>>>>>> we verify the fence state and results. The test assumes that the
>>>>>>>>>>>> error notification happens after a hang is declared, which takes
>>>>>>>>>>>> longer than submitting the next set of fences, making the test pass
>>>>>>>>>>>> every time. With the immediate reset, this might not happen, so the
>>>>>>>>>>>> assertion fails, as there are no active fences in the GPU hang case.
>>>>>>>>>>>>
>>>>>>>>>>>> Move the check for active fence to the path for non-hanging workload,
>>>>>>>>>>>> and verify results only in this scenario.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>>>>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
>>>>>>>>>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/
>>>>> gem_exec_fence.c
>>>>>>>>>>>> index d46914c2..260aa82c 100644
>>>>>>>>>>>> --- a/tests/i915/gem_exec_fence.c
>>>>>>>>>>>> +++ b/tests/i915/gem_exec_fence.c
>>>>>>>>>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd, const
>>>>>>>>> intel_ctx_t
>>>>>>>>>>> *ctx,
>>>>>> (...)
>>>>>>>>>>>>
>>>>>>>>>>>> - if ((flags & HANG) == 0)
>>>>>>>>>>>> igt_spin_end(spin);
>>>>>>>>>>>> + }
>>>>>>>>>>>>
>>>>>>>>>>>> igt_waitchildren();
>>>>>>>>>>>>
>>>>>>>>>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
>>>>>>>>>>>> - while (i--)
>>>>>>>>>>>> + igt_assert(!fence_busy(spin->out_fence));
>>>>>>>>>>>
>>>>>>>>>>> We only check that the out fence of the presumably hanged spin batch
>>>>> no
>>>>>>>>> longer
>>>>>>>>>>> blocks execution of store batches.
>>>>>>>>>>
>>>>>>>>>> This check applies to all workloads, all of them should be done with
>>>>>>>>>> work at this point
>>>>>>>>>
>>>>>>>>> OK, but since that's the only explicit assert in the *-hang processing
>>>>> path,
>>>>>>>>> does it tell us anything about fencing working or not?
>>>>>>>>
>>>>>>>> It says that we were given an active fence, we wait at it and hope it
>>>>>>>> signals when an error is reported. Like I said, we can't check the
>>>>>>>> results itself, as they are meaningless with the reset. If we have an
>>>>>>>> active fence at this point, that's bad, and the test should fail.
>>>>>>>>
>>>>>>>>> I think it doesn't,
>>>>>>>>> and as long as I'm not wrong, I think such scenarios hardly belong to
>>>>>>>>> gem_exec_fence.
>>>>>>>>
>>>>>>>> Hm, I'm not sure if I follow, but this exact transition (from active ->
>>>>>>>> (record error) -> signal) is one of the possible scenarios we wish to
>>>>>>>> test.
>>>>>>>
>>>>>>> OK, so we check if an active fence is signalled on error. But then, what
>>>>> does
>>>>>>> 'active' mean here?
>>>>>>
>>>>>> Active means that the fence was sent and we wait to hear back from the
>>>>>> GPU. If you'd like to see what are the state transitions in fences, you
>>>>>> can check out Mainline Explicit Fencing series of blog posts/presentation.
>>>>>>
>>>>>>> Do we consider a fence active as soon as it has been
>>>>>>> exported to userspace? Or only after it has been imported back from
>>>>> userspace
>>>>>>> by at least one consumer?
>>>>>>
>>>>>> We assume them to be active as soon as the fence's fd is returned from
>>>>>> the driver to userspace (we deal with out-fences here).
>>>>>>
>>>>>>> Assuming the former (as I guess), what do we need
>>>>>>> the store batches for in these now modified *await-hang scenarios? What
>>>>> extra
>>>>>>> value do those scenarios provide compared to (nb-)?wait-hang ?
>>>>>>
>>>>>> Hm, I don't quite understand the question here -- are you asking why do
>>>>>> we check the store results? test_fence_await is reused by other
>>>>>> subtests, not only the hanging cases, and we expect to see the stores.
>>>>>
>>>>> The patch introduces two processing paths to test_fence_await(), one of them
>>>>> for *-hang variants. In that *-hang processing path, why do we still submit
>>>>> batches that depend on the fence if we don't examine their execution and
>>>>> results, only their completion?
>>>>
>>>> Ah, OK, now I get it. Do you suggest that we should also add a check for
>>>> HANG flag for igt_store_word block? But we still need to send something
>>>> to test this case.
>>>
>>> Why do we need to send something? What that something should look like? IOW,
>>> what are we trying to exercise with this case? How is it supposed to be
>>> different from wait-hang scenario?
>>
>> test_fence_await tests pipelining work (here, writing something to
>> memory in parallel) and cross-checks its status with what's reported by
>> the fence,
>
> True for *await (no HANG) subtests, but in *await-hang variants I still can't
> recognize checks in place as cross-checks and what value they add compared to
> wait-hang.
wait_hang and await_hang are different in the sense of work they do.
test_fence_busy is a test with a simple batch buffer (with no actual
writes) that is _iteratively_ executed on different physical engines,
whereas test_fence_await spawns work on different engines in _parallel_.
It's a different scenario from the fence's perspective, as we have one
fence on the spinner and pass it to other engines which (asynchronously)
wait on it. The value added here is the check for 1 fence - many engines
(wait_hang has 1-1 mapping).
> Does a check for invalidated work no longer queued nor running
> tell us anything about the fence behavior, i.e., if and how it affected /
> interacted with that work? I think it doesn't, then, I'm not sure if we still
> need such limited scenarios.
I don't think I quite understand -- we check if we've sent a hanging
workload, which is expected to result in an error, there's no additional
check for the work itself (how one could check it?). As the error is
raised from any of the engines (I'm taking about the await case), the
fence is expected to signal, and this is what we check. The fence itself
can't interact with that work
> Please convince me that we do and I'll be happy
> to push the series with my S-o-b: added.
I have commit rights now, so I can push it myself, but I want to address
all the comments before moving on.
If you have further questions or my answers are not satisfactory (which
is fair), you can reach out to the author. He knows all the bits and
pieces of this test suite. I'm more of a messenger here.
All the best,
Karolina
> Thanks,
> Janusz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-08-02 10:20 ` Karolina Drobnik
@ 2022-08-03 7:21 ` Janusz Krzysztofik
2022-08-03 7:45 ` Karolina Drobnik
0 siblings, 1 reply; 20+ messages in thread
From: Janusz Krzysztofik @ 2022-08-03 7:21 UTC (permalink / raw)
To: Karolina Drobnik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
On Tuesday, 2 August 2022 12:20:29 CEST Karolina Drobnik wrote:
> Hi,
>
> On 01.08.2022 16:43, Janusz Krzysztofik wrote:
> > On Monday, 1 August 2022 15:39:36 CEST Karolina Drobnik wrote:
> >> Hi,
> >>
> >> On 01.08.2022 13:54, Janusz Krzysztofik wrote:
> >>> On Monday, 1 August 2022 11:51:27 CEST Karolina Drobnik wrote:
> >>>> Hi,
> >>>>
> >>>> On 01.08.2022 10:11, Janusz Krzysztofik wrote:
> >>>>> On Monday, 1 August 2022 07:53:54 CEST Karolina Drobnik wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 29.07.2022 17:23, Janusz Krzysztofik wrote:
> >>>>>>> On Friday, 29 July 2022 13:32:37 CEST Karolina Drobnik wrote:
> >>>>>>>> Hi Janusz,
> >>>>>>>>
> >>>>>>>> On 29.07.2022 10:24, Janusz Krzysztofik wrote:
> >>>>>>>>> Hi Karolina,
> >>>>>>>>>
> >>>>>>>>> On Friday, 29 July 2022 09:38:43 CEST Karolina Drobnik wrote:
> >>>>>>>>>> Hi Janusz,
> >>>>>>>>>>
> >>>>>>>>>> Thanks a lot for taking a look at the patch.
> >>>>>>>>>>
> >>>>>>>>>> On 28.07.2022 18:56, Janusz Krzysztofik wrote:
> >>>>>>>>>>> On Tuesday, 26 July 2022 12:13:11 CEST Karolina Drobnik wrote:
> >>>>>>>>>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>>>>>>
> >>>>>>>>>>>> test_fence_await verifies if a fence used to pipeline work
signals
> >>>>>>>>>>>> correctly. await-hang and nb-await-hang test cases inject GPU
hang,
> >>>>>>>>>>>> which causes an erroneous state, meaning the fence will be
signaled
> >>>>>>>>>>>> without execution. The error causes an instant reset of the
command
> >>>>>>>>>>>> streamer for the hanging workload. This revealed a problem with
how
> >>>>>>>>>>>> we verify the fence state and results. The test assumes that
the
> >>>>>>>>>>>> error notification happens after a hang is declared, which
takes
> >>>>>>>>>>>> longer than submitting the next set of fences, making the test
pass
> >>>>>>>>>>>> every time. With the immediate reset, this might not happen, so
the
> >>>>>>>>>>>> assertion fails, as there are no active fences in the GPU hang
case.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Move the check for active fence to the path for non-hanging
workload,
> >>>>>>>>>>>> and verify results only in this scenario.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>>>>>> Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> tests/i915/gem_exec_fence.c | 14 ++++++++------
> >>>>>>>>>>>> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/
> >>>>> gem_exec_fence.c
> >>>>>>>>>>>> index d46914c2..260aa82c 100644
> >>>>>>>>>>>> --- a/tests/i915/gem_exec_fence.c
> >>>>>>>>>>>> +++ b/tests/i915/gem_exec_fence.c
> >>>>>>>>>>>> @@ -350,18 +350,20 @@ static void test_fence_await(int fd,
const
> >>>>>>>>> intel_ctx_t
> >>>>>>>>>>> *ctx,
> >>>>>> (...)
> >>>>>>>>>>>>
> >>>>>>>>>>>> - if ((flags & HANG) == 0)
> >>>>>>>>>>>> igt_spin_end(spin);
> >>>>>>>>>>>> + }
> >>>>>>>>>>>>
> >>>>>>>>>>>> igt_waitchildren();
> >>>>>>>>>>>>
> >>>>>>>>>>>> gem_set_domain(fd, scratch, I915_GEM_DOMAIN_GTT, 0);
> >>>>>>>>>>>> - while (i--)
> >>>>>>>>>>>> + igt_assert(!fence_busy(spin->out_fence));
> >>>>>>>>>>>
> >>>>>>>>>>> We only check that the out fence of the presumably hanged spin
batch
> >>>>> no
> >>>>>>>>> longer
> >>>>>>>>>>> blocks execution of store batches.
> >>>>>>>>>>
> >>>>>>>>>> This check applies to all workloads, all of them should be done
with
> >>>>>>>>>> work at this point
> >>>>>>>>>
> >>>>>>>>> OK, but since that's the only explicit assert in the *-hang
processing
> >>>>> path,
> >>>>>>>>> does it tell us anything about fencing working or not?
> >>>>>>>>
> >>>>>>>> It says that we were given an active fence, we wait at it and hope
it
> >>>>>>>> signals when an error is reported. Like I said, we can't check the
> >>>>>>>> results itself, as they are meaningless with the reset. If we have
an
> >>>>>>>> active fence at this point, that's bad, and the test should fail.
> >>>>>>>>
> >>>>>>>>> I think it doesn't,
> >>>>>>>>> and as long as I'm not wrong, I think such scenarios hardly belong
to
> >>>>>>>>> gem_exec_fence.
> >>>>>>>>
> >>>>>>>> Hm, I'm not sure if I follow, but this exact transition (from
active ->
> >>>>>>>> (record error) -> signal) is one of the possible scenarios we wish
to
> >>>>>>>> test.
> >>>>>>>
> >>>>>>> OK, so we check if an active fence is signalled on error. But then,
what
> >>>>> does
> >>>>>>> 'active' mean here?
> >>>>>>
> >>>>>> Active means that the fence was sent and we wait to hear back from
the
> >>>>>> GPU. If you'd like to see what are the state transitions in fences,
you
> >>>>>> can check out Mainline Explicit Fencing series of blog posts/
presentation.
> >>>>>>
> >>>>>>> Do we consider a fence active as soon as it has been
> >>>>>>> exported to userspace? Or only after it has been imported back from
> >>>>> userspace
> >>>>>>> by at least one consumer?
> >>>>>>
> >>>>>> We assume them to be active as soon as the fence's fd is returned
from
> >>>>>> the driver to userspace (we deal with out-fences here).
> >>>>>>
> >>>>>>> Assuming the former (as I guess), what do we need
> >>>>>>> the store batches for in these now modified *await-hang scenarios?
What
> >>>>> extra
> >>>>>>> value do those scenarios provide compared to (nb-)?wait-hang ?
> >>>>>>
> >>>>>> Hm, I don't quite understand the question here -- are you asking why
do
> >>>>>> we check the store results? test_fence_await is reused by other
> >>>>>> subtests, not only the hanging cases, and we expect to see the
stores.
> >>>>>
> >>>>> The patch introduces two processing paths to test_fence_await(), one
of them
> >>>>> for *-hang variants. In that *-hang processing path, why do we still
submit
> >>>>> batches that depend on the fence if we don't examine their execution
and
> >>>>> results, only their completion?
> >>>>
> >>>> Ah, OK, now I get it. Do you suggest that we should also add a check
for
> >>>> HANG flag for igt_store_word block? But we still need to send something
> >>>> to test this case.
> >>>
> >>> Why do we need to send something? What that something should look like?
IOW,
> >>> what are we trying to exercise with this case? How is it supposed to be
> >>> different from wait-hang scenario?
> >>
> >> test_fence_await tests pipelining work (here, writing something to
> >> memory in parallel) and cross-checks its status with what's reported by
> >> the fence,
> >
> > True for *await (no HANG) subtests, but in *await-hang variants I still
can't
> > recognize checks in place as cross-checks and what value they add compared
to
> > wait-hang.
>
> wait_hang and await_hang are different in the sense of work they do.
> test_fence_busy is a test with a simple batch buffer (with no actual
> writes) that is _iteratively_ executed on different physical engines,
> whereas test_fence_await spawns work on different engines in _parallel_.
> It's a different scenario from the fence's perspective, as we have one
> fence on the spinner and pass it to other engines which (asynchronously)
> wait on it. The value added here is the check for 1 fence - many engines
> (wait_hang has 1-1 mapping).
>
> > Does a check for invalidated work no longer queued nor running
> > tell us anything about the fence behavior, i.e., if and how it affected /
> > interacted with that work? I think it doesn't, then, I'm not sure if we
still
> > need such limited scenarios.
>
> I don't think I quite understand -- we check if we've sent a hanging
> workload, which is expected to result in an error, there's no additional
> check for the work itself (how one could check it?). As the error is
> raised from any of the engines (I'm taking about the await case), the
> fence is expected to signal, and this is what we check. The fence itself
> can't interact with that work
>
> > Please convince me that we do and I'll be happy
> > to push the series with my S-o-b: added.
>
> I have commit rights now, so I can push it myself,
OK, let's take a different approach then. Please feel free to push the series
with R-b:s collected so far yourself, and I'll try to update and restore
disabled checks in a follow-up patch.
Thanks,
Janusz
> but I want to address
> all the comments before moving on.
>
> If you have further questions or my answers are not satisfactory (which
> is fair), you can reach out to the author. He knows all the bits and
> pieces of this test suite. I'm more of a messenger here.
>
> All the best,
> Karolina
>
> > Thanks,
> > Janusz
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads
2022-08-03 7:21 ` Janusz Krzysztofik
@ 2022-08-03 7:45 ` Karolina Drobnik
0 siblings, 0 replies; 20+ messages in thread
From: Karolina Drobnik @ 2022-08-03 7:45 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, Chris Wilson, Tvrtko Ursulin
Hi,
On 03.08.2022 09:21, Janusz Krzysztofik wrote:
> On Tuesday, 2 August 2022 12:20:29 CEST Karolina Drobnik wrote:
>> Hi,
>>
>> On 01.08.2022 16:43, Janusz Krzysztofik wrote:
>>> On Monday, 1 August 2022 15:39:36 CEST Karolina Drobnik wrote:
<big snip>
>>>>>>> The patch introduces two processing paths to test_fence_await(), one
> of them
>>>>>>> for *-hang variants. In that *-hang processing path, why do we still
> submit
>>>>>>> batches that depend on the fence if we don't examine their execution
> and
>>>>>>> results, only their completion?
>>>>>>
>>>>>> Ah, OK, now I get it. Do you suggest that we should also add a check
> for
>>>>>> HANG flag for igt_store_word block? But we still need to send something
>>>>>> to test this case.
>>>>>
>>>>> Why do we need to send something? What that something should look like?
> IOW,
>>>>> what are we trying to exercise with this case? How is it supposed to be
>>>>> different from wait-hang scenario?
>>>>
>>>> test_fence_await tests pipelining work (here, writing something to
>>>> memory in parallel) and cross-checks its status with what's reported by
>>>> the fence,
>>>
>>> True for *await (no HANG) subtests, but in *await-hang variants I still
> can't
>>> recognize checks in place as cross-checks and what value they add compared
> to
>>> wait-hang.
>>
>> wait_hang and await_hang are different in the sense of work they do.
>> test_fence_busy is a test with a simple batch buffer (with no actual
>> writes) that is _iteratively_ executed on different physical engines,
>> whereas test_fence_await spawns work on different engines in _parallel_.
>> It's a different scenario from the fence's perspective, as we have one
>> fence on the spinner and pass it to other engines which (asynchronously)
>> wait on it. The value added here is the check for 1 fence - many engines
>> (wait_hang has 1-1 mapping).
>>
>>> Does a check for invalidated work no longer queued nor running
>>> tell us anything about the fence behavior, i.e., if and how it affected /
>>> interacted with that work? I think it doesn't, then, I'm not sure if we
> still
>>> need such limited scenarios.
>>
>> I don't think I quite understand -- we check if we've sent a hanging
>> workload, which is expected to result in an error, there's no additional
>> check for the work itself (how one could check it?). As the error is
>> raised from any of the engines (I'm taking about the await case), the
>> fence is expected to signal, and this is what we check. The fence itself
>> can't interact with that work
>>
>>> Please convince me that we do and I'll be happy
>>> to push the series with my S-o-b: added.
>>
>> I have commit rights now, so I can push it myself,
>
> OK, let's take a different approach then. Please feel free to push the series
> with R-b:s collected so far yourself, and I'll try to update and restore
> disabled checks in a follow-up patch.
OK, that sounds like a plan, thanks. You can CC the list of people we
have here for better visibility (and, hopefully, more feedback).
Many thanks,
Karolina
> Thanks,
> Janusz
>
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-08-03 7:45 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-26 10:13 [igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads Karolina Drobnik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Karolina Drobnik
2022-07-26 14:27 ` Kamil Konieczny
2022-07-28 16:56 ` Janusz Krzysztofik
2022-07-29 7:38 ` Karolina Drobnik
2022-07-29 8:24 ` Janusz Krzysztofik
2022-07-29 11:32 ` Karolina Drobnik
2022-07-29 15:23 ` Janusz Krzysztofik
2022-07-26 10:13 ` [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request Karolina Drobnik
2022-07-26 14:28 ` Kamil Konieczny
2022-07-26 10:54 ` [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2) Patchwork
2022-07-26 11:06 ` Karolina Drobnik
2022-07-28 15:17 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2022-07-28 21:20 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
[not found] ` <6459819.4vTCxPXJkl@jkrzyszt-mobl1.ger.corp.intel.com>
[not found] ` <fb564118-4afb-6f4a-03cc-34e255b871ef@intel.com>
2022-08-01 11:54 ` [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads Janusz Krzysztofik
2022-08-01 13:39 ` Karolina Drobnik
2022-08-01 14:43 ` Janusz Krzysztofik
2022-08-02 10:20 ` Karolina Drobnik
2022-08-03 7:21 ` Janusz Krzysztofik
2022-08-03 7:45 ` Karolina Drobnik
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.