https://bugs.freedesktop.org/show_bug.cgi?id=102670
Arek Hiler <arkadiusz.hi...@intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
i915 platform|BXT, GLK, HSW, I915G, KBL, |ALL
|SKL, SNB |
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org |
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
|sktop.org |.org
CC| |arkadiusz.hi...@intel.com
Component|DRM/Intel |IGT
--- Comment #17 from Arek Hiler <arkadiusz.hi...@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._______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
