Bug 109088 - [CI][DRMTIP]igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge - 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
Summary: [CI][DRMTIP]igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge - Fail - Failed a...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-18 20:28 UTC by Lakshmi
Modified: 2019-09-09 20:56 UTC (History)
3 users (show)

See Also:
i915 platform: CFL, ICL
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshmi 2018-12-18 20:28:44 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_173/fi-icl-u3/igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge.html

Starting subtest: pipe-C-128x128-top-edge
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: Test assertion failure function kmstest_dumb_create, file ../lib/igt_kms.c:608:
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: 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
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: Last errno: 22, Invalid argument
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: error: -1 != 0
Subtest pipe-C-128x128-top-edge failed.
**** DEBUG ****
(kms_chv_cursor_fail:1284) igt_kms-DEBUG: display: HDMI-A-2: set_pipe(C)
(kms_chv_cursor_fail:1284) igt_kms-DEBUG: display: HDMI-A-2: Selecting pipe C
(kms_chv_cursor_fail:1284) igt_fb-DEBUG: igt_create_fb_with_bo_size(width=0, height=0, format=0x34325258, tiling=0x0, size=0)
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: Test assertion failure function kmstest_dumb_create, file ../lib/igt_kms.c:608:
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: 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
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: Last errno: 22, Invalid argument
(kms_chv_cursor_fail:1284) igt_kms-CRITICAL: error: -1 != 0
(kms_chv_cursor_fail:1284) igt_core-INFO: Stack trace:
(kms_chv_cursor_fail:1284) igt_core-INFO:   #0 ../lib/igt_core.c:1467 __igt_fail_assert()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #1 ../lib/igt_kms.c:608 kmstest_dumb_create()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #2 ../lib/igt_fb.c:524 create_bo_for_fb()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #3 ../lib/igt_fb.c:930 igt_create_fb_with_bo_size()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #4 ../lib/igt_fb.c:969 igt_create_fb()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #5 ../lib/igt_fb.c:1041 igt_create_pattern_fb()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #6 ../tests/kms_chv_cursor_fail.c:247 prepare_crtc()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #7 ../tests/kms_chv_cursor_fail.c:268 test_crtc()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #8 ../tests/kms_chv_cursor_fail.c:358 main()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #9 ../csu/libc-start.c:344 __libc_start_main()
(kms_chv_cursor_fail:1284) igt_core-INFO:   #10 [_start+0x2a]
****  END  ****
Subtest pipe-C-128x128-top-edge: FAIL (0.137s)
Comment 3 CI Bug Log 2019-01-25 09:02:40 UTC
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
Comment 4 CI Bug Log 2019-04-10 13:24:33 UTC
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) &lt;&lt; (((0+8)+8)+14)) | (((&#39;d&#39;)) &lt;&lt; (0+8)) | (((0xB2)) &lt;&lt; 0) | ((((sizeof(struct drm_mode_create_dumb)))) &lt;&lt; ((0+8)+8)))), (&amp;create)) == 0 +}

 No new failures caught with the new filter
Comment 5 Martin Peres 2019-04-23 11:28:54 UTC
The current reproduction rate is once every 10 drmtip runs, last seen on drmtip_209. Let's wait until drmtip_309!
Comment 6 CI Bug Log 2019-07-08 08:42:55 UTC
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) &lt;&lt; (((0+8)+8)+14)) | (((&#39;d&#39;)) &lt;&lt; (0+8)) | (((0xB2)) &lt;&lt; 0) | ((((sizeof(struct drm_mode_create_dumb)))) &lt;&lt; ((0+8)+8)))), (&amp;create)) == 0 -}
{+ CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) &lt;&lt; (((0+8)+8)+14)) | (((&#39;d&#39;)) &lt;&lt; (0+8)) | (((0xB2)) &lt;&lt; 0) | ((((sizeof(struct drm_mode_create_dumb)))) &lt;&lt; ((0+8)+8)))), (&amp;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
Comment 7 CI Bug Log 2019-07-23 07:24:54 UTC
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) &lt;&lt; (((0+8)+8)+14)) | (((&#39;d&#39;)) &lt;&lt; (0+8)) | (((0xB2)) &lt;&lt; 0) | ((((sizeof(struct drm_mode_create_dumb)))) &lt;&lt; ((0+8)+8)))), (&amp;create)) == 0 -}
{+ CFL ICL: some kms tests - fail - Failed assertion: igt_ioctl((fd), ((((2U|1U) &lt;&lt; (((0+8)+8)+14)) | (((&#39;d&#39;)) &lt;&lt; (0+8)) | (((0xB2)) &lt;&lt; 0) | ((((sizeof(struct drm_mode_create_dumb)))) &lt;&lt; ((0+8)+8)))), (&amp;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
Comment 8 Matt Roper 2019-09-09 20:56:16 UTC
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?


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.