Summary: | [CI][SHARDS] igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic - fail - Test assertion failure function igt_display_commit_atomic, Failed assertion: ret == 0, Last errno: 16, Device or resource busy | ||
---|---|---|---|
Product: | DRI | Reporter: | Martin Peres <martin.peres> |
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | low | CC: | intel-gfx-bugs |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | GLK, KBL | i915 features: | display/atomic |
Description
Martin Peres
2018-07-27 13:55:41 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4624/shard-glk9/igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing.html (kms_atomic_transition:1240) igt_kms-CRITICAL: Test assertion failure function igt_display_commit_atomic, file ../lib/igt_kms.c:3325: (kms_atomic_transition:1240) igt_kms-CRITICAL: Failed assertion: ret == 0 (kms_atomic_transition:1240) igt_kms-CRITICAL: Last errno: 16, Device or resource busy (kms_atomic_transition:1240) igt_kms-CRITICAL: error: -16 != 0 Subtest 1x-modeset-transitions-nonblocking-fencing failed. Also seen on ICL https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_158/fi-icl-u2/igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic.html Starting subtest: 2x-nonblocking-modeset-vs-cursor-atomic (kms_cursor_legacy:1066) igt_kms-CRITICAL: Test assertion failure function igt_display_commit_atomic, file ../lib/igt_kms.c:3395: (kms_cursor_legacy:1066) igt_kms-CRITICAL: Failed assertion: ret == 0 (kms_cursor_legacy:1066) igt_kms-CRITICAL: Last errno: 16, Device or resource busy (kms_cursor_legacy:1066) igt_kms-CRITICAL: error: -16 != 0 Subtest 2x-nonblocking-modeset-vs-cursor-atomic failed. Comments from Maarten: Impact: cursor on crtc 1 might be lagging when a nonblocking modeset happens on crtc2. However the most common situation is that a modeset is done blockingly, in which case cursor hangs anyway, so low impact. A CI Bug Log filter associated to this bug has been updated: {- GLK ICL: igt@*nonblocking-modeset* - fail - Failed assertion: ret == 0, Last errno: 16, Device or resource busy -} {+ GLK: igt@*nonblocking-modeset* - fail - Failed assertion: ret == 0, Last errno: 16, Device or resource busy +} No new failures caught with the new filter (In reply to CI Bug Log from comment #4) > A CI Bug Log filter associated to this bug has been updated: > > {- GLK ICL: igt@*nonblocking-modeset* - fail - Failed assertion: ret == 0, > Last errno: 16, Device or resource busy -} > {+ GLK: igt@*nonblocking-modeset* - fail - Failed assertion: ret == 0, Last > errno: 16, Device or resource busy +} > > No new failures caught with the new filter Dropping ICL since it was seen only once, 4 months ago, and the hardware and firmware versions have significantly changed since then. As for the reproduction rate on GLK, this is only seen on shards, and multiple times per week (on average once every 12-15 runs) except for 2 weeks where it was not seen. The two affected tests are equally impacted, so nothing too interesting here. What the test is doing is nonblocking modesets on one crtc and nonblocking page flips on the cursor plane on another crtc. This can happen when we're moving the mouse around the screen and changing the image to react to the mouse context (text selection etc), and at the same time changing the resolution of another screen, hotplugging another monitor, .... The failure here is getting EBUSY from the atomic commit, meaning the kernel had an earlier update pending. (In reply to Petri Latvala from comment #6) > What the test is doing is nonblocking modesets on one crtc and nonblocking > page flips on the cursor plane on another crtc. This can happen when we're > moving the mouse around the screen and changing the image to react to the > mouse context (text selection etc), and at the same time changing the > resolution of another screen, hotplugging another monitor, .... > > The failure here is getting EBUSY from the atomic commit, meaning the kernel > had an earlier update pending. Thanks, based on this and Maarten's assessment, I think we can agree that this is a low priority, especially since this is happening ONLY on GLK which is a low power device usually used only by tablets, IVI systems, ... which do not use a cursor :D NUCs are the exception, but one does not usually change resolutions in a desktop PC. A CI Bug Log filter associated to this bug has been updated: {- GLK igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic fail - Test assertion failure Last errno: 16, Device or resource busy -} {+ GLK KBL: igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic fail - Test assertion failure Last errno: 16, Device or resource busy +} New failures caught by the filter: * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_349/fi-kbl-7500u/igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic.html -- 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/133. |
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.