[PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Chris Wilson]

The intent of the assert is to document that the caller took the
appropriate wakerefs for the function. However, as Tvrtko pointed out,
we simply check whether the fw_domains are active and may be confused by
the auto wakeref which may be dropped between the check and use. Let's
be more careful in the assert and check that each fw_domain has an
explicit caller wakeref above and beyond the automatic wakeref.

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_uncore.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index 68d54e126d79..bc25a6e51463 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore *uncore)
 void assert_forcewakes_active(struct intel_uncore *uncore,
 			      enum forcewake_domains fw_domains)
 {
+	struct intel_uncore_forcewake_domain *domain;
+	unsigned int tmp;
+
+	if (!IS_ENABLED(CONFIG_DRM_i915_RUNTIME_PM))
+		return;
+
 	if (!uncore->funcs.force_wake_get)
 		return;
 
@@ -747,6 +753,24 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
 	WARN(fw_domains & ~uncore->fw_domains_active,
 	     "Expected %08x fw_domains to be active, but %08x are off\n",
 	     fw_domains, fw_domains & ~uncore->fw_domains_active);
+
+	/*
+	 * Check that the caller has an explicit wakeref and we don't mistake
+	 * it for the auto wakeref.
+	 */
+	local_irq_disable();
+	for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
+		unsigned int expect = 1;
+
+		if (hrtimer_active(&domain->timer))
+			expect++;
+
+		if (WARN(domain->wake_count < expect,
+			 "Expected domain %d to be held awake by caller\n",
+			 domain->id))
+			break;
+	}
+	local_irq_enable();
 }
 
 /* We give fast paths for the really cool registers */
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Tvrtko Ursulin]

On 03/07/2019 13:12, Chris Wilson wrote:
> The intent of the assert is to document that the caller took the
> appropriate wakerefs for the function. However, as Tvrtko pointed out,
> we simply check whether the fw_domains are active and may be confused by
> the auto wakeref which may be dropped between the check and use. Let's
> be more careful in the assert and check that each fw_domain has an
> explicit caller wakeref above and beyond the automatic wakeref.

Although we still don't know if it is our caller who took the fw or some 
unrelated thread. Still, a more thorough check is better even if not 
perfect.

> 
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/intel_uncore.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 68d54e126d79..bc25a6e51463 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore *uncore)
>   void assert_forcewakes_active(struct intel_uncore *uncore,
>   			      enum forcewake_domains fw_domains)
>   {
> +	struct intel_uncore_forcewake_domain *domain;
> +	unsigned int tmp;
> +
> +	if (!IS_ENABLED(CONFIG_DRM_i915_RUNTIME_PM))
> +		return;
> +

If uncore->funcs.force_wake_get is set why wouldn't we still want to run 
the asserts?

>   	if (!uncore->funcs.force_wake_get)
>   		return;
>   
> @@ -747,6 +753,24 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
>   	WARN(fw_domains & ~uncore->fw_domains_active,
>   	     "Expected %08x fw_domains to be active, but %08x are off\n",
>   	     fw_domains, fw_domains & ~uncore->fw_domains_active);
> +
> +	/*
> +	 * Check that the caller has an explicit wakeref and we don't mistake
> +	 * it for the auto wakeref.
> +	 */
> +	local_irq_disable();
> +	for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
> +		unsigned int expect = 1;
> +
> +		if (hrtimer_active(&domain->timer))
> +			expect++;
> +
> +		if (WARN(domain->wake_count < expect,
> +			 "Expected domain %d to be held awake by caller\n",
> +			 domain->id))
> +			break;
> +	}
> +	local_irq_enable();

This part looks good. Let wait and see if CI calls me a fool.

Regards,

Tvrtko

>   }
>   
>   /* We give fast paths for the really cool registers */
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-07-03 13:43:34)
> 
> On 03/07/2019 13:12, Chris Wilson wrote:
> > The intent of the assert is to document that the caller took the
> > appropriate wakerefs for the function. However, as Tvrtko pointed out,
> > we simply check whether the fw_domains are active and may be confused by
> > the auto wakeref which may be dropped between the check and use. Let's
> > be more careful in the assert and check that each fw_domain has an
> > explicit caller wakeref above and beyond the automatic wakeref.
> 
> Although we still don't know if it is our caller who took the fw or some 
> unrelated thread. Still, a more thorough check is better even if not 
> perfect.

Since it's not a mutex, we can't stuff an owner field in here, the only
way to properly track in that case would be to return cookies from
forcewake_get and verify the cookies are still active.

Not feeling the inclination to do that yet. Maybe if we get a few fw
leaks.

> > Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_uncore.c | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > index 68d54e126d79..bc25a6e51463 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore *uncore)
> >   void assert_forcewakes_active(struct intel_uncore *uncore,
> >                             enum forcewake_domains fw_domains)
> >   {
> > +     struct intel_uncore_forcewake_domain *domain;
> > +     unsigned int tmp;
> > +
> > +     if (!IS_ENABLED(CONFIG_DRM_i915_RUNTIME_PM))
> > +             return;
> > +
> 
> If uncore->funcs.force_wake_get is set why wouldn't we still want to run 
> the asserts?

I'm just being worried by adding a loop under irq-off and didn't want to
add more trouble to non-debug kernels. (Closing the stable door much?)
> 
> >       if (!uncore->funcs.force_wake_get)
> >               return;
> >   
> > @@ -747,6 +753,24 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
> >       WARN(fw_domains & ~uncore->fw_domains_active,
> >            "Expected %08x fw_domains to be active, but %08x are off\n",
> >            fw_domains, fw_domains & ~uncore->fw_domains_active);
> > +
> > +     /*
> > +      * Check that the caller has an explicit wakeref and we don't mistake
> > +      * it for the auto wakeref.
> > +      */
> > +     local_irq_disable();
> > +     for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
> > +             unsigned int expect = 1;
> > +
> > +             if (hrtimer_active(&domain->timer))
> > +                     expect++;
> > +
> > +             if (WARN(domain->wake_count < expect,
> > +                      "Expected domain %d to be held awake by caller\n",
> > +                      domain->id))
> > +                     break;
> > +     }
> > +     local_irq_enable();
> 
> This part looks good. Let wait and see if CI calls me a fool.

Aye, that's what I'm waiting for as well. Personalized insults from CI :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Patchwork]

== Series Details ==

Series: drm/i915: Check caller held wakerefs in assert_forcewakes_active
URL   : https://patchwork.freedesktop.org/series/63125/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404 -> Patchwork_13507
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_pm_rpm@module-reload:
    - fi-skl-6770hq:      [PASS][1] -> [FAIL][2] ([fdo#108511])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-icl-u2:          [PASS][3] -> [FAIL][4] ([fdo#103167])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-ilk-650:         [PASS][5] -> [DMESG-WARN][6] ([fdo#106387])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html

  
#### Possible fixes ####

  * igt@gem_ctx_create@basic-files:
    - fi-icl-u3:          [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/fi-icl-u3/igt@gem_ctx_create@basic-files.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/fi-icl-u3/igt@gem_ctx_create@basic-files.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100


Participating hosts (54 -> 45)
------------------------------

  Missing    (9): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus 


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

  * Linux: CI_DRM_6404 -> Patchwork_13507

  CI_DRM_6404: 1b853e6e181c6015faca908b57956ea836e1f440 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5079: 873df2fa9e8f5fd02d4532b30ef2579f4fe4f27f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13507: b7676feecc89b1f82784c694922cf04ca182a7c5 @ git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/build_32bit.log

  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  CHK     include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

b7676feecc89 drm/i915: Check caller held wakerefs in assert_forcewakes_active

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Tvrtko Ursulin]

On 03/07/2019 13:48, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-07-03 13:43:34)
>>
>> On 03/07/2019 13:12, Chris Wilson wrote:
>>> The intent of the assert is to document that the caller took the
>>> appropriate wakerefs for the function. However, as Tvrtko pointed out,
>>> we simply check whether the fw_domains are active and may be confused by
>>> the auto wakeref which may be dropped between the check and use. Let's
>>> be more careful in the assert and check that each fw_domain has an
>>> explicit caller wakeref above and beyond the automatic wakeref.
>>
>> Although we still don't know if it is our caller who took the fw or some
>> unrelated thread. Still, a more thorough check is better even if not
>> perfect.
> 
> Since it's not a mutex, we can't stuff an owner field in here, the only
> way to properly track in that case would be to return cookies from
> forcewake_get and verify the cookies are still active.
> 
> Not feeling the inclination to do that yet. Maybe if we get a few fw
> leaks.

Agreed, I wasn't trying to say we have to do it.

> 
>>> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/intel_uncore.c | 24 ++++++++++++++++++++++++
>>>    1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
>>> index 68d54e126d79..bc25a6e51463 100644
>>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>>> @@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore *uncore)
>>>    void assert_forcewakes_active(struct intel_uncore *uncore,
>>>                              enum forcewake_domains fw_domains)
>>>    {
>>> +     struct intel_uncore_forcewake_domain *domain;
>>> +     unsigned int tmp;
>>> +
>>> +     if (!IS_ENABLED(CONFIG_DRM_i915_RUNTIME_PM))
>>> +             return;
>>> +
>>
>> If uncore->funcs.force_wake_get is set why wouldn't we still want to run
>> the asserts?
> 
> I'm just being worried by adding a loop under irq-off and didn't want to
> add more trouble to non-debug kernels. (Closing the stable door much?)

What is the connection between debug/non-debug kernels and 
CONFIG_DRM_i915_RUNTIME_PM?

Regards,

Tvrtko

>>
>>>        if (!uncore->funcs.force_wake_get)
>>>                return;
>>>    
>>> @@ -747,6 +753,24 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
>>>        WARN(fw_domains & ~uncore->fw_domains_active,
>>>             "Expected %08x fw_domains to be active, but %08x are off\n",
>>>             fw_domains, fw_domains & ~uncore->fw_domains_active);
>>> +
>>> +     /*
>>> +      * Check that the caller has an explicit wakeref and we don't mistake
>>> +      * it for the auto wakeref.
>>> +      */
>>> +     local_irq_disable();
>>> +     for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
>>> +             unsigned int expect = 1;
>>> +
>>> +             if (hrtimer_active(&domain->timer))
>>> +                     expect++;
>>> +
>>> +             if (WARN(domain->wake_count < expect,
>>> +                      "Expected domain %d to be held awake by caller\n",
>>> +                      domain->id))
>>> +                     break;
>>> +     }
>>> +     local_irq_enable();
>>
>> This part looks good. Let wait and see if CI calls me a fool.
> 
> Aye, that's what I'm waiting for as well. Personalized insults from CI :)
> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-07-04 09:10:32)
> 
> On 03/07/2019 13:48, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-03 13:43:34)
> >>
> >> On 03/07/2019 13:12, Chris Wilson wrote:
> >>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> >>> index 68d54e126d79..bc25a6e51463 100644
> >>> --- a/drivers/gpu/drm/i915/intel_uncore.c
> >>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> >>> @@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore *uncore)
> >>>    void assert_forcewakes_active(struct intel_uncore *uncore,
> >>>                              enum forcewake_domains fw_domains)
> >>>    {
> >>> +     struct intel_uncore_forcewake_domain *domain;
> >>> +     unsigned int tmp;
> >>> +
> >>> +     if (!IS_ENABLED(CONFIG_DRM_i915_RUNTIME_PM))
> >>> +             return;
> >>> +
> >>
> >> If uncore->funcs.force_wake_get is set why wouldn't we still want to run
> >> the asserts?
> > 
> > I'm just being worried by adding a loop under irq-off and didn't want to
> > add more trouble to non-debug kernels. (Closing the stable door much?)
> 
> What is the connection between debug/non-debug kernels and 
> CONFIG_DRM_i915_RUNTIME_PM?

Well, I can't type obviously. It's meant to be the symbol for
	config DRM_I915_DEBUG_RUNTIME_PM
to match the other assert in use.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for drm/i915: Check caller held wakerefs in assert_forcewakes_active

[Patchwork]

== Series Details ==

Series: drm/i915: Check caller held wakerefs in assert_forcewakes_active
URL   : https://patchwork.freedesktop.org/series/63125/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13507_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@close-race:
    - shard-hsw:          [PASS][1] -> [DMESG-FAIL][2] ([fdo#111063])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw4/igt@gem_busy@close-race.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw1/igt@gem_busy@close-race.html

  * igt@gem_eio@reset-stress:
    - shard-snb:          [PASS][3] -> [FAIL][4] ([fdo#109661])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-snb7/igt@gem_eio@reset-stress.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-snb2/igt@gem_eio@reset-stress.html

  * igt@i915_pm_rpm@i2c:
    - shard-hsw:          [PASS][5] -> [FAIL][6] ([fdo#104097])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw7/igt@i915_pm_rpm@i2c.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw5/igt@i915_pm_rpm@i2c.html

  * igt@i915_pm_rpm@modeset-stress-extra-wait:
    - shard-iclb:         [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108840])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb3/igt@i915_pm_rpm@modeset-stress-extra-wait.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb7/igt@i915_pm_rpm@modeset-stress-extra-wait.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [PASS][9] -> [FAIL][10] ([fdo#105363])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-kbl:          [PASS][11] -> [DMESG-WARN][12] ([fdo#103313])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-kbl6/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu:
    - shard-hsw:          [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw7/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([fdo#103167]) +7 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb4/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html

  
#### Possible fixes ####

  * igt@gem_busy@close-race:
    - shard-skl:          [DMESG-FAIL][21] ([fdo#111063]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_busy@close-race.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl10/igt@gem_busy@close-race.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][23] ([fdo#104108] / [fdo#107773]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_softpin@noreloc-s3.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl7/igt@gem_softpin@noreloc-s3.html

  * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
    - shard-glk:          [FAIL][25] ([fdo#104873]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk2/igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-glk8/igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt:
    - shard-iclb:         [INCOMPLETE][27] ([fdo#106978] / [fdo#107713]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
    - shard-iclb:         [FAIL][29] ([fdo#103167]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-apl:          [DMESG-WARN][31] ([fdo#108566]) -> [PASS][32] +2 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [FAIL][33] ([fdo#108145]) -> [PASS][34] +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][35] ([fdo#108145] / [fdo#110403]) -> [PASS][36] +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [FAIL][37] ([fdo#103166]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb6/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb2/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [SKIP][39] ([fdo#109441]) -> [PASS][40] +2 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_psr@psr2_cursor_render.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb2/igt@kms_psr@psr2_cursor_render.html

  * igt@perf@blocking:
    - shard-skl:          [FAIL][41] ([fdo#110728]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl8/igt@perf@blocking.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl9/igt@perf@blocking.html

  
#### Warnings ####

  * igt@kms_content_protection@atomic:
    - shard-iclb:         [SKIP][43] ([fdo#109300]) -> [SKIP][44] ([fdo#109300] / [fdo#111066])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb7/igt@kms_content_protection@atomic.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb8/igt@kms_content_protection@atomic.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [SKIP][45] ([fdo#109642]) -> [SKIP][46] ([fdo#109642] / [fdo#111068])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb3/igt@kms_psr2_su@page_flip.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb7/igt@kms_psr2_su@page_flip.html

  
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
  [fdo#104097]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
  [fdo#111063]: https://bugs.freedesktop.org/show_bug.cgi?id=111063
  [fdo#111066]: https://bugs.freedesktop.org/show_bug.cgi?id=111066
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * Linux: CI_DRM_6404 -> Patchwork_13507

  CI_DRM_6404: 1b853e6e181c6015faca908b57956ea836e1f440 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5079: 873df2fa9e8f5fd02d4532b30ef2579f4fe4f27f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13507: b7676feecc89b1f82784c694922cf04ca182a7c5 @ 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_13507/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx