[Bug 111603] [CI][DRMTIP] igt at kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: __gem_create(fd, size, &handle) == 0, error: -22 != 0

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Sep 26 20:19:48 UTC 2019


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

--- Comment #2 from Matt Roper <matthew.d.roper at intel.com> ---
There aren't enough debugging messages in the gem_create path to know with 100%
certainty, but based on the clues here it appears this is quite likely another
case of a display link going down mid-test:

<7>[   30.093477] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:95:DP-2] status updated from connected to disconnected

which results in the mode obtained by the test being 0x0.  The test fails to
notice and attempts to allocate a 0-sized framebuffer, which will be rejected
with -EINVAL (-22) in i915_gem_create().

End-user impact of this should be nil (if a monitor is unplugged then a hotplug
event is sent to userspace and handled appropriately by whatever graphical
environment is running).  But the impact of this sequence of events on general
CI stability is a bit higher.  I know we've got other fdo bugs that are all
triggered by the same general sequence of events where a display connection
goes down mid-test (maybe due to flaky cables, dying boards, or just plain
loose cables) and IGT doesn't notice so it tries to allocate 0-sized
framebuffers for this inactive mode; when the kernel (correctly) rejects the
buffer creation ioctl, IGT registers that as a test failure, even though the
behavior doesn't have anything to do with what the test app was attempting to
exercise.

We probably need a strategy for IGT tests (all IGT tests, not just this one) to
react to unexpected mid-test hot(un)plugs that occur due to flaky
hardware/dongles/cables/etc.  Or at the very least, force all of these
occurrences across all IGT tests to fail with one easily-recognizable signature
so that we can capture them all in a single bug.

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


More information about the intel-gfx-bugs mailing list