Bug 109079 - [CI][DRMTIP] igt@kms_cursor_legacy@2x-(long-)?cursor-vs-flip-(legacy|atomic) - fail - Failed assertion: shared[child] > vrefresh[child]*target[child] / 2
Summary: [CI][DRMTIP] igt@kms_cursor_legacy@2x-(long-)?cursor-vs-flip-(legacy|atomic) ...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: high normal
Assignee: Neel
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-17 17:36 UTC by Martin Peres
Modified: 2019-11-22 19:33 UTC (History)
2 users (show)

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


Attachments

Description Martin Peres 2018-12-17 17:36:42 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_171/fi-icl-u3/igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_172/fi-icl-u3/igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_169/fi-icl-u3/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_172/fi-icl-u3/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html

Starting subtest: 2x-long-cursor-vs-flip-atomic
(kms_cursor_legacy:2461) CRITICAL: Test assertion failure function two_screens_cursor_vs_flip, file ../tests/kms_cursor_legacy.c:1207:
(kms_cursor_legacy:2461) CRITICAL: Failed assertion: shared[child] > vrefresh[child]*target[child] / 2
(kms_cursor_legacy:2461) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_cursor_legacy:2461) CRITICAL: completed 256 cursor updated in a period of 30 flips, we expect to complete approximately 7680 updates, with the threshold set at 3840
Subtest 2x-long-cursor-vs-flip-atomic failed.

This may be related to https://bugs.freedesktop.org/show_bug.cgi?id=103355
Comment 1 Martin Peres 2018-12-17 17:39:30 UTC
Oops, this was a drmtip run, sorry for the noise!
Comment 2 CI Bug Log 2019-02-26 13:13:57 UTC
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
Comment 3 Neel 2019-03-11 16:25:10 UTC
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...
Comment 4 Ville Syrjala 2019-03-11 16:36:30 UTC
(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.
Comment 5 Neel 2019-03-12 16:20:25 UTC
Patch submitted for review
Comment 6 Neel 2019-03-15 03:39:25 UTC
@Ville: Your patch series:skl+ cursor DDB allocation fixes  on top of drm-tip resolves the issue.
Comment 7 Jani Saarinen 2019-04-05 19:00:42 UTC
Series has been merged, resolving.
Comment 8 Martin Peres 2019-04-17 14:51:59 UTC
(In reply to Jani Saarinen from comment #7)
> Series has been merged, resolving.

Seems like it landed in drmtip_252.
Comment 9 CI Bug Log 2019-04-17 14:52:04 UTC
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.
Comment 10 CI Bug Log 2019-05-31 09:40:18 UTC
The CI Bug Log issue associated to this bug has been restored.

All the previous filters are now active.
Comment 11 Lakshmi 2019-05-31 09:41:44 UTC
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.
Comment 12 Maarten Lankhorst 2019-05-31 12:54:00 UTC
Please open a new bug, this is a regression, most likely from the ICL bandwidth series.
Comment 13 swathi.dhanavanthri 2019-11-22 19:33:31 UTC
Last seen drmtip_299 (5 months, 3 weeks old) not seen in the last 108 runs, so closing and archiving this
Comment 14 CI Bug Log 2019-11-22 19:33:43 UTC
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.