[igt-dev] i915/gem_exec_fair: Fix failed assertion

[Ram Moon, AnandX]

Hi Tvrtko Ursulin,

-----Original Message-----
From: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> 
Sent: Tuesday, February 23, 2021 10:05 PM
To: Ram Moon, AnandX <anandx.ram.moon at intel.com>; igt-dev at lists.freedesktop.org
Subject: Re: [igt-dev] i915/gem_exec_fair: Fix failed assertion


On 23/02/2021 14:08, Anand Moon wrote:
> Changes fix the Failed assertion below
> 
> (gem_exec_fair:1606) CRITICAL: Test assertion failure function deadline, file ../tests/i915/gem_exec_fair.c:1163:
> (gem_exec_fair:1606) CRITICAL: Failed assertion: missed == 0
> (gem_exec_fair:1606) CRITICAL: 1 child, missed 60 frames, overran by 
> 20095804us Subtest basic-deadline failed.
> 
> Signed-off-by: Anand Moon <anandx.ram.moon at intel.com>
> ---
>   tests/i915/gem_exec_fair.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c 
> index c1a71f77..9d6f9d50 100644
> --- a/tests/i915/gem_exec_fair.c
> +++ b/tests/i915/gem_exec_fair.c
> @@ -1158,7 +1158,7 @@ static void deadline(int i915, int duration, unsigned int flags)
>   		igt_waitchildren();
>   		close(timeline);
>   
> -		igt_assert_f(missed == 0,
> +		igt_assert_f(missed >= 0,
>   			     "%d child, missed %d frames, overran by %'"PRIu64"us\n",
>   			     num_children, missed, over / 1000);
>   
> 

It's not very good to allow unlimited missed frames. It's akin to turning that assert into igt_info. Which may be okay in itself, given the "red" history of the test in CI. At least until the scheduling improvements land.

Or take a platform where test mostly fails, like SKL or GLK, and try to figure out what is the cause of failure. Is it a test bug, like trying to do too much, too many clients, or a consequence of currently limited
i915 scheduling.

If you are not familiar with the area, or need help translating the test code into "theory of operation", I can help with that (might take some time to figure it out), or Chris (test author) might jump in.


Regards,

Tvrtko

Opps, I know the theory of operation behind this and I have debug this, but I will try to find the root cause of the assertion. 

Thanks
-Anand