[igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

This change will slow this test down a bit. In mid test starting
to use higher bpp pixel format (say 64bpp) can cause modeset.
Use blocking commit so there's wait for modeset to happen.

Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
---
 tests/kms_plane.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tests/kms_plane.c b/tests/kms_plane.c
index 805795cd..2324fb6e 100644
--- a/tests/kms_plane.c
+++ b/tests/kms_plane.c
@@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, enum pipe pipe,
 
 		if (data->display.is_atomic) {
 			/*
-			 * Use non-blocking commits to allow the next fb
-			 * to be prepared in parallel while the current fb
-			 * awaits to be latched.
+			 * Use blocking commit because there maybe
+			 * modeset when going to higher bpp pixel format.
 			 */
 			igt_display_commit_atomic(&data->display,
-						  DRM_MODE_ATOMIC_NONBLOCK |
 						  DRM_MODE_PAGE_FLIP_EVENT, NULL);
 		} else {
 			/*
-- 
2.17.1

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

[igt-dev] ✓ Fi.CI.BAT: success for tests/kms_plane: survive cdclk caused modeset

[Patchwork]

== Series Details ==

Series: tests/kms_plane: survive cdclk caused modeset
URL   : https://patchwork.freedesktop.org/series/75610/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8264 -> IGTPW_4424
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_chamelium@dp-edid-read:
    - fi-kbl-7500u:       [PASS][1] -> [FAIL][2] ([i915#976])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-kbl-7500u/igt@kms_chamelium@dp-edid-read.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/fi-kbl-7500u/igt@kms_chamelium@dp-edid-read.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s4-devices:
    - fi-tgl-y:           [FAIL][3] ([i915#1158]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html

  * igt@i915_selftest@live@hangcheck:
    - fi-icl-y:           [INCOMPLETE][5] ([i915#1580]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-y/igt@i915_selftest@live@hangcheck.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/fi-icl-y/igt@i915_selftest@live@hangcheck.html

  
  [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158
  [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580
  [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976


Participating hosts (53 -> 47)
------------------------------

  Additional (1): fi-kbl-7560u 
  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5573 -> IGTPW_4424

  CI-20190529: 20190529
  CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4424: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/index.html
  IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Ville Syrjälä]

On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> This change will slow this test down a bit. In mid test starting
> to use higher bpp pixel format (say 64bpp) can cause modeset.
> Use blocking commit so there's wait for modeset to happen.

We already wait for the event the next time around. So this
doesn't make sense to me.

> 
> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> ---
>  tests/kms_plane.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> index 805795cd..2324fb6e 100644
> --- a/tests/kms_plane.c
> +++ b/tests/kms_plane.c
> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, enum pipe pipe,
>  
>  		if (data->display.is_atomic) {
>  			/*
> -			 * Use non-blocking commits to allow the next fb
> -			 * to be prepared in parallel while the current fb
> -			 * awaits to be latched.
> +			 * Use blocking commit because there maybe
> +			 * modeset when going to higher bpp pixel format.
>  			 */
>  			igt_display_commit_atomic(&data->display,
> -						  DRM_MODE_ATOMIC_NONBLOCK |
>  						  DRM_MODE_PAGE_FLIP_EVENT, NULL);
>  		} else {
>  			/*
> -- 
> 2.17.1
> 
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 7.4.2020 18.36, Ville Syrjälä wrote:
> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>> This change will slow this test down a bit. In mid test starting
>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>> Use blocking commit so there's wait for modeset to happen.
> 
> We already wait for the event the next time around. So this
> doesn't make sense to me.

There's those logs like this
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html

where going to 64bpp pixel format will cause modeset and fail running 
test. I was testing this on ICL and see errors randomly, on ci those 
seem to be less random. Making this one commit blocking will cause 
modeset to settle without interrupting test, at least on my ICL.

If there's a way to sort those pixel formats according to bpp and start 
with highest there's no need for this.

> 
>>
>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>> ---
>>   tests/kms_plane.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>> index 805795cd..2324fb6e 100644
>> --- a/tests/kms_plane.c
>> +++ b/tests/kms_plane.c
>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, enum pipe pipe,
>>   
>>   		if (data->display.is_atomic) {
>>   			/*
>> -			 * Use non-blocking commits to allow the next fb
>> -			 * to be prepared in parallel while the current fb
>> -			 * awaits to be latched.
>> +			 * Use blocking commit because there maybe
>> +			 * modeset when going to higher bpp pixel format.
>>   			 */
>>   			igt_display_commit_atomic(&data->display,
>> -						  DRM_MODE_ATOMIC_NONBLOCK |
>>   						  DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>   		} else {
>>   			/*
>> -- 
>> 2.17.1
>>
>> _______________________________________________
>> igt-dev mailing list
>> igt-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Ville Syrjälä]

On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
> On 7.4.2020 18.36, Ville Syrjälä wrote:
> > On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> >> This change will slow this test down a bit. In mid test starting
> >> to use higher bpp pixel format (say 64bpp) can cause modeset.
> >> Use blocking commit so there's wait for modeset to happen.
> > 
> > We already wait for the event the next time around. So this
> > doesn't make sense to me.
> 
> There's those logs like this
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
> 
> where going to 64bpp pixel format will cause modeset and fail running 
> test.

Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
actual debug message :( Anyways, the real bug seems to be the lack of
ALLOW_MODESET.

> I was testing this on ICL and see errors randomly, on ci those 
> seem to be less random. Making this one commit blocking will cause 
> modeset to settle without interrupting test, at least on my ICL.
> 
> If there's a way to sort those pixel formats according to bpp and start 
> with highest there's no need for this.
> 
> > 
> >>
> >> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> >> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> >> ---
> >>   tests/kms_plane.c | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> >> index 805795cd..2324fb6e 100644
> >> --- a/tests/kms_plane.c
> >> +++ b/tests/kms_plane.c
> >> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, enum pipe pipe,
> >>   
> >>   		if (data->display.is_atomic) {
> >>   			/*
> >> -			 * Use non-blocking commits to allow the next fb
> >> -			 * to be prepared in parallel while the current fb
> >> -			 * awaits to be latched.
> >> +			 * Use blocking commit because there maybe
> >> +			 * modeset when going to higher bpp pixel format.
> >>   			 */
> >>   			igt_display_commit_atomic(&data->display,
> >> -						  DRM_MODE_ATOMIC_NONBLOCK |
> >>   						  DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>   		} else {
> >>   			/*
> >> -- 
> >> 2.17.1
> >>
> >> _______________________________________________
> >> igt-dev mailing list
> >> igt-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 7.4.2020 19.08, Ville Syrjälä wrote:
> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
>> On 7.4.2020 18.36, Ville Syrjälä wrote:
>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>>>> This change will slow this test down a bit. In mid test starting
>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>>>> Use blocking commit so there's wait for modeset to happen.
>>>
>>> We already wait for the event the next time around. So this
>>> doesn't make sense to me.
>>
>> There's those logs like this
>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
>>
>> where going to 64bpp pixel format will cause modeset and fail running
>> test.
> 
> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
> actual debug message :( Anyways, the real bug seems to be the lack of
> ALLOW_MODESET.

I'll try that and see how it changes situation. I originally had idea 
modeset will block the flip and making this commit blocking would always 
force things always into correct order as current test didn't fail every 
time for me.

> 
>> I was testing this on ICL and see errors randomly, on ci those
>> seem to be less random. Making this one commit blocking will cause
>> modeset to settle without interrupting test, at least on my ICL.
>>
>> If there's a way to sort those pixel formats according to bpp and start
>> with highest there's no need for this.
>>
>>>
>>>>
>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>>>> ---
>>>>    tests/kms_plane.c | 6 ++----
>>>>    1 file changed, 2 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>>>> index 805795cd..2324fb6e 100644
>>>> --- a/tests/kms_plane.c
>>>> +++ b/tests/kms_plane.c
>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, enum pipe pipe,
>>>>    
>>>>    		if (data->display.is_atomic) {
>>>>    			/*
>>>> -			 * Use non-blocking commits to allow the next fb
>>>> -			 * to be prepared in parallel while the current fb
>>>> -			 * awaits to be latched.
>>>> +			 * Use blocking commit because there maybe
>>>> +			 * modeset when going to higher bpp pixel format.
>>>>    			 */
>>>>    			igt_display_commit_atomic(&data->display,
>>>> -						  DRM_MODE_ATOMIC_NONBLOCK |
>>>>    						  DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>    		} else {
>>>>    			/*
>>>> -- 
>>>> 2.17.1
>>>>
>>>> _______________________________________________
>>>> igt-dev mailing list
>>>> igt-dev@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>
> 

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
> On 7.4.2020 19.08, Ville Syrjälä wrote:
>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>>>>> This change will slow this test down a bit. In mid test starting
>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>>>>> Use blocking commit so there's wait for modeset to happen.
>>>>
>>>> We already wait for the event the next time around. So this
>>>> doesn't make sense to me.
>>>
>>> There's those logs like this
>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html 
>>>
>>>
>>> where going to 64bpp pixel format will cause modeset and fail running
>>> test.
>>
>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
>> actual debug message :( Anyways, the real bug seems to be the lack of
>> ALLOW_MODESET.
> 
> I'll try that and see how it changes situation. I originally had idea 
> modeset will block the flip and making this commit blocking would always 
> force things always into correct order as current test didn't fail every 
> time for me.

Having that commit saying

igt_display_commit_atomic(&data->display,
	DRM_MODE_ATOMIC_ALLOW_MODESET |
	DRM_MODE_ATOMIC_NONBLOCK |
	DRM_MODE_PAGE_FLIP_EVENT, NULL);

I see test failing as before so it will not alone fix this issue. On my 
ICL box the test fail maybe 1/5 times, with the patch on list it never 
failed so far.

> 
>>
>>> I was testing this on ICL and see errors randomly, on ci those
>>> seem to be less random. Making this one commit blocking will cause
>>> modeset to settle without interrupting test, at least on my ICL.
>>>
>>> If there's a way to sort those pixel formats according to bpp and start
>>> with highest there's no need for this.
>>>
>>>>
>>>>>
>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>>>>> ---
>>>>>    tests/kms_plane.c | 6 ++----
>>>>>    1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>>>>> index 805795cd..2324fb6e 100644
>>>>> --- a/tests/kms_plane.c
>>>>> +++ b/tests/kms_plane.c
>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, 
>>>>> enum pipe pipe,
>>>>>            if (data->display.is_atomic) {
>>>>>                /*
>>>>> -             * Use non-blocking commits to allow the next fb
>>>>> -             * to be prepared in parallel while the current fb
>>>>> -             * awaits to be latched.
>>>>> +             * Use blocking commit because there maybe
>>>>> +             * modeset when going to higher bpp pixel format.
>>>>>                 */
>>>>>                igt_display_commit_atomic(&data->display,
>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
>>>>>                              DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>>            } else {
>>>>>                /*
>>>>> -- 
>>>>> 2.17.1
>>>>>
>>>>> _______________________________________________
>>>>> igt-dev mailing list
>>>>> igt-dev@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>
>>
> 

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Ville Syrjälä]

On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
> > On 7.4.2020 19.08, Ville Syrjälä wrote:
> >> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
> >>> On 7.4.2020 18.36, Ville Syrjälä wrote:
> >>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> >>>>> This change will slow this test down a bit. In mid test starting
> >>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
> >>>>> Use blocking commit so there's wait for modeset to happen.
> >>>>
> >>>> We already wait for the event the next time around. So this
> >>>> doesn't make sense to me.
> >>>
> >>> There's those logs like this
> >>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html 
> >>>
> >>>
> >>> where going to 64bpp pixel format will cause modeset and fail running
> >>> test.
> >>
> >> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
> >> actual debug message :( Anyways, the real bug seems to be the lack of
> >> ALLOW_MODESET.
> > 
> > I'll try that and see how it changes situation. I originally had idea 
> > modeset will block the flip and making this commit blocking would always 
> > force things always into correct order as current test didn't fail every 
> > time for me.
> 
> Having that commit saying
> 
> igt_display_commit_atomic(&data->display,
> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
> 	DRM_MODE_ATOMIC_NONBLOCK |
> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
> 
> I see test failing as before so it will not alone fix this issue. On my 
> ICL box the test fail maybe 1/5 times, with the patch on list it never 
> failed so far.

Why does it fail?

> 
> > 
> >>
> >>> I was testing this on ICL and see errors randomly, on ci those
> >>> seem to be less random. Making this one commit blocking will cause
> >>> modeset to settle without interrupting test, at least on my ICL.
> >>>
> >>> If there's a way to sort those pixel formats according to bpp and start
> >>> with highest there's no need for this.
> >>>
> >>>>
> >>>>>
> >>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> >>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> >>>>> ---
> >>>>>    tests/kms_plane.c | 6 ++----
> >>>>>    1 file changed, 2 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> >>>>> index 805795cd..2324fb6e 100644
> >>>>> --- a/tests/kms_plane.c
> >>>>> +++ b/tests/kms_plane.c
> >>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, 
> >>>>> enum pipe pipe,
> >>>>>            if (data->display.is_atomic) {
> >>>>>                /*
> >>>>> -             * Use non-blocking commits to allow the next fb
> >>>>> -             * to be prepared in parallel while the current fb
> >>>>> -             * awaits to be latched.
> >>>>> +             * Use blocking commit because there maybe
> >>>>> +             * modeset when going to higher bpp pixel format.
> >>>>>                 */
> >>>>>                igt_display_commit_atomic(&data->display,
> >>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
> >>>>>                              DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>>>>            } else {
> >>>>>                /*
> >>>>> -- 
> >>>>> 2.17.1
> >>>>>
> >>>>> _______________________________________________
> >>>>> igt-dev mailing list
> >>>>> igt-dev@lists.freedesktop.org
> >>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >>>>
> >>
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 7.4.2020 20.10, Ville Syrjälä wrote:
> On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
>> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
>>> On 7.4.2020 19.08, Ville Syrjälä wrote:
>>>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
>>>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
>>>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>>>>>>> This change will slow this test down a bit. In mid test starting
>>>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>>>>>>> Use blocking commit so there's wait for modeset to happen.
>>>>>>
>>>>>> We already wait for the event the next time around. So this
>>>>>> doesn't make sense to me.
>>>>>
>>>>> There's those logs like this
>>>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
>>>>>
>>>>>
>>>>> where going to 64bpp pixel format will cause modeset and fail running
>>>>> test.
>>>>
>>>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
>>>> actual debug message :( Anyways, the real bug seems to be the lack of
>>>> ALLOW_MODESET.
>>>
>>> I'll try that and see how it changes situation. I originally had idea
>>> modeset will block the flip and making this commit blocking would always
>>> force things always into correct order as current test didn't fail every
>>> time for me.
>>
>> Having that commit saying
>>
>> igt_display_commit_atomic(&data->display,
>> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
>> 	DRM_MODE_ATOMIC_NONBLOCK |
>> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>
>> I see test failing as before so it will not alone fix this issue. On my
>> ICL box the test fail maybe 1/5 times, with the patch on list it never
>> failed so far.
> 
> Why does it fail?


This is failure with ALLOW_MODESET
---
(kms_plane:31238) igt_kms-DEBUG: display: }
(kms_plane:31238) igt_kms-CRITICAL: Test assertion failure function 
igt_display_commit_atomic, file ../lib/igt_kms.c:3508:
(kms_plane:31238) igt_kms-CRITICAL: Failed assertion: ret == 0
(kms_plane:31238) igt_kms-CRITICAL: Last errno: 16, Device or resource busy
(kms_plane:31238) igt_kms-CRITICAL: error: -16 != 0
(kms_plane:31238) igt_core-INFO: Stack trace:
(kms_plane:31238) igt_core-INFO:   #0 ../lib/igt_core.c:1676 
__igt_fail_assert()
(kms_plane:31238) igt_core-INFO:   #1 [igt_display_commit_atomic+0x44]
(kms_plane:31238) igt_core-INFO:   #2 ../tests/kms_plane.c:599 
capture_format_crcs.constprop.14()
(kms_plane:31238) igt_core-INFO:   #3 ../tests/kms_plane.c:652 
test_format_plane_colors.constprop.13()
(kms_plane:31238) igt_core-INFO:   #4 ../tests/kms_plane.c:728 
test_pixel_formats.constprop.9()
(kms_plane:31238) igt_core-INFO:   #5 ../tests/kms_plane.c:950 
run_tests_for_pipe_plane.constprop.8()
(kms_plane:31238) igt_core-INFO:   #6 ../tests/kms_plane.c:1019 
__real_main1006()
(kms_plane:31238) igt_core-INFO:   #7 ../tests/kms_plane.c:1006 main()
(kms_plane:31238) igt_core-INFO:   #8 ../csu/libc-start.c:344 
__libc_start_main()
(kms_plane:31238) igt_core-INFO:   #9 [_start+0x2a]
****  END  ****
Stack trace:
   #0 ../lib/igt_core.c:1676 __igt_fail_assert()
   #1 [igt_display_commit_atomic+0x44]
   #2 ../tests/kms_plane.c:599 capture_format_crcs.constprop.14()
   #3 ../tests/kms_plane.c:652 test_format_plane_colors.constprop.13()
   #4 ../tests/kms_plane.c:728 test_pixel_formats.constprop.9()
   #5 ../tests/kms_plane.c:950 run_tests_for_pipe_plane.constprop.8()
   #6 ../tests/kms_plane.c:1019 __real_main1006()
   #7 ../tests/kms_plane.c:1006 main()
   #8 ../csu/libc-start.c:344 __libc_start_main()
   #9 [_start+0x2a]
Subtest pixel-format-pipe-A-planes-source-clamping: FAIL (22.543s)
--

Failure is ebusy. It seems round where it kick me out is not always the 
same.

> 
>>
>>>
>>>>
>>>>> I was testing this on ICL and see errors randomly, on ci those
>>>>> seem to be less random. Making this one commit blocking will cause
>>>>> modeset to settle without interrupting test, at least on my ICL.
>>>>>
>>>>> If there's a way to sort those pixel formats according to bpp and start
>>>>> with highest there's no need for this.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>>>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>>>>>>> ---
>>>>>>>     tests/kms_plane.c | 6 ++----
>>>>>>>     1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>
>>>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>>>>>>> index 805795cd..2324fb6e 100644
>>>>>>> --- a/tests/kms_plane.c
>>>>>>> +++ b/tests/kms_plane.c
>>>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data,
>>>>>>> enum pipe pipe,
>>>>>>>             if (data->display.is_atomic) {
>>>>>>>                 /*
>>>>>>> -             * Use non-blocking commits to allow the next fb
>>>>>>> -             * to be prepared in parallel while the current fb
>>>>>>> -             * awaits to be latched.
>>>>>>> +             * Use blocking commit because there maybe
>>>>>>> +             * modeset when going to higher bpp pixel format.
>>>>>>>                  */
>>>>>>>                 igt_display_commit_atomic(&data->display,
>>>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
>>>>>>>                               DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>>>>             } else {
>>>>>>>                 /*
>>>>>>> -- 
>>>>>>> 2.17.1
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> igt-dev mailing list
>>>>>>> igt-dev@lists.freedesktop.org
>>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>>>
>>>>
>>>
> 

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Ville Syrjälä]

On Tue, Apr 07, 2020 at 08:24:01PM +0300, Juha-Pekka Heikkila wrote:
> On 7.4.2020 20.10, Ville Syrjälä wrote:
> > On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
> >> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
> >>> On 7.4.2020 19.08, Ville Syrjälä wrote:
> >>>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
> >>>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
> >>>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> >>>>>>> This change will slow this test down a bit. In mid test starting
> >>>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
> >>>>>>> Use blocking commit so there's wait for modeset to happen.
> >>>>>>
> >>>>>> We already wait for the event the next time around. So this
> >>>>>> doesn't make sense to me.
> >>>>>
> >>>>> There's those logs like this
> >>>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
> >>>>>
> >>>>>
> >>>>> where going to 64bpp pixel format will cause modeset and fail running
> >>>>> test.
> >>>>
> >>>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
> >>>> actual debug message :( Anyways, the real bug seems to be the lack of
> >>>> ALLOW_MODESET.
> >>>
> >>> I'll try that and see how it changes situation. I originally had idea
> >>> modeset will block the flip and making this commit blocking would always
> >>> force things always into correct order as current test didn't fail every
> >>> time for me.
> >>
> >> Having that commit saying
> >>
> >> igt_display_commit_atomic(&data->display,
> >> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
> >> 	DRM_MODE_ATOMIC_NONBLOCK |
> >> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>
> >> I see test failing as before so it will not alone fix this issue. On my
> >> ICL box the test fail maybe 1/5 times, with the patch on list it never
> >> failed so far.
> > 
> > Why does it fail?
> 
> 
> This is failure with ALLOW_MODESET
> ---
> (kms_plane:31238) igt_kms-DEBUG: display: }
> (kms_plane:31238) igt_kms-CRITICAL: Test assertion failure function 
> igt_display_commit_atomic, file ../lib/igt_kms.c:3508:
> (kms_plane:31238) igt_kms-CRITICAL: Failed assertion: ret == 0
> (kms_plane:31238) igt_kms-CRITICAL: Last errno: 16, Device or resource busy
> (kms_plane:31238) igt_kms-CRITICAL: error: -16 != 0
> (kms_plane:31238) igt_core-INFO: Stack trace:
> (kms_plane:31238) igt_core-INFO:   #0 ../lib/igt_core.c:1676 
> __igt_fail_assert()
> (kms_plane:31238) igt_core-INFO:   #1 [igt_display_commit_atomic+0x44]
> (kms_plane:31238) igt_core-INFO:   #2 ../tests/kms_plane.c:599 
> capture_format_crcs.constprop.14()
> (kms_plane:31238) igt_core-INFO:   #3 ../tests/kms_plane.c:652 
> test_format_plane_colors.constprop.13()
> (kms_plane:31238) igt_core-INFO:   #4 ../tests/kms_plane.c:728 
> test_pixel_formats.constprop.9()
> (kms_plane:31238) igt_core-INFO:   #5 ../tests/kms_plane.c:950 
> run_tests_for_pipe_plane.constprop.8()
> (kms_plane:31238) igt_core-INFO:   #6 ../tests/kms_plane.c:1019 
> __real_main1006()
> (kms_plane:31238) igt_core-INFO:   #7 ../tests/kms_plane.c:1006 main()
> (kms_plane:31238) igt_core-INFO:   #8 ../csu/libc-start.c:344 
> __libc_start_main()
> (kms_plane:31238) igt_core-INFO:   #9 [_start+0x2a]
> ****  END  ****
> Stack trace:
>    #0 ../lib/igt_core.c:1676 __igt_fail_assert()
>    #1 [igt_display_commit_atomic+0x44]
>    #2 ../tests/kms_plane.c:599 capture_format_crcs.constprop.14()
>    #3 ../tests/kms_plane.c:652 test_format_plane_colors.constprop.13()
>    #4 ../tests/kms_plane.c:728 test_pixel_formats.constprop.9()
>    #5 ../tests/kms_plane.c:950 run_tests_for_pipe_plane.constprop.8()
>    #6 ../tests/kms_plane.c:1019 __real_main1006()
>    #7 ../tests/kms_plane.c:1006 main()
>    #8 ../csu/libc-start.c:344 __libc_start_main()
>    #9 [_start+0x2a]
> Subtest pixel-format-pipe-A-planes-source-clamping: FAIL (22.543s)

That doesn't tell anyone anything useful. Only kernel logs can help
diagnose the problem.


> --
> 
> Failure is ebusy. It seems round where it kick me out is not always the 
> same.

Hmm. Sounds like we have a race between sending the event vs. submitting
a new commit :(

Hmm. What wasn't there a patch from Daniel to convert modeset commits to
blocking to "fix" a race just like this? Ah, yeah it was EBUSY due to
multiple pipes and noblocking modesets. Do you have multiple pipes
enablad when it fails? That could certainly explain the race.

> 
> > 
> >>
> >>>
> >>>>
> >>>>> I was testing this on ICL and see errors randomly, on ci those
> >>>>> seem to be less random. Making this one commit blocking will cause
> >>>>> modeset to settle without interrupting test, at least on my ICL.
> >>>>>
> >>>>> If there's a way to sort those pixel formats according to bpp and start
> >>>>> with highest there's no need for this.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> >>>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> >>>>>>> ---
> >>>>>>>     tests/kms_plane.c | 6 ++----
> >>>>>>>     1 file changed, 2 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> >>>>>>> index 805795cd..2324fb6e 100644
> >>>>>>> --- a/tests/kms_plane.c
> >>>>>>> +++ b/tests/kms_plane.c
> >>>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data,
> >>>>>>> enum pipe pipe,
> >>>>>>>             if (data->display.is_atomic) {
> >>>>>>>                 /*
> >>>>>>> -             * Use non-blocking commits to allow the next fb
> >>>>>>> -             * to be prepared in parallel while the current fb
> >>>>>>> -             * awaits to be latched.
> >>>>>>> +             * Use blocking commit because there maybe
> >>>>>>> +             * modeset when going to higher bpp pixel format.
> >>>>>>>                  */
> >>>>>>>                 igt_display_commit_atomic(&data->display,
> >>>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
> >>>>>>>                               DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>>>>>>             } else {
> >>>>>>>                 /*
> >>>>>>> -- 
> >>>>>>> 2.17.1
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> igt-dev mailing list
> >>>>>>> igt-dev@lists.freedesktop.org
> >>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >>>>>>
> >>>>
> >>>
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for tests/kms_plane: survive cdclk caused modeset

[Patchwork]

== Series Details ==

Series: tests/kms_plane: survive cdclk caused modeset
URL   : https://patchwork.freedesktop.org/series/75610/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8264_full -> IGTPW_4424_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen:
    - shard-apl:          [PASS][1] -> [FAIL][2] ([i915#54] / [i915#95])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl4/igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl8/igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
    - shard-kbl:          [PASS][3] -> [FAIL][4] ([i915#54] / [i915#93] / [i915#95]) +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge:
    - shard-kbl:          [PASS][7] -> [FAIL][8] ([i915#70] / [i915#93] / [i915#95])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl1/igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl6/igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
    - shard-kbl:          [PASS][9] -> [FAIL][10] ([i915#1566] / [i915#93] / [i915#95])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl4/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl3/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html

  * igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled:
    - shard-glk:          [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-glk4/igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-hsw:          [PASS][13] -> [INCOMPLETE][14] ([i915#61])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-hsw7/igt@kms_flip@flip-vs-suspend-interruptible.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-hsw4/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_flip@plain-flip-ts-check:
    - shard-glk:          [PASS][15] -> [FAIL][16] ([i915#34])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-glk5/igt@kms_flip@plain-flip-ts-check.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-glk3/igt@kms_flip@plain-flip-ts-check.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [PASS][17] -> [DMESG-WARN][18] ([i915#180] / [i915#93] / [i915#95])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl2/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
    - shard-apl:          [PASS][19] -> [DMESG-WARN][20] ([i915#180] / [i915#95])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl6/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
    - shard-tglb:         [PASS][21] -> [SKIP][22] ([i915#668]) +5 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-tglb7/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-tglb6/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-iclb8/igt@kms_psr@psr2_cursor_mmap_cpu.html

  * igt@kms_psr@suspend:
    - shard-iclb:         [PASS][25] -> [INCOMPLETE][26] ([i915#1185])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-iclb2/igt@kms_psr@suspend.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-iclb3/igt@kms_psr@suspend.html

  
#### Possible fixes ####

  * {igt@gem_ctx_isolation@preservation-s3@rcs0}:
    - shard-apl:          [DMESG-WARN][27] ([i915#180]) -> [PASS][28] +4 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl6/igt@gem_ctx_isolation@preservation-s3@rcs0.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl1/igt@gem_ctx_isolation@preservation-s3@rcs0.html

  * igt@gem_exec_balancer@hang:
    - shard-tglb:         [FAIL][29] ([i915#1277]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-tglb6/igt@gem_exec_balancer@hang.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-tglb3/igt@gem_exec_balancer@hang.html

  * igt@gem_exec_params@invalid-bsd-ring:
    - shard-iclb:         [SKIP][31] ([fdo#109276]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-iclb7/igt@gem_exec_params@invalid-bsd-ring.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-iclb4/igt@gem_exec_params@invalid-bsd-ring.html

  * igt@i915_pm_rc6_residency@rc6-idle:
    - shard-hsw:          [FAIL][33] ([i915#1516]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-hsw1/igt@i915_pm_rc6_residency@rc6-idle.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-hsw6/igt@i915_pm_rc6_residency@rc6-idle.html

  * igt@i915_selftest@live@blt:
    - shard-snb:          [DMESG-FAIL][35] ([i915#1409]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-snb4/igt@i915_selftest@live@blt.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-snb4/igt@i915_selftest@live@blt.html

  * igt@kms_color@pipe-a-ctm-green-to-red:
    - shard-kbl:          [FAIL][37] ([i915#129]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl4/igt@kms_color@pipe-a-ctm-green-to-red.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl7/igt@kms_color@pipe-a-ctm-green-to-red.html
    - shard-apl:          [FAIL][39] ([i915#129]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl2/igt@kms_color@pipe-a-ctm-green-to-red.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl4/igt@kms_color@pipe-a-ctm-green-to-red.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen:
    - shard-kbl:          [FAIL][41] ([i915#54] / [i915#93] / [i915#95]) -> [PASS][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html

  * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled:
    - shard-glk:          [FAIL][43] ([i915#52] / [i915#54]) -> [PASS][44] +5 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-glk1/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-glk1/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][45] ([i915#180] / [i915#93] / [i915#95]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@2x-plain-flip-ts-check:
    - shard-glk:          [FAIL][47] ([i915#34]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-glk5/igt@kms_flip@2x-plain-flip-ts-check.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-glk1/igt@kms_flip@2x-plain-flip-ts-check.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-apl:          [FAIL][49] ([i915#79]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl4/igt@kms_flip@flip-vs-expired-vblank.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl1/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-kbl:          [DMESG-WARN][51] ([i915#180]) -> [PASS][52] +2 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl3/igt@kms_flip@flip-vs-suspend-interruptible.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl3/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
    - shard-apl:          [FAIL][53] ([i915#53] / [i915#95]) -> [PASS][54] +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-apl4/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-apl6/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - shard-kbl:          [FAIL][55] ([i915#53] / [i915#93] / [i915#95]) -> [PASS][56] +1 similar issue
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-snb:          [DMESG-WARN][57] ([i915#42]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-snb6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-snb4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_lowres@pipe-a-tiling-none:
    - shard-kbl:          [DMESG-WARN][59] ([i915#165] / [i915#78]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl2/igt@kms_plane_lowres@pipe-a-tiling-none.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl3/igt@kms_plane_lowres@pipe-a-tiling-none.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [SKIP][61] ([fdo#109441]) -> [PASS][62] +2 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-iclb3/igt@kms_psr@psr2_no_drrs.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-iclb2/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
    - shard-kbl:          [INCOMPLETE][63] ([i915#155]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-kbl4/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-kbl6/igt@kms_vblank@pipe-b-ts-continuation-suspend.html

  * {igt@perf@blocking-parameterized}:
    - shard-iclb:         [FAIL][65] ([i915#1542]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-iclb8/igt@perf@blocking-parameterized.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-iclb4/igt@perf@blocking-parameterized.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc6-dpms:
    - shard-snb:          [SKIP][67] ([fdo#109271]) -> [INCOMPLETE][68] ([i915#82])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/shard-snb7/igt@i915_pm_dc@dc6-dpms.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/shard-snb1/igt@i915_pm_dc@dc6-dpms.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#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
  [i915#1277]: https://gitlab.freedesktop.org/drm/intel/issues/1277
  [i915#129]: https://gitlab.freedesktop.org/drm/intel/issues/129
  [i915#1409]: https://gitlab.freedesktop.org/drm/intel/issues/1409
  [i915#1516]: https://gitlab.freedesktop.org/drm/intel/issues/1516
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1566]: https://gitlab.freedesktop.org/drm/intel/issues/1566
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
  [i915#42]: https://gitlab.freedesktop.org/drm/intel/issues/42
  [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
  [i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
  [i915#70]: https://gitlab.freedesktop.org/drm/intel/issues/70
  [i915#78]: https://gitlab.freedesktop.org/drm/intel/issues/78
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
  [i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


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

  Missing    (2): pig-skl-6260u pig-glk-j5005 


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5573 -> IGTPW_4424
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4424: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4424/index.html
  IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 7.4.2020 20.42, Ville Syrjälä wrote:
> On Tue, Apr 07, 2020 at 08:24:01PM +0300, Juha-Pekka Heikkila wrote:
>> On 7.4.2020 20.10, Ville Syrjälä wrote:
>>> On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
>>>> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
>>>>> On 7.4.2020 19.08, Ville Syrjälä wrote:
>>>>>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
>>>>>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
>>>>>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>>>>>>>>> This change will slow this test down a bit. In mid test starting
>>>>>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>>>>>>>>> Use blocking commit so there's wait for modeset to happen.
>>>>>>>>
>>>>>>>> We already wait for the event the next time around. So this
>>>>>>>> doesn't make sense to me.
>>>>>>>
>>>>>>> There's those logs like this
>>>>>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
>>>>>>>
>>>>>>>
>>>>>>> where going to 64bpp pixel format will cause modeset and fail running
>>>>>>> test.
>>>>>>
>>>>>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
>>>>>> actual debug message :( Anyways, the real bug seems to be the lack of
>>>>>> ALLOW_MODESET.
>>>>>
>>>>> I'll try that and see how it changes situation. I originally had idea
>>>>> modeset will block the flip and making this commit blocking would always
>>>>> force things always into correct order as current test didn't fail every
>>>>> time for me.
>>>>
>>>> Having that commit saying
>>>>
>>>> igt_display_commit_atomic(&data->display,
>>>> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
>>>> 	DRM_MODE_ATOMIC_NONBLOCK |
>>>> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>
>>>> I see test failing as before so it will not alone fix this issue. On my
>>>> ICL box the test fail maybe 1/5 times, with the patch on list it never
>>>> failed so far.
>>>
>>> Why does it fail?
>>
>>
>> This is failure with ALLOW_MODESET
>> ---
>> (kms_plane:31238) igt_kms-DEBUG: display: }
>> (kms_plane:31238) igt_kms-CRITICAL: Test assertion failure function
>> igt_display_commit_atomic, file ../lib/igt_kms.c:3508:
>> (kms_plane:31238) igt_kms-CRITICAL: Failed assertion: ret == 0
>> (kms_plane:31238) igt_kms-CRITICAL: Last errno: 16, Device or resource busy
>> (kms_plane:31238) igt_kms-CRITICAL: error: -16 != 0
>> (kms_plane:31238) igt_core-INFO: Stack trace:
>> (kms_plane:31238) igt_core-INFO:   #0 ../lib/igt_core.c:1676
>> __igt_fail_assert()
>> (kms_plane:31238) igt_core-INFO:   #1 [igt_display_commit_atomic+0x44]
>> (kms_plane:31238) igt_core-INFO:   #2 ../tests/kms_plane.c:599
>> capture_format_crcs.constprop.14()
>> (kms_plane:31238) igt_core-INFO:   #3 ../tests/kms_plane.c:652
>> test_format_plane_colors.constprop.13()
>> (kms_plane:31238) igt_core-INFO:   #4 ../tests/kms_plane.c:728
>> test_pixel_formats.constprop.9()
>> (kms_plane:31238) igt_core-INFO:   #5 ../tests/kms_plane.c:950
>> run_tests_for_pipe_plane.constprop.8()
>> (kms_plane:31238) igt_core-INFO:   #6 ../tests/kms_plane.c:1019
>> __real_main1006()
>> (kms_plane:31238) igt_core-INFO:   #7 ../tests/kms_plane.c:1006 main()
>> (kms_plane:31238) igt_core-INFO:   #8 ../csu/libc-start.c:344
>> __libc_start_main()
>> (kms_plane:31238) igt_core-INFO:   #9 [_start+0x2a]
>> ****  END  ****
>> Stack trace:
>>     #0 ../lib/igt_core.c:1676 __igt_fail_assert()
>>     #1 [igt_display_commit_atomic+0x44]
>>     #2 ../tests/kms_plane.c:599 capture_format_crcs.constprop.14()
>>     #3 ../tests/kms_plane.c:652 test_format_plane_colors.constprop.13()
>>     #4 ../tests/kms_plane.c:728 test_pixel_formats.constprop.9()
>>     #5 ../tests/kms_plane.c:950 run_tests_for_pipe_plane.constprop.8()
>>     #6 ../tests/kms_plane.c:1019 __real_main1006()
>>     #7 ../tests/kms_plane.c:1006 main()
>>     #8 ../csu/libc-start.c:344 __libc_start_main()
>>     #9 [_start+0x2a]
>> Subtest pixel-format-pipe-A-planes-source-clamping: FAIL (22.543s)
> 
> That doesn't tell anyone anything useful. Only kernel logs can help
> diagnose the problem.
> 
> 
>> --
>>
>> Failure is ebusy. It seems round where it kick me out is not always the
>> same.
> 
> Hmm. Sounds like we have a race between sending the event vs. submitting
> a new commit :(
> 
> Hmm. What wasn't there a patch from Daniel to convert modeset commits to
> blocking to "fix" a race just like this? Ah, yeah it was EBUSY due to
> multiple pipes and noblocking modesets. Do you have multiple pipes
> enablad when it fails? That could certainly explain the race.
> 

Quickly looking there shouldn't be multiple pipes enabled. Test is one 
of those simple loops that start with for_each_plane_on_pipe(..){..} and 
different pipes are run as different tests.

>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> I was testing this on ICL and see errors randomly, on ci those
>>>>>>> seem to be less random. Making this one commit blocking will cause
>>>>>>> modeset to settle without interrupting test, at least on my ICL.
>>>>>>>
>>>>>>> If there's a way to sort those pixel formats according to bpp and start
>>>>>>> with highest there's no need for this.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>>>>>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>>>>>>>>> ---
>>>>>>>>>      tests/kms_plane.c | 6 ++----
>>>>>>>>>      1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>>>>>>>>> index 805795cd..2324fb6e 100644
>>>>>>>>> --- a/tests/kms_plane.c
>>>>>>>>> +++ b/tests/kms_plane.c
>>>>>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data,
>>>>>>>>> enum pipe pipe,
>>>>>>>>>              if (data->display.is_atomic) {
>>>>>>>>>                  /*
>>>>>>>>> -             * Use non-blocking commits to allow the next fb
>>>>>>>>> -             * to be prepared in parallel while the current fb
>>>>>>>>> -             * awaits to be latched.
>>>>>>>>> +             * Use blocking commit because there maybe
>>>>>>>>> +             * modeset when going to higher bpp pixel format.
>>>>>>>>>                   */
>>>>>>>>>                  igt_display_commit_atomic(&data->display,
>>>>>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
>>>>>>>>>                                DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>>>>>>              } else {
>>>>>>>>>                  /*
>>>>>>>>> -- 
>>>>>>>>> 2.17.1
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> igt-dev mailing list
>>>>>>>>> igt-dev@lists.freedesktop.org
>>>>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>>>>>
>>>>>>
>>>>>
>>>
> 

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

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Ville Syrjälä]

On Wed, Apr 08, 2020 at 10:08:31PM +0300, Juha-Pekka Heikkila wrote:
> On 7.4.2020 20.42, Ville Syrjälä wrote:
> > On Tue, Apr 07, 2020 at 08:24:01PM +0300, Juha-Pekka Heikkila wrote:
> >> On 7.4.2020 20.10, Ville Syrjälä wrote:
> >>> On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
> >>>> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
> >>>>> On 7.4.2020 19.08, Ville Syrjälä wrote:
> >>>>>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
> >>>>>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
> >>>>>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> >>>>>>>>> This change will slow this test down a bit. In mid test starting
> >>>>>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
> >>>>>>>>> Use blocking commit so there's wait for modeset to happen.
> >>>>>>>>
> >>>>>>>> We already wait for the event the next time around. So this
> >>>>>>>> doesn't make sense to me.
> >>>>>>>
> >>>>>>> There's those logs like this
> >>>>>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
> >>>>>>>
> >>>>>>>
> >>>>>>> where going to 64bpp pixel format will cause modeset and fail running
> >>>>>>> test.
> >>>>>>
> >>>>>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
> >>>>>> actual debug message :( Anyways, the real bug seems to be the lack of
> >>>>>> ALLOW_MODESET.
> >>>>>
> >>>>> I'll try that and see how it changes situation. I originally had idea
> >>>>> modeset will block the flip and making this commit blocking would always
> >>>>> force things always into correct order as current test didn't fail every
> >>>>> time for me.
> >>>>
> >>>> Having that commit saying
> >>>>
> >>>> igt_display_commit_atomic(&data->display,
> >>>> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
> >>>> 	DRM_MODE_ATOMIC_NONBLOCK |
> >>>> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>>>
> >>>> I see test failing as before so it will not alone fix this issue. On my
> >>>> ICL box the test fail maybe 1/5 times, with the patch on list it never
> >>>> failed so far.
> >>>
> >>> Why does it fail?
> >>
> >>
> >> This is failure with ALLOW_MODESET
> >> ---
> >> (kms_plane:31238) igt_kms-DEBUG: display: }
> >> (kms_plane:31238) igt_kms-CRITICAL: Test assertion failure function
> >> igt_display_commit_atomic, file ../lib/igt_kms.c:3508:
> >> (kms_plane:31238) igt_kms-CRITICAL: Failed assertion: ret == 0
> >> (kms_plane:31238) igt_kms-CRITICAL: Last errno: 16, Device or resource busy
> >> (kms_plane:31238) igt_kms-CRITICAL: error: -16 != 0
> >> (kms_plane:31238) igt_core-INFO: Stack trace:
> >> (kms_plane:31238) igt_core-INFO:   #0 ../lib/igt_core.c:1676
> >> __igt_fail_assert()
> >> (kms_plane:31238) igt_core-INFO:   #1 [igt_display_commit_atomic+0x44]
> >> (kms_plane:31238) igt_core-INFO:   #2 ../tests/kms_plane.c:599
> >> capture_format_crcs.constprop.14()
> >> (kms_plane:31238) igt_core-INFO:   #3 ../tests/kms_plane.c:652
> >> test_format_plane_colors.constprop.13()
> >> (kms_plane:31238) igt_core-INFO:   #4 ../tests/kms_plane.c:728
> >> test_pixel_formats.constprop.9()
> >> (kms_plane:31238) igt_core-INFO:   #5 ../tests/kms_plane.c:950
> >> run_tests_for_pipe_plane.constprop.8()
> >> (kms_plane:31238) igt_core-INFO:   #6 ../tests/kms_plane.c:1019
> >> __real_main1006()
> >> (kms_plane:31238) igt_core-INFO:   #7 ../tests/kms_plane.c:1006 main()
> >> (kms_plane:31238) igt_core-INFO:   #8 ../csu/libc-start.c:344
> >> __libc_start_main()
> >> (kms_plane:31238) igt_core-INFO:   #9 [_start+0x2a]
> >> ****  END  ****
> >> Stack trace:
> >>     #0 ../lib/igt_core.c:1676 __igt_fail_assert()
> >>     #1 [igt_display_commit_atomic+0x44]
> >>     #2 ../tests/kms_plane.c:599 capture_format_crcs.constprop.14()
> >>     #3 ../tests/kms_plane.c:652 test_format_plane_colors.constprop.13()
> >>     #4 ../tests/kms_plane.c:728 test_pixel_formats.constprop.9()
> >>     #5 ../tests/kms_plane.c:950 run_tests_for_pipe_plane.constprop.8()
> >>     #6 ../tests/kms_plane.c:1019 __real_main1006()
> >>     #7 ../tests/kms_plane.c:1006 main()
> >>     #8 ../csu/libc-start.c:344 __libc_start_main()
> >>     #9 [_start+0x2a]
> >> Subtest pixel-format-pipe-A-planes-source-clamping: FAIL (22.543s)
> > 
> > That doesn't tell anyone anything useful. Only kernel logs can help
> > diagnose the problem.
> > 
> > 
> >> --
> >>
> >> Failure is ebusy. It seems round where it kick me out is not always the
> >> same.
> > 
> > Hmm. Sounds like we have a race between sending the event vs. submitting
> > a new commit :(
> > 
> > Hmm. What wasn't there a patch from Daniel to convert modeset commits to
> > blocking to "fix" a race just like this? Ah, yeah it was EBUSY due to
> > multiple pipes and noblocking modesets. Do you have multiple pipes
> > enablad when it fails? That could certainly explain the race.
> > 
> 
> Quickly looking there shouldn't be multiple pipes enabled. Test is one 
> of those simple loops that start with for_each_plane_on_pipe(..){..} and 
> different pipes are run as different tests.

Can't see anything else returning -EBUSY except if flip_done is not
completed, and that one should be done before we send the event.

> 
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> I was testing this on ICL and see errors randomly, on ci those
> >>>>>>> seem to be less random. Making this one commit blocking will cause
> >>>>>>> modeset to settle without interrupting test, at least on my ICL.
> >>>>>>>
> >>>>>>> If there's a way to sort those pixel formats according to bpp and start
> >>>>>>> with highest there's no need for this.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> >>>>>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>>      tests/kms_plane.c | 6 ++----
> >>>>>>>>>      1 file changed, 2 insertions(+), 4 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> >>>>>>>>> index 805795cd..2324fb6e 100644
> >>>>>>>>> --- a/tests/kms_plane.c
> >>>>>>>>> +++ b/tests/kms_plane.c
> >>>>>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data,
> >>>>>>>>> enum pipe pipe,
> >>>>>>>>>              if (data->display.is_atomic) {
> >>>>>>>>>                  /*
> >>>>>>>>> -             * Use non-blocking commits to allow the next fb
> >>>>>>>>> -             * to be prepared in parallel while the current fb
> >>>>>>>>> -             * awaits to be latched.
> >>>>>>>>> +             * Use blocking commit because there maybe
> >>>>>>>>> +             * modeset when going to higher bpp pixel format.
> >>>>>>>>>                   */
> >>>>>>>>>                  igt_display_commit_atomic(&data->display,
> >>>>>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
> >>>>>>>>>                                DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>>>>>>>>              } else {
> >>>>>>>>>                  /*
> >>>>>>>>> -- 
> >>>>>>>>> 2.17.1
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> igt-dev mailing list
> >>>>>>>>> igt-dev@lists.freedesktop.org
> >>>>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset

[Juha-Pekka Heikkila]

On 9.4.2020 19.08, Ville Syrjälä wrote:
> On Wed, Apr 08, 2020 at 10:08:31PM +0300, Juha-Pekka Heikkila wrote:
>> On 7.4.2020 20.42, Ville Syrjälä wrote:
>>> On Tue, Apr 07, 2020 at 08:24:01PM +0300, Juha-Pekka Heikkila wrote:
>>>> On 7.4.2020 20.10, Ville Syrjälä wrote:
>>>>> On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
>>>>>> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
>>>>>>> On 7.4.2020 19.08, Ville Syrjälä wrote:
>>>>>>>> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
>>>>>>>>> On 7.4.2020 18.36, Ville Syrjälä wrote:
>>>>>>>>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
>>>>>>>>>>> This change will slow this test down a bit. In mid test starting
>>>>>>>>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
>>>>>>>>>>> Use blocking commit so there's wait for modeset to happen.
>>>>>>>>>>
>>>>>>>>>> We already wait for the event the next time around. So this
>>>>>>>>>> doesn't make sense to me.
>>>>>>>>>
>>>>>>>>> There's those logs like this
>>>>>>>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> where going to 64bpp pixel format will cause modeset and fail running
>>>>>>>>> test.
>>>>>>>>
>>>>>>>> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
>>>>>>>> actual debug message :( Anyways, the real bug seems to be the lack of
>>>>>>>> ALLOW_MODESET.
>>>>>>>
>>>>>>> I'll try that and see how it changes situation. I originally had idea
>>>>>>> modeset will block the flip and making this commit blocking would always
>>>>>>> force things always into correct order as current test didn't fail every
>>>>>>> time for me.
>>>>>>
>>>>>> Having that commit saying
>>>>>>
>>>>>> igt_display_commit_atomic(&data->display,
>>>>>> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
>>>>>> 	DRM_MODE_ATOMIC_NONBLOCK |
>>>>>> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>>>
>>>>>> I see test failing as before so it will not alone fix this issue. On my
>>>>>> ICL box the test fail maybe 1/5 times, with the patch on list it never
>>>>>> failed so far.
>>>>>
>>>>> Why does it fail?
>>>>
>>>>
>>>> This is failure with ALLOW_MODESET
>>>> ---
>>>> (kms_plane:31238) igt_kms-DEBUG: display: }
>>>> (kms_plane:31238) igt_kms-CRITICAL: Test assertion failure function
>>>> igt_display_commit_atomic, file ../lib/igt_kms.c:3508:
>>>> (kms_plane:31238) igt_kms-CRITICAL: Failed assertion: ret == 0
>>>> (kms_plane:31238) igt_kms-CRITICAL: Last errno: 16, Device or resource busy
>>>> (kms_plane:31238) igt_kms-CRITICAL: error: -16 != 0
>>>> (kms_plane:31238) igt_core-INFO: Stack trace:
>>>> (kms_plane:31238) igt_core-INFO:   #0 ../lib/igt_core.c:1676
>>>> __igt_fail_assert()
>>>> (kms_plane:31238) igt_core-INFO:   #1 [igt_display_commit_atomic+0x44]
>>>> (kms_plane:31238) igt_core-INFO:   #2 ../tests/kms_plane.c:599
>>>> capture_format_crcs.constprop.14()
>>>> (kms_plane:31238) igt_core-INFO:   #3 ../tests/kms_plane.c:652
>>>> test_format_plane_colors.constprop.13()
>>>> (kms_plane:31238) igt_core-INFO:   #4 ../tests/kms_plane.c:728
>>>> test_pixel_formats.constprop.9()
>>>> (kms_plane:31238) igt_core-INFO:   #5 ../tests/kms_plane.c:950
>>>> run_tests_for_pipe_plane.constprop.8()
>>>> (kms_plane:31238) igt_core-INFO:   #6 ../tests/kms_plane.c:1019
>>>> __real_main1006()
>>>> (kms_plane:31238) igt_core-INFO:   #7 ../tests/kms_plane.c:1006 main()
>>>> (kms_plane:31238) igt_core-INFO:   #8 ../csu/libc-start.c:344
>>>> __libc_start_main()
>>>> (kms_plane:31238) igt_core-INFO:   #9 [_start+0x2a]
>>>> ****  END  ****
>>>> Stack trace:
>>>>      #0 ../lib/igt_core.c:1676 __igt_fail_assert()
>>>>      #1 [igt_display_commit_atomic+0x44]
>>>>      #2 ../tests/kms_plane.c:599 capture_format_crcs.constprop.14()
>>>>      #3 ../tests/kms_plane.c:652 test_format_plane_colors.constprop.13()
>>>>      #4 ../tests/kms_plane.c:728 test_pixel_formats.constprop.9()
>>>>      #5 ../tests/kms_plane.c:950 run_tests_for_pipe_plane.constprop.8()
>>>>      #6 ../tests/kms_plane.c:1019 __real_main1006()
>>>>      #7 ../tests/kms_plane.c:1006 main()
>>>>      #8 ../csu/libc-start.c:344 __libc_start_main()
>>>>      #9 [_start+0x2a]
>>>> Subtest pixel-format-pipe-A-planes-source-clamping: FAIL (22.543s)
>>>
>>> That doesn't tell anyone anything useful. Only kernel logs can help
>>> diagnose the problem.
>>>
>>>
>>>> --
>>>>
>>>> Failure is ebusy. It seems round where it kick me out is not always the
>>>> same.
>>>
>>> Hmm. Sounds like we have a race between sending the event vs. submitting
>>> a new commit :(
>>>
>>> Hmm. What wasn't there a patch from Daniel to convert modeset commits to
>>> blocking to "fix" a race just like this? Ah, yeah it was EBUSY due to
>>> multiple pipes and noblocking modesets. Do you have multiple pipes
>>> enablad when it fails? That could certainly explain the race.
>>>
>>
>> Quickly looking there shouldn't be multiple pipes enabled. Test is one
>> of those simple loops that start with for_each_plane_on_pipe(..){..} and
>> different pipes are run as different tests.
> 
> Can't see anything else returning -EBUSY except if flip_done is not
> completed, and that one should be done before we send the event.
> 

I think that modeset somehow affects busyness. I can try this test w/o 
64bpp formats just to check out it will not fail otherwise with same 
kernel/machine. Now it seems when it's busy it's at the moment of modeset.

>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> I was testing this on ICL and see errors randomly, on ci those
>>>>>>>>> seem to be less random. Making this one commit blocking will cause
>>>>>>>>> modeset to settle without interrupting test, at least on my ICL.
>>>>>>>>>
>>>>>>>>> If there's a way to sort those pixel formats according to bpp and start
>>>>>>>>> with highest there's no need for this.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
>>>>>>>>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>>>>>>>>>>> ---
>>>>>>>>>>>       tests/kms_plane.c | 6 ++----
>>>>>>>>>>>       1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
>>>>>>>>>>> index 805795cd..2324fb6e 100644
>>>>>>>>>>> --- a/tests/kms_plane.c
>>>>>>>>>>> +++ b/tests/kms_plane.c
>>>>>>>>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data,
>>>>>>>>>>> enum pipe pipe,
>>>>>>>>>>>               if (data->display.is_atomic) {
>>>>>>>>>>>                   /*
>>>>>>>>>>> -             * Use non-blocking commits to allow the next fb
>>>>>>>>>>> -             * to be prepared in parallel while the current fb
>>>>>>>>>>> -             * awaits to be latched.
>>>>>>>>>>> +             * Use blocking commit because there maybe
>>>>>>>>>>> +             * modeset when going to higher bpp pixel format.
>>>>>>>>>>>                    */
>>>>>>>>>>>                   igt_display_commit_atomic(&data->display,
>>>>>>>>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
>>>>>>>>>>>                                 DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>>>>>>>>>>               } else {
>>>>>>>>>>>                   /*
>>>>>>>>>>> -- 
>>>>>>>>>>> 2.17.1
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> igt-dev mailing list
>>>>>>>>>>> igt-dev@lists.freedesktop.org
>>>>>>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
> 

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