* [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
* 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 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
* 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
* [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
* 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: 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
* [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
* [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
[parent not found: <6459819.4vTCxPXJkl@jkrzyszt-mobl1.ger.corp.intel.com>]
[parent not found: <fb564118-4afb-6f4a-03cc-34e255b871ef@intel.com>]
* 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.