Bug 112027 - [CI][RESUME] igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0
Summary: [CI][RESUME] igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed asse...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: low minor
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2019-10-16 11:08 UTC by Lakshmi
Modified: 2019-11-29 19:41 UTC (History)
3 users (show)

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


Description Lakshmi 2019-10-16 11:08:39 UTC
Starting subtest: 2x-scaler-multi-pipe
(kms_plane_scaling:1493) igt_kms-CRITICAL: Test assertion failure function do_display_commit, file ../lib/igt_kms.c:3464:
(kms_plane_scaling:1493) igt_kms-CRITICAL: Failed assertion: ret == 0
(kms_plane_scaling:1493) igt_kms-CRITICAL: Last errno: 22, Invalid argument
(kms_plane_scaling:1493) igt_kms-CRITICAL: error: -22 != 0
Subtest 2x-scaler-multi-pipe failed.
Comment 1 CI Bug Log 2019-10-16 11:09:31 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* TGL:  igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7093/re-tgl-u/igt@kms_plane_scaling@2x-scaler-multi-pipe.html
Comment 2 Swati Sharma 2019-10-18 06:46:33 UTC
From logs it can be seen 
<7> [886.185133] [drm:intel_atomic_setup_scalers [i915]] Too many scaling requests 3 > 2

Available 2 scalers, however requested for 3. Can this cause an issue?
Comment 3 Matt Roper 2019-10-29 23:01:53 UTC
Yes, Swati is correct; the issue is that the test is trying to use too many scalers.  The test only explicitly enables two plane scalers per pipe, but fails to account for one of the scalers already being used by the pipe (i.e., in "panel fitter" mode).

In this case, the second display is driving a YCbCr display which necessitates the use of a pipe scaler even in cases where the resolution does not change:

<7> [152.668726] [drm:skl_update_scaler [i915]] scaler_user index 1.31: staged scaling request for 3840x2160->3840x2160 scaler_users = 0x80000000
<7> [154.169675] [drm:intel_dump_pipe_config [i915]] active: yes, output_types: HDMI (0x40), output format: YCBCR4:2:0

Once we try to activate scaling on two planes, our scaler user bitmask for the second display has three bits turned on (highest bit in the mask is the crtc):

<7> [154.115560] [drm:skl_update_scaler [i915]] scaler_user index 0.1: staged scaling request for 500x500->3840x2160 scaler_users = 0x3
<7> [154.115676] [drm:skl_update_scaler [i915]] scaler_user index 1.9: staged scaling request for 400x400->3840x2160 scaler_users = 0x80000300

which ultimately results in the kernel rejecting the atomic transaction as invalid as Swati pointed out:

<7> [154.115816] [drm:intel_atomic_setup_scalers [i915]] Too many scaling requests 3 > 2

This is exactly the behavior we want --- kernel properly rejects userspace requests that it doesn't have the resources to handle.  Real userspace would take the failure into account and try again with a different compositing strategy.  Unfortunately our IGT tests are trying to use insider knowledge of the hardware resources, but failing to account for CRTC scaler usage due to YUV outputs, which leads to a false positive failure.

This should be fixed on the IGT side; there's no impact to end users, only to CI.  Setting priority/exposure to low.
Comment 4 Martin Peres 2019-11-29 19:41:01 UTC
-- 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/513.

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.