[Bug 103355] [CI][SHARDS] igt at kms_cursor_legacy@cursor-vs-flip-* - fail - Failed assertion: shared[0] > vrefresh*target / 2

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103355

--- Comment #20 from anusha <anusha.srivatsa at intel.com> ---
(In reply to Martin Peres from comment #19)
> (In reply to Arek Hiler from comment #18)
> > The test is checking how many cursor updates we can fit between vblanks, and
> > treating that as a baseline. Then it does 30 flips and checks whether we fit
> > expected (num_of_flips * baseline / 8) amount of cursor updates. The check
> > is done 50 times.
> > 
> > We fails this check but yet the cursor refresh rate for each failure is well
> > above 1k (per 30 flips) and there are really no sense in having mouses with
> > refresh rates higher than 1kHz.
> > 
> > The customer impact is low.
> > 
> > The test needs some rethinking and possibly updated pass criteria.
> 
> Anusha, please update the test to clip the wanted refresh rate to 1kHz,
> anything above above is useless and just adds noise.

I dont think that will work. The test checks that a certain amount (targeteted
amount) of cursor updates happens between vblanks and that flip do not affect
vblank counter. The subtest already sets the targetted cursor updates to a
pretty low value, despite that the test fails.  We need to understand -
1. how the flips are affecting the vblanks
2. why particularly in ICL we are not able to do that many number of cursor
updates. (that is assuming this test was passing on non ICL systems). I plan on
seeing the behaviour on my KBL system.

Also, just out of curiosity I did change the target value to see if at any
point the test passes. it doesnt. Regardless of how less we set the cursor
update, we fail to achieve that in the given interval.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190404/270eb861/attachment.html>