Bug 111603 - [CI][DRMTIP] igt@kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: __gem_create(fd, size, &handle) == 0, error: -22 != 0
Summary: [CI][DRMTIP] igt@kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: ...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: not set not set
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-09 10:11 UTC by Lakshmi
Modified: 2019-09-26 20:19 UTC (History)
1 user (show)

See Also:
i915 platform: CFL
i915 features: display/Other


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshmi 2019-09-09 10:11:47 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-cfl-8109u/igt@kms_ccs@pipe-b-crc-primary-basic.html

Starting subtest: pipe-B-crc-primary-basic
(kms_ccs:1039) ioctl_wrappers-CRITICAL: Test assertion failure function gem_create, file ../lib/ioctl_wrappers.c:575:
(kms_ccs:1039) ioctl_wrappers-CRITICAL: Failed assertion: __gem_create(fd, size, &handle) == 0
(kms_ccs:1039) ioctl_wrappers-CRITICAL: error: -22 != 0
Subtest pipe-B-crc-primary-basic failed.
Comment 1 CI Bug Log 2019-09-09 10:31:50 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* CFL: igt@kms_ccs@pipe-b-crc-primary-basic - fail - Failed assertion: __gem_create(fd, size, &handle) == 0, error: -22 != 0
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-cfl-8109u/igt@kms_ccs@pipe-b-crc-primary-basic.html
Comment 2 Matt Roper 2019-09-26 20:19:48 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.