https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_169/fi-cfl-8109u/igt@kms_vblank@pipe-c-query-forked-hang.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-icl-u3/igt@kms_lease@lease_revoke.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_171/fi-icl-u3/igt@kms_lease@simple_lease.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_175/fi-icl-u3/igt@kms_cursor_crc@cursor-128x42-offscreen.html

A CI Bug Log filter associated to this bug has been updated:

{- CFL ICL: igt@kms_* - fail - Failed assertion: igt_ioctl\(\(fd\),(.*)\n[^\n]*Last errno: 22, Invalid argument -}
{+ CFL ICL: igt@kms_* - fail - Failed assertion: igt_ioctl\(\(fd\),(.*)\n[^\n]*Last errno: 22, Invalid argument +}

New failures caught by the filter:

* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_196/fi-icl-u3/igt@kms_chv_cursor_fail@pipe-c-256x256-bottom-edge.html
* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_178/fi-icl-u3/igt@kms_chv_cursor_fail@pipe-c-256x256-bottom-edge.html

A CI Bug Log filter associated to this bug has been updated:

{- CFL ICL: igt@kms_* - fail - Failed assertion: igt_ioctl\(\(fd\),(.*)\n[^\n]*Last errno: 22, Invalid argument -}
{+ CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0 +}

 No new failures caught with the new filter

The current reproduction rate is once every 10 drmtip runs, last seen on drmtip_209. Let's wait until drmtip_309!

A CI Bug Log filter associated to this bug has been updated:

{- CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0 -}
{+ CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0 +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_321/fi-icl-u4/igt@kms_color@pipe-c-ctm-green-to-red.html

A CI Bug Log filter associated to this bug has been updated:

{- CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0 -}
{+ CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0 +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_329/fi-icl-u4/igt@kms_vblank@pipe-a-ts-continuation-modeset.html

Ultimately the failure here originates on the test side rather than the driver side; the final cause of failure here is pretty simple:  IGT's fb creation routine is calling DRM_IOCTL_MODE_CREATE_DUMB asking for a framebuffer with dimensions 0x0, which is illegal and rejected by the kernel.  However why that's happening is a bit more complicated; a common pattern in our IGT tests when we decide to utilize a specific output is to call igt_output_get_mode() to get the size of the display and then immediately create a framebuffer of that size (e.g., via igt_create_color_fb).  However if the output is considered disconnected by the time we get to this point in the test, the output's mode list and default mode will have been zeroed out and mode->hdisplay / mode->vdisplay will be 0 which ultimately leads to the failure here during fb creation.

There are a lot of different tests that follow this pattern (and thus are susceptible to this bug), and in the dmesg logs I looked at I always saw something that was updating connector state during the test -- either hotplug events or temporary failures to get DPCD responses from DP++ adapters.  I assume nobody is actually plugging/unplugging the cables while these tests are running, so this may just be random fallout of faulty or loose cables on the CI machines.

We probably need to write our tests more defensively to avoid situations like this somehow.  We know that 0x0 isn't a valid framebuffer size that we actually want to create, so one solution might be to just force a test skip in create_bo_for_fb() any time we see a 0x0 size requested, under the assumption that we only get to this point because the calling test lost its monitor but didn't notice.  That seems like kind of an indirect solution to the problem here, so I'm not super happy with it.  This really feels like more of an igt_kms wrapper design issue (which is something that I'm still not 100% familiar with despite having worked with KMS IGT's for a long time).  Finally we could write more defensive logic into each individual test to account for hot-unplugged monitors and such at the point we go to create fb's.

I think it would be good to have someone on the CI team (or an expert on the igt_kms wrapper library) make a judgment call on what the proper path forward is on this.  @Martin, any thoughts?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/201.