Bug 110391 - [CI][RESUME] igt@kms_setmode@invalid-clone-single-crtc-stealing - fail - Failed assertion: ret == 0, Last errno: 22, Invalid argument
Summary: [CI][RESUME] igt@kms_setmode@invalid-clone-single-crtc-stealing - fail - Fail...
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Maarten Lankhorst
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-10 15:39 UTC by Martin Peres
Modified: 2019-06-03 16:06 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Peres 2019-04-10 15:39:03 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5891/re-icl-u/igt@kms_setmode@invalid-clone-single-crtc-stealing.html

Starting subtest: invalid-clone-single-crtc-stealing
(kms_setmode:1349) CRITICAL: Test assertion failure function test_stealing, file ../tests/kms_setmode.c:398:
(kms_setmode:1349) CRITICAL: Failed assertion: ret == 0
(kms_setmode:1349) CRITICAL: Last errno: 22, Invalid argument
(kms_setmode:1349) CRITICAL: error: -22 != 0
Comment 1 CI Bug Log 2019-04-10 15:39:17 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@kms_setmode@invalid-clone-single-crtc-stealing - fail - Failed assertion: ret == 0, Last errno: 22, Invalid argument

  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5891/re-icl-u/igt@kms_setmode@invalid-clone-single-crtc-stealing.html
Comment 2 Martin Peres 2019-04-25 07:12:14 UTC
This test has been failing 100% of the time on re-icl-u, and only this one...

This might be explained by the fact that this is the only machine that has a chamelium connected to its mDP port.

The test is supposed to check that one CRTC stealing an already-used encoder is not accepted by atomic. However, in this particular case, the failure happens on the first modeset (the one where we want to try stealing the encoder from).

Here is the relevant failure:

<7> [23.795360] [drm:drm_mode_setcrtc] [CRTC:82:pipe A]
<7> [23.795445] [drm:drm_mode_setcrtc] [CONNECTOR:196:DP-1]
<7> [23.795602] [drm:intel_atomic_check [i915]] [CONNECTOR:196:DP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
<7> [23.795668] [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max rate 270000 max bpp 24 pixel clock 533250KHz
<7> [23.795731] [drm:intel_dp_compute_config [i915]] Force DSC en = 0
<7> [23.795788] [drm:intel_atomic_check [i915]] Encoder config failure: -22
Comment 3 Arek Hiler 2019-04-25 07:17:23 UTC
The failure is likely caused by this function that gets mode to set on all connectors:

static void get_mode_for_crtc(struct crtc_config *crtc,
			      drmModeModeInfo *mode_ret)
{
	drmModeModeInfo mode;
	int i;

	/*
	 * First try to select a default mode that is supported by all
	 * connectors.
	 */
	for (i = 0; i < crtc->connector_count; i++) {
		mode = crtc->cconfs[i].default_mode;
		if (crtc_supports_mode(crtc, &mode))
			goto found;
	}

	/*
	 * Then just fall back to find any that is supported by all
	 * connectors.
	 */
	for (i = 0; i < crtc->cconfs[0].connector->count_modes; i++) {
		mode = crtc->cconfs[0].connector->modes[i];
		if (crtc_supports_mode(crtc, &mode))
			goto found;
	}

	/*
	 * If none is found then just pick the default mode of the first
	 * connector and hope the other connectors can support it by scaling
	 * etc.
	 */
	mode = crtc->cconfs[0].default_mode;
found:
	*mode_ret = mode;
}

eDP quite likely supports 36bpp but DP does not. Because of the wrong assumptions above we try to set this 36bpp mode on the DP connector, failing on the first drmModeSetCrtc().

The test should be fixed by being more clever about mode selection or just skipping if connector happens to not support given mode, instead of asserting straight away.

Dropping priority to medium, as this is a test issue.
Comment 4 Martin Peres 2019-04-25 07:18:10 UTC
This test is pretty generic, so if some machines fail/skip it, it is not lost test coverage. I think you are with the priority!
Comment 6 Maarten Lankhorst 2019-06-03 16:06:01 UTC
commit 6cfbf0365f39d68fcaabcd0498ffec28d1528d8f (HEAD, origin/master, origin/HEAD)
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Apr 25 10:41:02 2019 +0200

    tests/kms_setmode: Handle eDP with fixed mode better.


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.