[igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads

[igt-dev] [PATCH i-g-t v2 0/2] tests/gem_exec_fence: Fix test_fence_await for hanging workloads

[Karolina Drobnik]

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

[igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Kamil Konieczny]

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
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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);
>  
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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);
>>   
>>
> 
> 
> 
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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);
> >>   
> >>
> > 
> > 
> > 
> > 
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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
> > 
> 

[igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request

[Karolina Drobnik]

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

Re: [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_exec_fence: Coordinate sleep with the start of the request

[Kamil Konieczny]

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
> 

[igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)

[Patchwork]

[-- 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 --]

Re: [igt-dev] ✗ Fi.CI.BAT: failure for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)

[Karolina Drobnik]

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
> 

[igt-dev] ✓ Fi.CI.BAT: success for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)

[Patchwork]

[-- 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 --]

[igt-dev] ✓ Fi.CI.IGT: success for tests/gem_exec_fence: Fix test_fence_await for hanging workloads (rev2)

[Patchwork]

[-- 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 --]

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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
> >>
> > 
> > 
> > 
> > 
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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
>>>>
>>>
>>>
>>>
>>>
>>
> 
> 
> 
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> > 
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Janusz Krzysztofik]

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
> 

Re: [igt-dev] [PATCH i-g-t v2 1/2] tests/gem_exec_fence: Check stored values only for valid workloads

[Karolina Drobnik]

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
>