<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][DRMTIP] igt@kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: __gem_create(fd, size, &handle) == 0, error: -22 != 0" href="https://bugs.freedesktop.org/show_bug.cgi?id=111603#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][DRMTIP] igt@kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: __gem_create(fd, size, &handle) == 0, error: -22 != 0" href="https://bugs.freedesktop.org/show_bug.cgi?id=111603">bug 111603</a> from <a class="email" href="mailto:matthew.d.roper@intel.com" title="Matt Roper <matthew.d.roper@intel.com>"> Matt Roper</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>