Summary: | [CI][DRMTIP] igt@kms_cursor_legacy@2x-(long-)?cursor-vs-flip-(legacy|atomic) - fail - Failed assertion: shared[child] > vrefresh[child]*target[child] / 2 | ||
---|---|---|---|
Product: | DRI | Reporter: | Martin Peres <martin.peres> |
Component: | DRM/Intel | Assignee: | Neel <neel.desai> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | high | CC: | intel-gfx-bugs, sudeep.dutt |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | ICL | i915 features: | display/Other |
Description
Martin Peres
2018-12-17 17:36:42 UTC
Oops, this was a drmtip run, sorry for the noise! A CI Bug Log filter associated to this bug has been updated: {- ICL: igt@kms_cursor_legacy@2x-(long-)?cursor-vs-flip-(legacy|atomic) - fail - Failed assertion: shared[child] > vrefresh[child]*target[child] / 2 -} {+ ICL: igt@kms_cursor_legacy@2x-(long-)?cursor-vs-flip-(legacy|atomic) - fail/dmesg-fail - Failed assertion: shared[child] > vrefresh[child]*target[child] / 2 +} New failures caught by the filter: * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_230/fi-icl-u2/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html Due to the DDB allocation changes, we have to add all the planes in the drm_atomic_state post gen 9. When the watermarks are computed by the kernel, the cursor plane is added to the state. This introduces a dependency between the code that processes DRM_IOCTL_MODE_ATOMIC and DRM_IOCTL_MODE_CURSOR. This is a corner case and there is no race-free way to handle this. The important thing is that we do not crash. These tests made sense < gen 9 but now, we have to block all crtc updates during modeset. So, I will be relaxing the test to skip the 2x-(long)cursor-vs-flip(atomic | legacy) subtests for gen 9+ Patch underway... (In reply to Neel from comment #3) > Due to the DDB allocation changes, we have to add all the planes in the > drm_atomic_state post gen 9. When the watermarks are computed by the kernel, > the cursor plane is added to the state. This introduces a dependency between > the code that processes DRM_IOCTL_MODE_ATOMIC and DRM_IOCTL_MODE_CURSOR. > This is a corner case and there is no race-free way to handle this. The > important thing is that we do not crash. These tests made sense < gen 9 but > now, we have to block all crtc updates during modeset. So, I will be > relaxing the test to skip the 2x-(long)cursor-vs-flip(atomic | legacy) > subtests for gen 9+ > > Patch underway... We use a fixed ddb allocation for the cursor. Hence its allocation should not change when other planes' allocations change. Patch submitted for review @Ville: Your patch series:skl+ cursor DDB allocation fixes on top of drm-tip resolves the issue. Series has been merged, resolving. (In reply to Jani Saarinen from comment #7) > Series has been merged, resolving. Seems like it landed in drmtip_252. The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. The CI Bug Log issue associated to this bug has been restored. All the previous filters are now active. Occurring again on ICL, reopened the bug. https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_296/fi-icl-u3/igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic.html Starting subtest: 2x-cursor-vs-flip-atomic (kms_cursor_legacy:1293) CRITICAL: Test assertion failure function two_screens_cursor_vs_flip, file ../tests/kms_cursor_legacy.c:1213: (kms_cursor_legacy:1293) CRITICAL: Failed assertion: shared[child] > vrefresh[child]*target[child] / 2 (kms_cursor_legacy:1293) CRITICAL: completed 77 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680 Subtest 2x-cursor-vs-flip-atomic failed. Please open a new bug, this is a regression, most likely from the ICL bandwidth series. Last seen drmtip_299 (5 months, 3 weeks old) not seen in the last 108 runs, so closing and archiving this The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. |
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.