[Bug 110536] [CI][DRMTIP] igt at kms_flip@busy-flip - fail - Failed assertion: do_page_flip(o, new_fb_id, 0) == -16

[bugzilla-daemon at freedesktop.org]

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

Matt Roper <matthew.d.roper at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
                 CC|                            |matthew.d.roper at intel.com
           Priority|medium                      |low

--- Comment #5 from Matt Roper <matthew.d.roper at intel.com> ---
Our pageflip ioctl is supposed to return -EBUSY to userspace if a second
pageflip is submitted while a first is still pending.  This test tries to
exercise that by attempting to submit two flip requests within the same vblank
(since the first flip won't be able to complete if the vblank hasn't happened
yet); in this case the second flip is occasionally returning a success return
code rather than -EBUSY, hence the failure.

The problem here most likely does not arise from the kernel behavior, but
rather from the fragility of the testing approach.  The test software in
userspace doesn't have any way to guarantee that both flips are actually
submitted within the same vblank, so any unexpected delay in OS scheduling
could cause the two flips to land in different vblanks; when that happens the
first flip has already completed before the second is issued, to the second
flip is successful (rather than EBUSY) and the test sees that as incorrect
behavior.  The test attempts to mitigate this unluckiness as much as possible
by doing a forced vblank wait before the first flip in the hopes that the first
flip will happen very shortly after the vblank and give the second flip time to
be submitted within the same window, but this strategy is not foolproof and
unexpected scheduling delay caused by other background tasks can still cause
one or both of the flips to be issued later than we'd hope.  It's probably not
surprising that the occasional failures we get from this test happen on some of
our slowest machines (atom rather than core).

Since we can't absolutely guarantee that both flips are submitted within the
same vblank window, one alternative to consider would be to try to make the
first flip take longer than a single vblank to complete.  Flips will block
until outstanding rendering against their framebuffer is completed, so issuing
a complicated render operation on the first framebuffer being flipped could
make that flip take multiple vblank periods to complete, effectively extending
the window for us to submit a second flip and receive -EBUSY.  Of course
performing complicated rendering operations in IGT without a full GL stack
isn't terribly easy either.  Maybe another alternative would be a debugfs
interface that causes the very next flip issued to take an artificially long
time to complete by internally creating a fence that the flip must wait on?

There shouldn't be any end-user impact here, only a small impact to CI from
false positive failures.  Marking this bug as 'low' importance.

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