[Intel-gfx] [PATCH 0/1] Fix Guc-Err-Capture sizing warning

[Intel-gfx] [PATCH 0/1] Fix Guc-Err-Capture sizing warning

[Alan Previn]

GuC Error capture initialization calculates an estimation
buffer size for worst case scenario of all engines getting
reset. Fix the calculation change from drm_warn to drm_dbg
since its a corner case

Alan Previn (1):
  drm/i915/guc: Fix GuC error capture sizing estimation and reporting

 .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 31 ++++++++++++-------
 1 file changed, 19 insertions(+), 12 deletions(-)


base-commit: 0b9f0501c9541cf79fdfb43a7760360a81453d88
-- 
2.34.1

[Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Alan Previn]

During GuC error capture initialization, we estimate the amount of size
we need for the error-capture-region of the shared GuC-log-buffer.
This calculation was incorrect so fix that. Additionally, if the size
was insufficient, don't drm_warn or drm_notice, just drm_debug since
actually running out based on that estimation is a corner case. It
can only occur if all engine instances get reset all at once and i915
isn't able extract the capture data fast enough within G2H handler
worker.

Fixes d7c15d76a5547: drm/i915/guc: Check sizing of guc_capture output

Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
---
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 31 ++++++++++++-------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 8f1165146013..cb62507c91ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -502,8 +502,9 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type, u32 cl
 	if (!num_regs)
 		return -ENODATA;
 
-	*size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
-			   (num_regs * sizeof(struct guc_mmio_reg)));
+	if (size)
+		*size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
+				   (num_regs * sizeof(struct guc_mmio_reg)));
 
 	return 0;
 }
@@ -606,7 +607,7 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
 	struct intel_gt *gt = guc_to_gt(guc);
 	struct intel_engine_cs *engine;
 	enum intel_engine_id id;
-	int worst_min_size = 0, num_regs = 0;
+	int worst_min_size = 0;
 	size_t tmp = 0;
 
 	if (!guc->capture)
@@ -628,20 +629,18 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
 					 (3 * sizeof(struct guc_state_capture_header_t));
 
 		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, &tmp))
-			num_regs += tmp;
+			worst_min_size += tmp;
 
 		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
 						   engine->class, &tmp)) {
-			num_regs += tmp;
+			worst_min_size += tmp;
 		}
 		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
 						   engine->class, &tmp)) {
-			num_regs += tmp;
+			worst_min_size += tmp;
 		}
 	}
 
-	worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
-
 	return worst_min_size;
 }
 
@@ -658,15 +657,23 @@ static void check_guc_capture_size(struct intel_guc *guc)
 	int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
 	u32 buffer_size = intel_guc_log_section_size_capture(&guc->log);
 
+	/*
+	 * Don't drm_warn or drm_error here on "possible" insufficient size because we only run out
+	 * of space if all engines were to suffer resets all at once AND the driver is not able to
+	 * extract that data fast enough in the interrupt handler worker (moving them to the
+	 * larger pool of pre-allocated capture nodes. If GuC does run out of space, we will
+	 * print an error when processing the G2H event capture-notification (search for
+	 * "INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_NOSPACE").
+	 */
 	if (min_size < 0)
 		drm_warn(&i915->drm, "Failed to calculate GuC error state capture buffer minimum size: %d!\n",
 			 min_size);
 	else if (min_size > buffer_size)
-		drm_warn(&i915->drm, "GuC error state capture buffer is too small: %d < %d\n",
-			 buffer_size, min_size);
+		drm_dbg(&i915->drm, "GuC error state capture buffer maybe small: %d < %d\n",
+			buffer_size, min_size);
 	else if (spare_size > buffer_size)
-		drm_notice(&i915->drm, "GuC error state capture buffer maybe too small: %d < %d (min = %d)\n",
-			   buffer_size, spare_size, min_size);
+		drm_dbg(&i915->drm, "GuC error state capture buffer lacks spare size: %d < %d (min = %d)\n",
+			buffer_size, spare_size, min_size);
 }
 
 /*
-- 
2.34.1

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[John Harrison]

On 9/29/2022 18:05, Alan Previn wrote:
> During GuC error capture initialization, we estimate the amount of size
> we need for the error-capture-region of the shared GuC-log-buffer.
> This calculation was incorrect so fix that. Additionally, if the size
> was insufficient, don't drm_warn or drm_notice, just drm_debug since
> actually running out based on that estimation is a corner case. It
> can only occur if all engine instances get reset all at once and i915
> isn't able extract the capture data fast enough within G2H handler
> worker.
>
> Fixes d7c15d76a5547: drm/i915/guc: Check sizing of guc_capture output
>
> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
>   .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 31 ++++++++++++-------
>   1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 8f1165146013..cb62507c91ce 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -502,8 +502,9 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type, u32 cl
>   	if (!num_regs)
>   		return -ENODATA;
>   
> -	*size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
> -			   (num_regs * sizeof(struct guc_mmio_reg)));
> +	if (size)
> +		*size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
> +				   (num_regs * sizeof(struct guc_mmio_reg)));
>   
>   	return 0;
>   }
> @@ -606,7 +607,7 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
>   	struct intel_gt *gt = guc_to_gt(guc);
>   	struct intel_engine_cs *engine;
>   	enum intel_engine_id id;
> -	int worst_min_size = 0, num_regs = 0;
> +	int worst_min_size = 0;
>   	size_t tmp = 0;
>   
>   	if (!guc->capture)
> @@ -628,20 +629,18 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
>   					 (3 * sizeof(struct guc_state_capture_header_t));
>   
>   		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, &tmp))
> -			num_regs += tmp;
> +			worst_min_size += tmp;
>   
>   		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
>   						   engine->class, &tmp)) {
> -			num_regs += tmp;
> +			worst_min_size += tmp;
>   		}
>   		if (!intel_guc_capture_getlistsize(guc, 0, GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
>   						   engine->class, &tmp)) {
> -			num_regs += tmp;
> +			worst_min_size += tmp;
>   		}
>   	}
>   
> -	worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
> -
>   	return worst_min_size;
>   }
>   
> @@ -658,15 +657,23 @@ static void check_guc_capture_size(struct intel_guc *guc)
>   	int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
>   	u32 buffer_size = intel_guc_log_section_size_capture(&guc->log);
>   
> +	/*
> +	 * Don't drm_warn or drm_error here on "possible" insufficient size because we only run out
> +	 * of space if all engines were to suffer resets all at once AND the driver is not able to
> +	 * extract that data fast enough in the interrupt handler worker (moving them to the
> +	 * larger pool of pre-allocated capture nodes. If GuC does run out of space, we will
> +	 * print an error when processing the G2H event capture-notification (search for
> +	 * "INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_NOSPACE").
> +	 */
>   	if (min_size < 0)
>   		drm_warn(&i915->drm, "Failed to calculate GuC error state capture buffer minimum size: %d!\n",
>   			 min_size);
>   	else if (min_size > buffer_size)
> -		drm_warn(&i915->drm, "GuC error state capture buffer is too small: %d < %d\n",
> -			 buffer_size, min_size);
> +		drm_dbg(&i915->drm, "GuC error state capture buffer maybe small: %d < %d\n",
> +			buffer_size, min_size);
Isn't min_size the bare minimum to get a valid capture? Surely this 
still needs to be a warning not a debug. If we can't manage a basic 
working error capture then there is a problem. This needs to be caught 
by CI and logged as a bug if it is ever hit. And that means an end user 
should never see it fire because we won't let a driver out the door 
unless the default buffer size is sufficient.

John.

>   	else if (spare_size > buffer_size)
> -		drm_notice(&i915->drm, "GuC error state capture buffer maybe too small: %d < %d (min = %d)\n",
> -			   buffer_size, spare_size, min_size);
> +		drm_dbg(&i915->drm, "GuC error state capture buffer lacks spare size: %d < %d (min = %d)\n",
> +			buffer_size, spare_size, min_size);
>   }
>   
>   /*

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Teres Alexis, Alan Previn]

I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
would just discard the ones after the first one and so it wouldnt even matter if we did catch it.

But I'll go ahead and re-rev this.
...alan

On Fri, 2022-09-30 at 10:48 -0700, Harrison, John C wrote:
> Isn't min_size the bare minimum to get a valid capture? Surely this 
> still needs to be a warning not a debug. If we can't manage a basic 
> working error capture then there is a problem. This needs to be caught 
> by CI and logged as a bug if it is ever hit. And that means an end user 
> should never see it fire because we won't let a driver out the door 
> unless the default buffer size is sufficient.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[John Harrison]

On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
> point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
> would just discard the ones after the first one and so it wouldnt even matter if we did catch it.
So min_size is not actually the minimal size for a meaningful capture? 
So what is? And remember that for compute class engines, there is 
dependent engine reset. So a reset of CCS2 also means a reset of RCS, 
CCS0, CCS1 and CCS3. So having at least four engines per capture is not 
unreasonable.

It seems pointless to go through a lot of effort to calculate the 
minimum and recommend sizes only to basically ignore them by just 
whispering very, very quietly that there might be a problem. It also 
seems pointless to complain about a minimum size that actually isn't the 
minimum size. That's sort of worse - now you are telling the user there 
is a problem when really there isn't.

IMHO, the min_size check should be meaningful and should be visible to 
the user if it fails.

Also, are we still hitting the minimum size failure message? Now that 
the calculation has been fixed, what sizes does it come up with for min 
and spare? Are they within the allocation now or not?

John.


> But I'll go ahead and re-rev this.
> ...alan
>
> On Fri, 2022-09-30 at 10:48 -0700, Harrison, John C wrote:
>> Isn't min_size the bare minimum to get a valid capture? Surely this
>> still needs to be a warning not a debug. If we can't manage a basic
>> working error capture then there is a problem. This needs to be caught
>> by CI and logged as a bug if it is ever hit. And that means an end user
>> should never see it fire because we won't let a driver out the door
>> unless the default buffer size is sufficient.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Teres Alexis, Alan Previn]

On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
> > point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
> > would just discard the ones after the first one and so it wouldnt even matter if we did catch it.
> So min_size is not actually the minimal size for a meaningful capture? 
> So what is? And remember that for compute class engines, there is 
> dependent engine reset. So a reset of CCS2 also means a reset of RCS, 
> CCS0, CCS1 and CCS3. So having at least four engines per capture is not 
> unreasonable.
> 
Alan: min_size is a meaningful size for the worst case scenario of collecting the guc-report. However due to gpu-core-
dump, its not meaningful in terms of reporting that information out to the user. Thats not a limitation of this
subsystem.

> It seems pointless to go through a lot of effort to calculate the 
> minimum and recommend sizes only to basically ignore them by just 
> whispering very, very quietly that there might be a problem.
> 
Alan: I already responded that i will re-rev as per your recommendation and switch back to drm_notice.

> It also 
> seems pointless to complain about a minimum size that actually isn't the 
> minimum size. That's sort of worse - now you are telling the user there 
> is a problem when really there isn't.
> 
Alan: the min size is accurate - but whether we report to the use about them possibly facing a problem is where it gets
a bit unclear because of the limitation in the gpu-core-dump framework. We could drop the message completely if you like
- but then we'd have to remember to re-add it if we fix gpu-core-dump in future. For now, as i mentioned in the last
reply, i have already changed it back to "notice" as per your last comment. Perhaps you should have looked at rev2 which
was posted before your responses above. As mentioned in last reply, i disagreed but i am committing to your request
which was fixed in rev2 as per your request.

> IMHO, the min_size check should be meaningful and should be visible to 
> the user if it fails.
> 
> Also, are we still hitting the minimum size failure message? Now that 
> the calculation has been fixed, what sizes does it come up with for min 
> and spare? Are they within the allocation now or not?
> 
Yes - we are within the allocation with this patch (the fix of removing the redundant register-struct-size
multiplication brought the number down significantly).

> John.

So how would you like to proceed? Could we reply on rev2 btw?

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[John Harrison]

On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
>> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
>>> I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
>>> point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
>>> would just discard the ones after the first one and so it wouldnt even matter if we did catch it.
>> So min_size is not actually the minimal size for a meaningful capture?
>> So what is? And remember that for compute class engines, there is
>> dependent engine reset. So a reset of CCS2 also means a reset of RCS,
>> CCS0, CCS1 and CCS3. So having at least four engines per capture is not
>> unreasonable.
>>
> Alan: min_size is a meaningful size for the worst case scenario of collecting the guc-report. However due to gpu-core-
> dump, its not meaningful in terms of reporting that information out to the user. Thats not a limitation of this
> subsystem.
I'm not following what you mean about gpu-core-dump. The point of the 
warning is to let the user know that the interface they want to use 
(error capture via sysfs) might not be complete in the majority of 
cases. If there is some catastrophic worst case scenario that overflows 
but 99% of instances are fine then that's what the drm_notice about 
'spare_size' is for. But if the 99% of instances of a capture are going 
to overflow then that is what the drm_warn about 'min_size' should be for.

>> It seems pointless to go through a lot of effort to calculate the
>> minimum and recommend sizes only to basically ignore them by just
>> whispering very, very quietly that there might be a problem.
>>
> Alan: I already responded that i will re-rev as per your recommendation and switch back to drm_notice.
>
>> It also
>> seems pointless to complain about a minimum size that actually isn't the
>> minimum size. That's sort of worse - now you are telling the user there
>> is a problem when really there isn't.
>>
> Alan: the min size is accurate - but whether we report to the use about them possibly facing a problem is where it gets
> a bit unclear because of the limitation in the gpu-core-dump framework. We could drop the message completely if you like
> - but then we'd have to remember to re-add it if we fix gpu-core-dump in future. For now, as i mentioned in the last
What limitation in the 'gpu-core-dump framework'? What is the fix required?

> reply, i have already changed it back to "notice" as per your last comment. Perhaps you should have looked at rev2 which
> was posted before your responses above. As mentioned in last reply, i disagreed but i am committing to your request
> which was fixed in rev2 as per your request.
The point of a code review is not "I say X so you must do X, immediately 
post a new revision now". I asked some questions. I stated my opinion 
about what the end user should see. If you think your implementation 
already matches that or you disagree because you think I am basing my 
comments on incorrect information, or even just that you disagree with 
my reasoning, then you should not blindly post a new revision saying 
"here are your changes, I don't like it because Y but just r-b it and 
I'll merge". You should reply to the comments with your thoughts and 
suggestions. Maybe the reviewer is wrong!

>> IMHO, the min_size check should be meaningful and should be visible to
>> the user if it fails.
>>
>> Also, are we still hitting the minimum size failure message? Now that
>> the calculation has been fixed, what sizes does it come up with for min
>> and spare? Are they within the allocation now or not?
>>
> Yes - we are within the allocation with this patch (the fix of removing the redundant register-struct-size
> multiplication brought the number down significantly).
Bringing in comment from other thread:
 > Some context: with the calculation fix we are allocating 4MB but we 
only need 78k as min-est.

Wow! That is quite a big smaller. And much more plausible! So if 
min_size is 78KB, what is spare_size now?

Sounds like we can drop it down to a 1MB allocation. And even if 
min_size is not the absolute minimum but quite a bit more worst case 
kind of size, it still seems reasonable to keep it as a warning rather 
than a notice. Given that it is so much smaller than the allocation 
size, if it does somehow overflow on some platform/configuration then 
that sounds like something we should know about because it likely means 
something is broken.


>> John.
> So how would you like to proceed? Could we reply on rev2 btw?
I would like to answer the questions/concerns before jumping in to 
writing/re-writing code.

Why split the email thread? The discussion is already happening here. 
There is no point splitting a single discussion across multiple patch 
sets just because a new patch has been posted if that patch does not 
actually change the discussion.

John.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Teres Alexis, Alan Previn]

On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
> > > > point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
> > > > would just discard the ones after the first one and so it wouldnt even matter if we did catch it.
> > > So min_size is not actually the minimal size for a meaningful capture?
> > > So what is? And remember that for compute class engines, there is
> > > dependent engine reset. So a reset of CCS2 also means a reset of RCS,
> > > CCS0, CCS1 and CCS3. So having at least four engines per capture is not
> > > unreasonable.
> > > 
> > Alan: min_size is a meaningful size for the worst case scenario of collecting the guc-report. However due to gpu-core-
> > dump, its not meaningful in terms of reporting that information out to the user. Thats not a limitation of this
> > subsystem.
> I'm not following what you mean about gpu-core-dump. The point of the 
> warning is to let the user know that the interface they want to use 
> (error capture via sysfs) might not be complete in the majority of 
> cases. If there is some catastrophic worst case scenario that overflows 
> but 99% of instances are fine then that's what the drm_notice about 
> 'spare_size' is for. But if the 99% of instances of a capture are going 
> to overflow then that is what the drm_warn about 'min_size' should be for.
> 
> > > It seems pointless to go through a lot of effort to calculate the
> > > minimum and recommend sizes only to basically ignore them by just
> > > whispering very, very quietly that there might be a problem.
> > > 
> > Alan: I already responded that i will re-rev as per your recommendation and switch back to drm_notice.
> > 
> > > It also
> > > seems pointless to complain about a minimum size that actually isn't the
> > > minimum size. That's sort of worse - now you are telling the user there
> > > is a problem when really there isn't.
> > > 
> > Alan: the min size is accurate - but whether we report to the use about them possibly facing a problem is where it gets
> > a bit unclear because of the limitation in the gpu-core-dump framework. We could drop the message completely if you like
> > - but then we'd have to remember to re-add it if we fix gpu-core-dump in future. For now, as i mentioned in the last
> What limitation in the 'gpu-core-dump framework'? What is the fix required?
> 
Unless it has changed since i last looked at it, gpu_coredump framework will store the first error-state captured and
wait until the user extracts it via sysfs. Any other error-state capture that gets created before that prior one was
cleared by the user gets dropped. I'm not sure if that limitation needs to be "fixed". I am not sure of its history -
maybe it was designed that way for a reason. ATM I dont have the bandwidth to chase that history down.

> > reply, i have already changed it back to "notice" as per your last comment. Perhaps you should have looked at rev2 which
> > was posted before your responses above. As mentioned in last reply, i disagreed but i am committing to your request
> > which was fixed in rev2 as per your request.
> The point of a code review is not "I say X so you must do X, immediately 
> post a new revision now". I asked some questions. I stated my opinion 
> about what the end user should see. If you think your implementation 
> already matches that or you disagree because you think I am basing my 
> comments on incorrect information, or even just that you disagree with 
> my reasoning, then you should not blindly post a new revision saying 
> "here are your changes, I don't like it because Y but just r-b it and 
> I'll merge". You should reply to the comments with your thoughts and 
> suggestions. Maybe the reviewer is wrong!
> 
I think this comes down to preference as there is no clear rule about what is right vs what is wrong in this case:

	- we have a possible issue but its a corner case when all engine instances suffer a reset all at once.
	- in the event of that corner case occurring, the end-user could go back and increase the guc-log-capture-
region size and thus the warning will go away and GuC will have space to report the error-state dump for all engine
instances if they got reset all at once (within the same G2H IRQ event).
	- assuming the issue is reproducible, the user, now happy that the warning is resolved, reruns the workload.
The
user dumps the first error-state-capture via sysfs which only contains info for the first engine that was reset (as it
appeared in the G2H-CTB). the user inspects the same sysfs and none of the other dmesg-reported engine-hang error-state-
dumps seem to be made available in the sysfs after clearing that first one.

so the preference here becomes "should we warn the user about this possible event of running out of guc-error-state
capture region when resolving it still doesn't allow the user to get it anyway"... OR "should we just make a quiet debug
message about it since an i915 developer knows that the gpu_coredump framework design can only ever store 1 error-state-
capture-dump and throws the rest away until its cleared by the user via sysfs".

My preference is the latter. However, just to be clear, with the fixed calculation, we'll probably never see the
warning(or-debug) message with the HW that we have today and the foreseeable future.

> > > IMHO, the min_size check should be meaningful and should be visible to
> > > the user if it fails.
> > > 
> > > Also, are we still hitting the minimum size failure message? Now that
> > > the calculation has been fixed, what sizes does it come up with for min
> > > and spare? Are they within the allocation now or not?
> > > 
> > Yes - we are within the allocation with this patch (the fix of removing the redundant register-struct-size
> > multiplication brought the number down significantly).
> Bringing in comment from other thread:
>  > Some context: with the calculation fix we are allocating 4MB but we 
> only need 78k as min-est.
> 
> Wow! That is quite a big smaller. And much more plausible! So if 
> min_size is 78KB, what is spare_size now?
> 
Around 230K. (the min_est was exactly 78504 bytes or 76.664Kb - that was based on a DG2 - i think it was a 384 - cant
recall for sure)

> Sounds like we can drop it down to a 1MB allocation.
> 
Okay - will do a 3rd rev with a 1MB change.

> And even if 
> min_size is not the absolute minimum but quite a bit more worst case 
> kind of size, it still seems reasonable to keep it as a warning rather 
> than a notice. Given that it is so much smaller than the allocation 
> size, if it does somehow overflow on some platform/configuration then 
> that sounds like something we should know about because it likely means 
> something is broken.

Okay - this works fine too since we probably will likely never trigger that message until we have significantly more
engine instances than todays hw.
> 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[John Harrison]

On 10/3/2022 14:10, Teres Alexis, Alan Previn wrote:
> On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
>> On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
>>> On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
>>>> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
>>>>> I disagree because its unlikely that all engines can reset all at once (we probably have bigger problems at the at
>>>>> point) and if they all occurred within the same G2H handler scheduled worker run, our current gpu_coredump framework
>>>>> would just discard the ones after the first one and so it wouldnt even matter if we did catch it.
>>>> So min_size is not actually the minimal size for a meaningful capture?
>>>> So what is? And remember that for compute class engines, there is
>>>> dependent engine reset. So a reset of CCS2 also means a reset of RCS,
>>>> CCS0, CCS1 and CCS3. So having at least four engines per capture is not
>>>> unreasonable.
>>>>
>>> Alan: min_size is a meaningful size for the worst case scenario of collecting the guc-report. However due to gpu-core-
>>> dump, its not meaningful in terms of reporting that information out to the user. Thats not a limitation of this
>>> subsystem.
>> I'm not following what you mean about gpu-core-dump. The point of the
>> warning is to let the user know that the interface they want to use
>> (error capture via sysfs) might not be complete in the majority of
>> cases. If there is some catastrophic worst case scenario that overflows
>> but 99% of instances are fine then that's what the drm_notice about
>> 'spare_size' is for. But if the 99% of instances of a capture are going
>> to overflow then that is what the drm_warn about 'min_size' should be for.
>>
>>>> It seems pointless to go through a lot of effort to calculate the
>>>> minimum and recommend sizes only to basically ignore them by just
>>>> whispering very, very quietly that there might be a problem.
>>>>
>>> Alan: I already responded that i will re-rev as per your recommendation and switch back to drm_notice.
>>>
>>>> It also
>>>> seems pointless to complain about a minimum size that actually isn't the
>>>> minimum size. That's sort of worse - now you are telling the user there
>>>> is a problem when really there isn't.
>>>>
>>> Alan: the min size is accurate - but whether we report to the use about them possibly facing a problem is where it gets
>>> a bit unclear because of the limitation in the gpu-core-dump framework. We could drop the message completely if you like
>>> - but then we'd have to remember to re-add it if we fix gpu-core-dump in future. For now, as i mentioned in the last
>> What limitation in the 'gpu-core-dump framework'? What is the fix required?
>>
> Unless it has changed since i last looked at it, gpu_coredump framework will store the first error-state captured and
> wait until the user extracts it via sysfs. Any other error-state capture that gets created before that prior one was
> cleared by the user gets dropped. I'm not sure if that limitation needs to be "fixed". I am not sure of its history -
> maybe it was designed that way for a reason. ATM I dont have the bandwidth to chase that history down.
That is by design. Generally speaking, you want to see the first error 
that occurred. If there were a bunch back to back then likely the first 
one is the real problem and the rest are either symptoms or repeat 
offences of the first.

Also, in the case where a user doesn't know what an error capture is but 
they are running (or developing) some app that keeps dying and produces 
core dumps, you can't just swallow all system memory in a linked list of 
error captures that won't ever be read out and freed up.

Hence the design is to save the first and hold on to it until read out. 
And if any further hangs happen before the current one is cleared, they 
are discarded as uninteresting if not plain old spam.

>
>>> reply, i have already changed it back to "notice" as per your last comment. Perhaps you should have looked at rev2 which
>>> was posted before your responses above. As mentioned in last reply, i disagreed but i am committing to your request
>>> which was fixed in rev2 as per your request.
>> The point of a code review is not "I say X so you must do X, immediately
>> post a new revision now". I asked some questions. I stated my opinion
>> about what the end user should see. If you think your implementation
>> already matches that or you disagree because you think I am basing my
>> comments on incorrect information, or even just that you disagree with
>> my reasoning, then you should not blindly post a new revision saying
>> "here are your changes, I don't like it because Y but just r-b it and
>> I'll merge". You should reply to the comments with your thoughts and
>> suggestions. Maybe the reviewer is wrong!
>>
> I think this comes down to preference as there is no clear rule about what is right vs what is wrong in this case:
>
> 	- we have a possible issue but its a corner case when all engine instances suffer a reset all at once.
> 	- in the event of that corner case occurring, the end-user could go back and increase the guc-log-capture-
> region size and thus the warning will go away and GuC will have space to report the error-state dump for all engine
> instances if they got reset all at once (within the same G2H IRQ event).
> 	- assuming the issue is reproducible, the user, now happy that the warning is resolved, reruns the workload.
> The
> user dumps the first error-state-capture via sysfs which only contains info for the first engine that was reset (as it
> appeared in the G2H-CTB). the user inspects the same sysfs and none of the other dmesg-reported engine-hang error-state-
> dumps seem to be made available in the sysfs after clearing that first one.
>
> so the preference here becomes "should we warn the user about this possible event of running out of guc-error-state
> capture region when resolving it still doesn't allow the user to get it anyway"... OR "should we just make a quiet debug
> message about it since an i915 developer knows that the gpu_coredump framework design can only ever store 1 error-state-
> capture-dump and throws the rest away until its cleared by the user via sysfs".
>
> My preference is the latter. However, just to be clear, with the fixed calculation, we'll probably never see the
> warning(or-debug) message with the HW that we have today and the foreseeable future.

The warning isn't meant to be for i915 developers who understand bizarre 
internal workings of the driver. The warning is meant to be for end 
users who might not be able to debug their applications.

Given that the error capture interface is fundamentally only really 
concerned about obtaining a single valid capture at a time. I would 
argue that supporting a dozen back-to-back captures is no more than a 
nice-to-have convenience for a very rare situation (such as the user has 
explicitly modified their kernel to save all the captures in a list). 
And that back-to-back scenario is the 'spare_size', not 'min_size' isn't 
it? So there is no need for a warning about that. A notice is fine but 
not a warning.

The thing that really, really, really matters to an end user is that the 
first capture of a session is complete and useful. So my view is that 
any warning message should be focused on that. Can we get one complete 
error capture for one complete set of engines? If not, that is something 
we should warn about. And that is what 'min_size' should be.

Note that 'one complete set of engines' really only means five on 
current hardware - RCS + CCS0-3 is the most that can reset at one time 
(due to dependent engine resets) given that GuC managed resets are 
context based and a context can only run on one engine. Although I think 
it is technically possible for more engines to be involved but that 
would also count as hard to hit a corner case. And given the small size 
involved, it might be simplest just to base min_size on all engines anyway.



>>>> IMHO, the min_size check should be meaningful and should be visible to
>>>> the user if it fails.
>>>>
>>>> Also, are we still hitting the minimum size failure message? Now that
>>>> the calculation has been fixed, what sizes does it come up with for min
>>>> and spare? Are they within the allocation now or not?
>>>>
>>> Yes - we are within the allocation with this patch (the fix of removing the redundant register-struct-size
>>> multiplication brought the number down significantly).
>> Bringing in comment from other thread:
>>   > Some context: with the calculation fix we are allocating 4MB but we
>> only need 78k as min-est.
>>
>> Wow! That is quite a big smaller. And much more plausible! So if
>> min_size is 78KB, what is spare_size now?
>>
> Around 230K. (the min_est was exactly 78504 bytes or 76.664Kb - that was based on a DG2 - i think it was a 384 - cant
> recall for sure)
Might be worth checking on PVC. That could be getting close to 1MB with 
all the extra blitter engines.

>
>> Sounds like we can drop it down to a 1MB allocation.
>>
> Okay - will do a 3rd rev with a 1MB change.
Don't start writing anything yet. Let's get to a final decision on the 
plan first.

>
>> And even if
>> min_size is not the absolute minimum but quite a bit more worst case
>> kind of size, it still seems reasonable to keep it as a warning rather
>> than a notice. Given that it is so much smaller than the allocation
>> size, if it does somehow overflow on some platform/configuration then
>> that sounds like something we should know about because it likely means
>> something is broken.
> Okay - this works fine too since we probably will likely never trigger that message until we have significantly more
> engine instances than todays hw.
See above about PVC.

John.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Teres Alexis, Alan Previn]

So as per the last response and the offline conversation we had we agreed that:

1. we shall stick with drm_warn( ... maybe too small...) if the allocation didn't meet min_size.
2. I'll model for PVC (since its better to look at the spec as opposed to trying to hunt for a free machine with the
most engines and DSS (for those steering registers that are counted multiple times).
3. If #2 yields us with substantial headroom (i.e. a model's PVC would be less than 700K min_size), then lets drop to
1MB allocation.

...alan


On Mon, 2022-10-03 at 16:51 -0700, Harrison, John C wrote:
> On 10/3/2022 14:10, Teres Alexis, Alan Previn wrote:
> > On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> > > On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > > > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > > 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[John Harrison]

On 10/3/2022 17:46, Teres Alexis, Alan Previn wrote:
> So as per the last response and the offline conversation we had we agreed that:
>
> 1. we shall stick with drm_warn( ... maybe too small...) if the allocation didn't meet min_size.
> 2. I'll model for PVC (since its better to look at the spec as opposed to trying to hunt for a free machine with the
> most engines and DSS (for those steering registers that are counted multiple times).
> 3. If #2 yields us with substantial headroom (i.e. a model's PVC would be less than 700K min_size), then lets drop to
> 1MB allocation.
>
> ...alan
Sounds good to me.

John.

>
>
> On Mon, 2022-10-03 at 16:51 -0700, Harrison, John C wrote:
>> On 10/3/2022 14:10, Teres Alexis, Alan Previn wrote:
>>> On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
>>>> On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
>>>>> On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
>>>>>> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
>>>>>>

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

[Teres Alexis, Alan Previn]

Hi John, tested on real PVC and the estimated min size needed was ~115K. Even without modelling, we can safely say that
an imaginary device with a tile that is 4x bigger would still be half than 1 MB. That said I shall proceed with a re-rev
that shall include dropping the size of guc-log-error-capture-region down to 1MB in addition to sticking with the
"drm_warn(...mayb too small)" and ofc rebasing to latest drm-tip. Shall rerun some tests just in case - so will get it
out later this week.

...alan

On Mon, 2022-10-03 at 18:51 -0700, Harrison, John C wrote:
> On 10/3/2022 17:46, Teres Alexis, Alan Previn wrote:
> > So as per the last response and the offline conversation we had we agreed that:
> > 
> > 1. we shall stick with drm_warn( ... maybe too small...) if the allocation didn't meet min_size.
> > 2. I'll model for PVC (since its better to look at the spec as opposed to trying to hunt for a free machine with the
> > most engines and DSS (for those steering registers that are counted multiple times).
> > 3. If #2 yields us with substantial headroom (i.e. a model's PVC would be less than 700K min_size), then lets drop to
> > 1MB allocation.
> > 
> > ...alan
> Sounds good to me.
> 
> John.
> 
> > 
> > 
> > On Mon, 2022-10-03 at 16:51 -0700, Harrison, John C wrote:
> > > On 10/3/2022 14:10, Teres Alexis, Alan Previn wrote:
> > > > On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> > > > > On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > > > > > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > > > > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > > > > 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix Guc-Err-Capture sizing warning

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

== Series Details ==

Series: Fix Guc-Err-Capture sizing warning
URL   : https://patchwork.freedesktop.org/series/109276/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12202 -> Patchwork_109276v1
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/index.html

Participating hosts (47 -> 43)
------------------------------

  Missing    (4): fi-ctg-p8600 bat-dg2-9 fi-bdw-samus fi-hsw-4200u 

Known issues
------------

  Here are the changes found in Patchwork_109276v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
    - fi-bsw-kefka:       [PASS][1] -> [FAIL][2] ([i915#6298])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@gt_pm:
    - {bat-rpls-2}:       [DMESG-FAIL][3] ([i915#4258]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298


Build changes
-------------

  * Linux: CI_DRM_12202 -> Patchwork_109276v1

  CI-20190529: 20190529
  CI_DRM_12202: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6670: d618e9865fe5cbaf511ca43503abad442605d0a5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109276v1: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

aa3aa2f83b0c drm/i915/guc: Fix GuC error capture sizing estimation and reporting

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/index.html

[-- Attachment #2: Type: text/html, Size: 3085 bytes --]

[Intel-gfx] ✓ Fi.CI.IGT: success for Fix Guc-Err-Capture sizing warning

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 30958 bytes --]

== Series Details ==

Series: Fix Guc-Err-Capture sizing warning
URL   : https://patchwork.freedesktop.org/series/109276/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12202_full -> Patchwork_109276v1_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
------------------------------

  No changes in participating hosts

Known issues
------------

  Here are the changes found in Patchwork_109276v1_full that come from known issues:

### CI changes ###

#### Issues hit ####

  * boot:
    - shard-apl:          ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [FAIL][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4386])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl1/boot.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/boot.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/boot.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/boot.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl3/boot.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl3/boot.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl3/boot.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl1/boot.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl2/boot.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl2/boot.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl2/boot.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl2/boot.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl1/boot.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl1/boot.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl1/boot.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl8/boot.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl8/boot.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl8/boot.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl8/boot.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl8/boot.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl7/boot.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl7/boot.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl7/boot.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl7/boot.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/boot.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl1/boot.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl1/boot.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl1/boot.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl1/boot.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl2/boot.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl2/boot.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl2/boot.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl2/boot.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl2/boot.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/boot.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/boot.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/boot.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/boot.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl6/boot.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl6/boot.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl6/boot.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl6/boot.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl7/boot.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl7/boot.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl7/boot.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl7/boot.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/boot.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/boot.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/boot.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/boot.html
    - shard-glk:          ([PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59], [PASS][60], [PASS][61], [PASS][62], [PASS][63], [PASS][64], [PASS][65], [PASS][66], [PASS][67], [PASS][68], [PASS][69], [PASS][70], [PASS][71], [PASS][72], [PASS][73], [PASS][74], [PASS][75]) -> ([PASS][76], [PASS][77], [PASS][78], [PASS][79], [PASS][80], [PASS][81], [PASS][82], [PASS][83], [PASS][84], [PASS][85], [PASS][86], [PASS][87], [PASS][88], [PASS][89], [PASS][90], [PASS][91], [PASS][92], [PASS][93], [FAIL][94], [PASS][95], [PASS][96], [PASS][97], [PASS][98], [PASS][99]) ([i915#4392])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk9/boot.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk9/boot.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk8/boot.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk8/boot.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk8/boot.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk7/boot.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk7/boot.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk7/boot.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk6/boot.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk6/boot.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk6/boot.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk5/boot.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk5/boot.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk5/boot.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk3/boot.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk3/boot.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk3/boot.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk3/boot.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk2/boot.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk2/boot.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk2/boot.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk2/boot.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk1/boot.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk1/boot.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk1/boot.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk1/boot.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk1/boot.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk1/boot.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk2/boot.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk2/boot.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk2/boot.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk3/boot.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk3/boot.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk5/boot.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk5/boot.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/boot.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/boot.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/boot.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/boot.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk7/boot.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk7/boot.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk7/boot.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk8/boot.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk8/boot.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk8/boot.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk8/boot.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk9/boot.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk9/boot.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk9/boot.html

  

### IGT changes ###

#### Issues hit ####

  * igt@feature_discovery@display-4x:
    - shard-tglb:         NOTRUN -> [SKIP][100] ([i915#1839])
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@feature_discovery@display-4x.html

  * igt@gem_exec_balancer@parallel-contexts:
    - shard-iclb:         [PASS][101] -> [SKIP][102] ([i915#4525])
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@gem_exec_balancer@parallel-contexts.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb5/igt@gem_exec_balancer@parallel-contexts.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
    - shard-tglb:         [PASS][103] -> [FAIL][104] ([i915#2842]) +1 similar issue
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-tglb8/igt@gem_exec_fair@basic-none-share@rcs0.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb5/igt@gem_exec_fair@basic-none-share@rcs0.html
    - shard-glk:          [PASS][105] -> [FAIL][106] ([i915#2842])
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk9/igt@gem_exec_fair@basic-none-share@rcs0.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk3/igt@gem_exec_fair@basic-none-share@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
    - shard-tglb:         NOTRUN -> [FAIL][107] ([i915#2842]) +4 similar issues
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@gem_exec_fair@basic-none@bcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-iclb:         [PASS][108] -> [FAIL][109] ([i915#2842]) +2 similar issues
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_lmem_swapping@heavy-multi:
    - shard-apl:          NOTRUN -> [SKIP][110] ([fdo#109271] / [i915#4613]) +1 similar issue
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@gem_lmem_swapping@heavy-multi.html

  * igt@gem_lmem_swapping@parallel-random:
    - shard-glk:          NOTRUN -> [SKIP][111] ([fdo#109271] / [i915#4613])
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/igt@gem_lmem_swapping@parallel-random.html

  * igt@gem_vm_create@invalid-create:
    - shard-snb:          NOTRUN -> [SKIP][112] ([fdo#109271]) +25 similar issues
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-snb6/igt@gem_vm_create@invalid-create.html

  * igt@gen7_exec_parse@batch-without-end:
    - shard-tglb:         NOTRUN -> [SKIP][113] ([fdo#109289])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@gen7_exec_parse@batch-without-end.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [PASS][114] -> [FAIL][115] ([i915#3989] / [i915#454])
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb4/igt@i915_pm_dc@dc6-dpms.html
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_addfb_basic@legacy-format:
    - shard-tglb:         [PASS][116] -> [INCOMPLETE][117] ([i915#6987])
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-tglb2/igt@kms_addfb_basic@legacy-format.html
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb3/igt@kms_addfb_basic@legacy-format.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
    - shard-tglb:         NOTRUN -> [SKIP][118] ([i915#5286]) +1 similar issue
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip:
    - shard-tglb:         NOTRUN -> [SKIP][119] ([fdo#111615])
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
    - shard-apl:          NOTRUN -> [SKIP][120] ([fdo#109271] / [i915#3886])
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs_cc:
    - shard-glk:          NOTRUN -> [SKIP][121] ([fdo#109271]) +1 similar issue
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs_cc.html

  * igt@kms_ccs@pipe-d-crc-primary-rotation-180-y_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][122] ([i915#3689])
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_ccs@pipe-d-crc-primary-rotation-180-y_tiled_ccs.html

  * igt@kms_chamelium@dp-crc-single:
    - shard-apl:          NOTRUN -> [SKIP][123] ([fdo#109271] / [fdo#111827]) +1 similar issue
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@kms_chamelium@dp-crc-single.html

  * igt@kms_chamelium@hdmi-edid-read:
    - shard-tglb:         NOTRUN -> [SKIP][124] ([fdo#109284] / [fdo#111827]) +1 similar issue
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_chamelium@hdmi-edid-read.html

  * igt@kms_content_protection@atomic-dpms:
    - shard-apl:          NOTRUN -> [TIMEOUT][125] ([i915#1319])
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@kms_content_protection@atomic-dpms.html

  * igt@kms_content_protection@dp-mst-type-1:
    - shard-tglb:         NOTRUN -> [SKIP][126] ([i915#3116] / [i915#3299])
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_content_protection@dp-mst-type-1.html

  * igt@kms_cursor_crc@cursor-rapid-movement-32x32:
    - shard-tglb:         NOTRUN -> [SKIP][127] ([i915#3555])
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_cursor_crc@cursor-rapid-movement-32x32.html

  * igt@kms_flip@2x-absolute-wf_vblank-interruptible:
    - shard-tglb:         NOTRUN -> [SKIP][128] ([fdo#109274] / [fdo#111825] / [i915#3637])
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_flip@2x-absolute-wf_vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend@b-dp1:
    - shard-apl:          [PASS][129] -> [DMESG-WARN][130] ([i915#180]) +1 similar issue
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl2/igt@kms_flip@flip-vs-suspend@b-dp1.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl1/igt@kms_flip@flip-vs-suspend@b-dp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-upscaling@pipe-a-valid-mode:
    - shard-tglb:         NOTRUN -> [SKIP][131] ([i915#2587] / [i915#2672])
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-upscaling@pipe-a-valid-mode.html

  * igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode:
    - shard-iclb:         NOTRUN -> [SKIP][132] ([i915#2587] / [i915#2672]) +2 similar issues
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-default-mode:
    - shard-iclb:         NOTRUN -> [SKIP][133] ([i915#3555])
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-default-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-upscaling@pipe-a-default-mode:
    - shard-iclb:         NOTRUN -> [SKIP][134] ([i915#2672]) +6 similar issues
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-upscaling@pipe-a-default-mode.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-render:
    - shard-tglb:         NOTRUN -> [SKIP][135] ([fdo#109280] / [fdo#111825]) +5 similar issues
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu:
    - shard-tglb:         NOTRUN -> [SKIP][136] ([i915#6497])
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-indfb-plflip-blt:
    - shard-apl:          NOTRUN -> [SKIP][137] ([fdo#109271]) +35 similar issues
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@kms_frontbuffer_tracking@psr-2p-primscrn-indfb-plflip-blt.html

  * igt@kms_plane_scaling@2x-scaler-multi-pipe:
    - shard-tglb:         NOTRUN -> [SKIP][138] ([fdo#109274] / [fdo#111825])
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_plane_scaling@2x-scaler-multi-pipe.html

  * igt@kms_psr2_sf@cursor-plane-update-sf:
    - shard-apl:          NOTRUN -> [SKIP][139] ([fdo#109271] / [i915#658])
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@kms_psr2_sf@cursor-plane-update-sf.html

  * igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
    - shard-tglb:         NOTRUN -> [SKIP][140] ([i915#2920])
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_psr2_sf@overlay-plane-move-continuous-sf.html

  * igt@kms_psr@psr2_primary_blt:
    - shard-iclb:         [PASS][141] -> [SKIP][142] ([fdo#109441]) +2 similar issues
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@kms_psr@psr2_primary_blt.html
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@kms_psr@psr2_primary_blt.html

  * igt@sysfs_clients@fair-7:
    - shard-apl:          NOTRUN -> [SKIP][143] ([fdo#109271] / [i915#2994])
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl3/igt@sysfs_clients@fair-7.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
    - shard-apl:          [DMESG-WARN][144] ([i915#180]) -> [PASS][145] +1 similar issue
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/igt@gem_ctx_isolation@preservation-s3@bcs0.html
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/igt@gem_ctx_isolation@preservation-s3@bcs0.html

  * igt@gem_exec_balancer@parallel-bb-first:
    - shard-iclb:         [SKIP][146] ([i915#4525]) -> [PASS][147] +2 similar issues
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb5/igt@gem_exec_balancer@parallel-bb-first.html
   [147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb1/igt@gem_exec_balancer@parallel-bb-first.html

  * igt@gen9_exec_parse@allowed-all:
    - shard-glk:          [DMESG-WARN][148] ([i915#5566] / [i915#716]) -> [PASS][149]
   [148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk7/igt@gen9_exec_parse@allowed-all.html
   [149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk6/igt@gen9_exec_parse@allowed-all.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-b-vga-1:
    - shard-snb:          [SKIP][150] ([fdo#109271]) -> [PASS][151] +1 similar issue
   [150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-snb6/igt@kms_cursor_crc@cursor-suspend@pipe-b-vga-1.html
   [151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-snb5/igt@kms_cursor_crc@cursor-suspend@pipe-b-vga-1.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-apl:          [FAIL][152] ([i915#4767]) -> [PASS][153]
   [152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/igt@kms_fbcon_fbt@fbc-suspend.html
   [153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl7/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1:
    - shard-iclb:         [SKIP][154] ([i915#5176]) -> [PASS][155] +2 similar issues
   [154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1.html
   [155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1.html

  * igt@kms_psr2_su@page_flip-xrgb8888:
    - shard-iclb:         [SKIP][156] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [PASS][157]
   [156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb1/igt@kms_psr2_su@page_flip-xrgb8888.html
   [157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb2/igt@kms_psr2_su@page_flip-xrgb8888.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [SKIP][158] ([fdo#109441]) -> [PASS][159] +2 similar issues
   [158]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html
   [159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html

  * igt@kms_psr_stress_test@flip-primary-invalidate-overlay:
    - shard-iclb:         [SKIP][160] ([i915#5519]) -> [PASS][161]
   [160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb7/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
   [161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb8/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html

  * igt@kms_rotation_crc@sprite-rotation-180:
    - shard-tglb:         [INCOMPLETE][162] -> [PASS][163]
   [162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-tglb8/igt@kms_rotation_crc@sprite-rotation-180.html
   [163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-tglb7/igt@kms_rotation_crc@sprite-rotation-180.html

  * igt@kms_vblank@pipe-c-accuracy-idle:
    - shard-glk:          [FAIL][164] ([i915#43]) -> [PASS][165]
   [164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-glk5/igt@kms_vblank@pipe-c-accuracy-idle.html
   [165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-glk8/igt@kms_vblank@pipe-c-accuracy-idle.html

  * igt@perf@polling-parameterized:
    - shard-apl:          [FAIL][166] ([i915#5639]) -> [PASS][167]
   [166]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-apl6/igt@perf@polling-parameterized.html
   [167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-apl8/igt@perf@polling-parameterized.html

  
#### Warnings ####

  * igt@gem_exec_balancer@parallel-ordering:
    - shard-iclb:         [FAIL][168] ([i915#6117]) -> [SKIP][169] ([i915#4525])
   [168]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@gem_exec_balancer@parallel-ordering.html
   [169]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@gem_exec_balancer@parallel-ordering.html

  * igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
    - shard-iclb:         [SKIP][170] ([i915#658]) -> [SKIP][171] ([i915#2920])
   [170]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb1/igt@kms_psr2_sf@cursor-plane-move-continuous-sf.html
   [171]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb2/igt@kms_psr2_sf@cursor-plane-move-continuous-sf.html

  * igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf:
    - shard-iclb:         [SKIP][172] ([i915#2920]) -> [SKIP][173] ([i915#658])
   [172]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html
   [173]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area:
    - shard-iclb:         [SKIP][174] ([i915#2920]) -> [SKIP][175] ([fdo#111068] / [i915#658]) +1 similar issue
   [174]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
   [175]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/shard-iclb6/igt@kms_psr2_sf@plane-move-sf-dmg-area.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
  [i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
  [i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989
  [i915#43]: https://gitlab.freedesktop.org/drm/intel/issues/43
  [i915#4386]: https://gitlab.freedesktop.org/drm/intel/issues/4386
  [i915#4392]: https://gitlab.freedesktop.org/drm/intel/issues/4392
  [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#4573]: https://gitlab.freedesktop.org/drm/intel/issues/4573
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4767]: https://gitlab.freedesktop.org/drm/intel/issues/4767
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
  [i915#5519]: https://gitlab.freedesktop.org/drm/intel/issues/5519
  [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
  [i915#5639]: https://gitlab.freedesktop.org/drm/intel/issues/5639
  [i915#6117]: https://gitlab.freedesktop.org/drm/intel/issues/6117
  [i915#6497]: https://gitlab.freedesktop.org/drm/intel/issues/6497
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#6987]: https://gitlab.freedesktop.org/drm/intel/issues/6987
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716


Build changes
-------------

  * Linux: CI_DRM_12202 -> Patchwork_109276v1

  CI-20190529: 20190529
  CI_DRM_12202: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6670: d618e9865fe5cbaf511ca43503abad442605d0a5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109276v1: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/index.html

[-- Attachment #2: Type: text/html, Size: 35153 bytes --]