[igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[Nicholas Kazlauskas]

If the VRR tests failed then there was a chance that VRR could be
left enabled when exiting the test so the VRR_ENABLED property was
reset to 0 whenever the pipe was reset.

However, in doing so the pipe's state was considered changed even
if VRR_ENABLED was already 0. This causes the pipe to be added to
commits where it previously wasn't.

Other tests with properties that can persist for failures (like color
management) don't bother resetting the properties - so this patch
changes VRR_ENABLED to work the same.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
---
 lib/igt_kms.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 71df98d2..0bec3734 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
 	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
 	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
 
-	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
-		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
-
 	pipe->out_fence_fd = -1;
 }
 
-- 
2.17.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[Maarten Lankhorst]

Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
> If the VRR tests failed then there was a chance that VRR could be
> left enabled when exiting the test so the VRR_ENABLED property was
> reset to 0 whenever the pipe was reset.
>
> However, in doing so the pipe's state was considered changed even
> if VRR_ENABLED was already 0. This causes the pipe to be added to
> commits where it previously wasn't.
>
> Other tests with properties that can persist for failures (like color
> management) don't bother resetting the properties - so this patch
> changes VRR_ENABLED to work the same.
>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> ---
>  lib/igt_kms.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 71df98d2..0bec3734 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>  	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>  	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>  
> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
> -
>  	pipe->out_fence_fd = -1;
>  }
>   

It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[Kazlauskas, Nicholas]

On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>> If the VRR tests failed then there was a chance that VRR could be
>> left enabled when exiting the test so the VRR_ENABLED property was
>> reset to 0 whenever the pipe was reset.
>>
>> However, in doing so the pipe's state was considered changed even
>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>> commits where it previously wasn't.
>>
>> Other tests with properties that can persist for failures (like color
>> management) don't bother resetting the properties - so this patch
>> changes VRR_ENABLED to work the same.
>>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>> ---
>>   lib/igt_kms.c | 3 ---
>>   1 file changed, 3 deletions(-)
>>
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>> index 71df98d2..0bec3734 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>   
>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>> -
>>   	pipe->out_fence_fd = -1;
>>   }
>>    
> 
> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
> 

A lot of atomic state can persist outside of an intended test. I 
couldn't really find anywhere that explicitly resets CRTC properties 
like gamma/background color/etc.

So I currently disable vrr before I check the main pass/fail threshold 
in the test. There are a few cases where the test can still fail while 
it's enabled, but those are mostly system failures. This bit in igt_kms 
is kind of redundant in that sense.

This patch aims to keep things they were before, where one test failure 
can cascade and cause many other tests to fail. I personally favor full 
test isolation when possible so I can tell what specifically went wrong 
when something happens but when everything breaks I guess it gives more 
incentive to address the breakage itself.

Nicholas Kazlauskas
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[Maarten Lankhorst]

Op 31-01-2019 om 16:09 schreef Kazlauskas, Nicholas:
> On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
>> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>>> If the VRR tests failed then there was a chance that VRR could be
>>> left enabled when exiting the test so the VRR_ENABLED property was
>>> reset to 0 whenever the pipe was reset.
>>>
>>> However, in doing so the pipe's state was considered changed even
>>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>>> commits where it previously wasn't.
>>>
>>> Other tests with properties that can persist for failures (like color
>>> management) don't bother resetting the properties - so this patch
>>> changes VRR_ENABLED to work the same.
>>>
>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>> Cc: Petri Latvala <petri.latvala@intel.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>>> ---
>>>   lib/igt_kms.c | 3 ---
>>>   1 file changed, 3 deletions(-)
>>>
>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>> index 71df98d2..0bec3734 100644
>>> --- a/lib/igt_kms.c
>>> +++ b/lib/igt_kms.c
>>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>>   
>>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>>> -
>>>   	pipe->out_fence_fd = -1;
>>>   }
>>>    
>> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
>>
> A lot of atomic state can persist outside of an intended test. I 
> couldn't really find anywhere that explicitly resets CRTC properties 
> like gamma/background color/etc.
>
> So I currently disable vrr before I check the main pass/fail threshold 
> in the test. There are a few cases where the test can still fail while 
> it's enabled, but those are mostly system failures. This bit in igt_kms 
> is kind of redundant in that sense.
>
> This patch aims to keep things they were before, where one test failure 
> can cascade and cause many other tests to fail. I personally favor full 
> test isolation when possible so I can tell what specifically went wrong 
> when something happens but when everything breaks I guess it gives more 
> incentive to address the breakage itself.

Hmm, I guess there's precedence to this with the other properties. Maybe we should clear out gamma/etc as well for a saner experience, but it 's harmless for now.

You're free to choose tif you want to keep resetting this or not. I'm a bit indifferent, but some tests may not handle VRR enabled correctly.

I think cascading tests should be avoided personally, igt_display_reset() should recover from a not too weird state, but then again it should also clear csc/gamma/etc then. Oh well..


Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit

[Wentland, Harry]

On 2019-01-31 10:57 a.m., Maarten Lankhorst wrote:
> Op 31-01-2019 om 16:09 schreef Kazlauskas, Nicholas:
>> On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
>>> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>>>> If the VRR tests failed then there was a chance that VRR could be
>>>> left enabled when exiting the test so the VRR_ENABLED property was
>>>> reset to 0 whenever the pipe was reset.
>>>>
>>>> However, in doing so the pipe's state was considered changed even
>>>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>>>> commits where it previously wasn't.
>>>>
>>>> Other tests with properties that can persist for failures (like color
>>>> management) don't bother resetting the properties - so this patch
>>>> changes VRR_ENABLED to work the same.
>>>>
>>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>>> Cc: Petri Latvala <petri.latvala@intel.com>
>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>>>> ---
>>>>   lib/igt_kms.c | 3 ---
>>>>   1 file changed, 3 deletions(-)
>>>>
>>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>>> index 71df98d2..0bec3734 100644
>>>> --- a/lib/igt_kms.c
>>>> +++ b/lib/igt_kms.c
>>>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>>>   
>>>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>>>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>>>> -
>>>>   	pipe->out_fence_fd = -1;
>>>>   }
>>>>    
>>> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
>>>
>> A lot of atomic state can persist outside of an intended test. I 
>> couldn't really find anywhere that explicitly resets CRTC properties 
>> like gamma/background color/etc.
>>
>> So I currently disable vrr before I check the main pass/fail threshold 
>> in the test. There are a few cases where the test can still fail while 
>> it's enabled, but those are mostly system failures. This bit in igt_kms 
>> is kind of redundant in that sense.
>>
>> This patch aims to keep things they were before, where one test failure 
>> can cascade and cause many other tests to fail. I personally favor full 
>> test isolation when possible so I can tell what specifically went wrong 
>> when something happens but when everything breaks I guess it gives more 
>> incentive to address the breakage itself.
> 
> Hmm, I guess there's precedence to this with the other properties. Maybe we should clear out gamma/etc as well for a saner experience, but it 's harmless for now.
> 
> You're free to choose tif you want to keep resetting this or not. I'm a bit indifferent, but some tests may not handle VRR enabled correctly.
> 
> I think cascading tests should be avoided personally, igt_display_reset() should recover from a not too weird state, but then again it should also clear csc/gamma/etc then. Oh well..
> 
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 

Not nice that igt_display_reset can't properly reset things without potentially impacting tests that run after. This might have unintended consequences but would it make sense to do a commit from igt_display_reset to commit the state and therefore actually go into any subsequent test with a "default" state?

Either way, based on current behavior this patch is
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Harry
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)

[Patchwork]

== Series Details ==

Series: lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
URL   : https://patchwork.freedesktop.org/series/55992/
State : success

== Summary ==

CI Bug Log - changes from IGT_4802 -> IGTPW_2328
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/55992/revisions/2/mbox/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@pm_rpm@basic-rte:
    - fi-bsw-kefka:       PASS -> FAIL [fdo#108800]

  
#### Possible fixes ####

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       INCOMPLETE [fdo#107718] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
    - fi-byt-clapper:     FAIL [fdo#103167] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
    - fi-byt-clapper:     FAIL [fdo#107362] -> PASS

  
  {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#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271


Participating hosts (48 -> 46)
------------------------------

  Additional (2): fi-icl-y fi-kbl-7567u 
  Missing    (4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


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

    * IGT: IGT_4802 -> IGTPW_2328

  CI_DRM_5518: 2369fd28d3a46b865f6d4f1d309a4c6b7b4e6d93 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2328: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2328/
  IGT_4802: 4049adf01014af077df2174def4fadf7cecb066e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

[igt-dev] ✓ Fi.CI.IGT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)

[Patchwork]

== Series Details ==

Series: lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
URL   : https://patchwork.freedesktop.org/series/55992/
State : success

== Summary ==

CI Bug Log - changes from IGT_4802_full -> IGTPW_2328_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/55992/revisions/2/mbox/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
    - shard-snb:          NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
    - shard-glk:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-a-degamma:
    - shard-apl:          PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-128x42-onscreen:
    - shard-glk:          PASS -> FAIL [fdo#103232] +3

  * igt@kms_cursor_crc@cursor-256x256-suspend:
    - shard-glk:          PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
    - shard-apl:          PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_crc@cursor-64x21-random:
    - shard-apl:          PASS -> FAIL [fdo#103232] +6

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          PASS -> FAIL [fdo#105767]

  * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled:
    - shard-glk:          PASS -> FAIL [fdo#103184]

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-glk:          PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-apl:          PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
    - shard-apl:          PASS -> FAIL [fdo#108948]
    - shard-glk:          PASS -> FAIL [fdo#108948]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
    - shard-glk:          PASS -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
    - shard-glk:          NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
    - shard-glk:          PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
    - shard-apl:          PASS -> FAIL [fdo#103166] +2

  * igt@kms_setmode@basic:
    - shard-snb:          NOTRUN -> FAIL [fdo#99912]

  
#### Possible fixes ####

  * igt@i915_suspend@fence-restore-untiled:
    - shard-apl:          DMESG-WARN [fdo#108566] -> PASS

  * igt@kms_busy@basic-modeset-a:
    - shard-apl:          FAIL [fdo#109490] -> PASS +3
    - shard-glk:          FAIL [fdo#109490] -> PASS +3
    - shard-snb:          FAIL [fdo#109490] -> PASS +1

  * igt@kms_cursor_crc@cursor-256x85-random:
    - shard-apl:          FAIL [fdo#103232] -> PASS +1

  * igt@kms_cursor_crc@cursor-size-change:
    - shard-glk:          FAIL [fdo#103232] -> PASS +3

  * igt@kms_flip@2x-flip-vs-modeset:
    - shard-hsw:          DMESG-WARN [fdo#102614] -> PASS

  * igt@kms_flip@modeset-vs-vblank-race:
    - shard-apl:          FAIL [fdo#103060] -> PASS

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
    - shard-glk:          FAIL [fdo#108145] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
    - shard-glk:          FAIL [fdo#103166] -> PASS +4

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
    - shard-apl:          FAIL [fdo#103166] -> PASS

  * igt@kms_setmode@basic:
    - shard-apl:          FAIL [fdo#99912] -> PASS
    - shard-hsw:          FAIL [fdo#99912] -> PASS

  * igt@kms_vblank@crtc-id:
    - shard-hsw:          FAIL [fdo#109490] -> PASS +3

  * igt@pm_rc6_residency@rc6-accuracy:
    - shard-snb:          {SKIP} [fdo#109271] -> PASS

  
#### Warnings ####

  * igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270:
    - shard-snb:          {SKIP} [fdo#109271] -> INCOMPLETE [fdo#105411]

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109490]: https://bugs.freedesktop.org/show_bug.cgi?id=109490
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (7 -> 5)
------------------------------

  Missing    (2): shard-skl shard-iclb 


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

    * IGT: IGT_4802 -> IGTPW_2328

  CI_DRM_5518: 2369fd28d3a46b865f6d4f1d309a4c6b7b4e6d93 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2328: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2328/
  IGT_4802: 4049adf01014af077df2174def4fadf7cecb066e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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