[Bug 102670] [CI] igt at kms_cursor_legacy@*flip-vs-cursor-* Failed assertion: get_vblank(display->drm_fd, pipe, 0) == *
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Apr 11 11:20:24 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=102670
Arek Hiler <arkadiusz.hiler at intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
i915 platform|BXT, GLK, HSW, I915G, KBL, |ALL
|SKL, SNB |
QA Contact|intel-gfx-bugs at lists.freede |
|sktop.org |
Assignee|intel-gfx-bugs at lists.freede |dri-devel at lists.freedesktop
|sktop.org |.org
CC| |arkadiusz.hiler at intel.com
Component|DRM/Intel |IGT
--- Comment #17 from Arek Hiler <arkadiusz.hiler at intel.com> ---
The test seems to be very prone to race conditions and this may explain the
sporadic failures we see (few instances every week, affects all the machines):
1. we try to figure out experimentally how many cursor updates we can squeeze
between vblanks, by starting with a high number and lowering it until we fit.
Our target is a quarter of that
2. we pin our process to a CPU and fork a busy loop with sched_yield();
3. 150 loops of trying to squeeze target cursor updates within one vblank
This doesn't take power and thermal budged into account and makes a lot of
assumptions about process scheduling on a non-RTOS.
User impact is low. We loose some coverage. Test needs to be reworked.
Immediate steps:
1. log the delta between vblanks, so we can regain some coverage by having
better filters
2. log our target
3. don't exit early, show how many iterations of the 150 had failed
This is related and it makes sense to work on both together:
https://bugs.freedesktop.org/show_bug.cgi?id=103355
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190411/342f3b5d/attachment.html>
More information about the dri-devel
mailing list