[igt-dev] ✗ Fi.CI.IGT: failure for tests: Add variable refresh rate tests (rev4)

[Nicholas Kazlauskas]

On 2019-01-29 4:51 a.m., Petri Latvala wrote:
> On Mon, Jan 28, 2019 at 09:32:37PM +0000, Patchwork wrote:
>> == Series Details ==
>>
>> Series: tests: Add variable refresh rate tests (rev4)
>> URL   : https://patchwork.freedesktop.org/series/54960/
>> State : failure
>>
>> == Summary ==
>>
>> CI Bug Log - changes from CI_DRM_5494_full -> IGTPW_2309_full
>> ====================================================
>>
>> Summary
>> -------
>>
>>    **FAILURE**
>>
>>    Serious unknown changes coming with IGTPW_2309_full absolutely need to be
>>    verified manually.
>>    
>>    If you think the reported changes have nothing to do with the changes
>>    introduced in IGTPW_2309_full, please notify your bug team to allow them
>>    to document this new failure mode, which will reduce false positives in CI.
>>
>>    External URL: https://patchwork.freedesktop.org/api/1.0/series/54960/revisions/4/mbox/
>>
>> Possible new issues
>> -------------------
>>
>>    Here are the unknown changes that may have been introduced in IGTPW_2309_full:
>>
>> ### IGT changes ###
>>
>> #### Possible regressions ####
>>
>>    * igt at kms_busy@basic-modeset-a:
>>      - shard-apl:          PASS -> FAIL +2
>>      - shard-glk:          PASS -> FAIL +3
>>      - shard-snb:          PASS -> FAIL +2
>>
>>    * igt at kms_busy@basic-modeset-b:
>>      - shard-kbl:          PASS -> FAIL +3
>>
>>    * igt at kms_busy@basic-modeset-c:
>>      - shard-apl:          NOTRUN -> FAIL
>>
>>    * igt at kms_vblank@crtc-id:
>>      - shard-hsw:          PASS -> FAIL +3
>>
> 
> 
> On Mon, Jan 28, 2019 at 04:00:47PM +0000, Wentland, Harry wrote:
>> I'll merge it if it passes Intel's CI.
> 
> 
> This got merged after BAT passed, but before the full round was
> run. For the record, Fi.CI.BAT is the basic test round that determines
> if the patch set is obviously broken, and Fi.CI.IGT is the real thing
> with most IGT tests run.
> 
> 
> The failures are filed as
> https://bugs.freedesktop.org/show_bug.cgi?id=109490 and follow the
> pattern of
> 
> (kms_busy:1080) CRITICAL: Test assertion failure function flip_to_fb, file ../tests/kms_busy.c:125:
> (kms_busy:1080) CRITICAL: Failed assertion: nanosleep(&tv, NULL) == -1
> (kms_busy:1080) CRITICAL: flip to fb[0] blocked waiting for busy fb
> 
> 
> 
> I did some quick testing and the value of the property is already 0
> when we try to set it. Didn't investigate further.
> 
> What do you suggest as the plan forward?
> 
> 1)
> 
>   if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED) &&
>       igt_pipe_obj_get_prop(pipe, IGT_CRTC_VRR_ENABLED))
>     igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
> 
> 
> 2)
> 
>   "It's a kernel bug, lemme fix that real quick"
> 
> 
> 3)
> 
>   "It's a bug in kms_busy.c, lemme fix that real quick"
> 
> 
> 4)
> 
>   Revert and do further debugging
> 
> 
> 

Is this actually caused by this patch? Seems rather odd that this would 
introduce a bug here from what's in the logs.

 From what you're saying it doesn't sound like (1) would help solve 
anything. So in the meantime I don't mind reverting (4) for now if you 
think it's the problem, however. I'll leave that up to you or Harry.

Thanks!

Nicholas Kazlauskas