Bug 108642 - [CI][SHARDS] igt@kms_properties@connector-properties-atomic - fail - Test assertion failure function max_bpc_prop_test, Failed assertion: ret == 0
Summary: [CI][SHARDS] igt@kms_properties@connector-properties-atomic - fail - Test ass...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: high normal
Assignee: Stanislav Lisovskiy
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-03 15:03 UTC by Martin Peres
Modified: 2018-12-28 08:59 UTC (History)
3 users (show)

See Also:
i915 platform: ALL
i915 features:


Attachments
Patch to allow a full modeset if needed (1.06 KB, patch)
2018-11-28 13:00 UTC, Stanislav Lisovskiy
no flags Details | Splinter Review

Description Martin Peres 2018-11-03 15:03:47 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5080/shard-apl4/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5080/shard-glk9/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5080/shard-skl2/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5080/shard-kbl7/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5080/shard-hsw5/igt@kms_properties@connector-properties-atomic.html
	
Starting subtest: connector-properties-atomic
(kms_properties:5933) CRITICAL: Test assertion failure function max_bpc_prop_test, file ../tests/kms_properties.c:104:
(kms_properties:5933) CRITICAL: Failed assertion: ret == 0
(kms_properties:5933) CRITICAL: Last errno: 22, Invalid argument
(kms_properties:5933) CRITICAL: error: -22 != 0
Subtest connector-properties-atomic failed.
Comment 1 Martin Peres 2018-11-03 15:09:20 UTC
I assigned Radhakrishna directly because the regression was quite likely caused by this patch:

author	Radhakrishna Sripada <radhakrishna.sripada@intel.com>	2018-10-12 11:42:32 -0700
committer	Rodrigo Vivi <rodrigo.vivi@intel.com>	2018-11-02 09:15:58 -0700
commit	47e22ff1a9e0c144611bd063b3e6135f9a269503

drm: Add connector property to limit max bpc

At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.

Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.

V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
    Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
V10,V11: Fix CI issues.
V12: Add the Kernel documentation(Daniel)
V14: Crossreference the function name in the doc(Daniel)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Sunpeng Li <sunpeng.li@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com

Link: https://cgit.freedesktop.org/drm-tip/commit/?id=f1a1217222a24775eaaafbcbd386101dc44f8a81

PS: Thanks for being on fd.o, Radhakrishna!
Comment 2 Martin Peres 2018-11-05 09:23:26 UTC
More machines affected:

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-bdw-5557u/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-bdw-gvtdvm/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-bsw-kefka/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-bxt-j4205/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-byt-clapper/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-cfl-8109u/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-cfl-8700k/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-cfl-guc/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-cfl-s3/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-cnl-u/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-icl-u/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-icl-u2/igt@kms_properties@connector-properties-atomic.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_137/fi-whl-u/igt@kms_properties@connector-properties-atomic.html

Starting subtest: connector-properties-atomic
(kms_properties:1136) CRITICAL: Test assertion failure function max_bpc_prop_test, file ../tests/kms_properties.c:104:
(kms_properties:1136) CRITICAL: Failed assertion: ret == 0
(kms_properties:1136) CRITICAL: Last errno: 22, Invalid argument
(kms_properties:1136) CRITICAL: error: -22 != 0
Subtest connector-properties-atomic failed.
Comment 3 Radhakrishna Sripada 2018-11-15 04:10:10 UTC
Investigating this issue. It is getting tricky because legacy subtest does not fail whereas atomic connector-properties subtest fails
Comment 4 Stanislav Lisovskiy 2018-11-28 12:58:26 UTC
Problem is quite simple in fact. I enabled atomic debugs for recent kernel and found that this code in drm_atomic.c is executed, thus returning EINVAL:

if (!state->allow_modeset) {
	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
		if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
			DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full modeset\n",
						 crtc->base.id, crtc->name);
			return -EINVAL;
		}
	}
}

So it determines that we have to do a full modeset, while we are not allowing it and returns an error.

state->allow_modeset is set to false, because DRM_MODE_ATOMIC_ALLOW_MODESET bit is not set drmModeAtomicCommit call.

Just merely adding this flag fixes the test case:

ret = drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_TEST_ONLY|DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
Comment 5 Stanislav Lisovskiy 2018-11-28 13:00:08 UTC
Created attachment 142643 [details] [review]
Patch to allow a full modeset if needed

Attaching a patch for igt, which fixes the problem.
Comment 6 Jani Saarinen 2018-11-28 13:11:39 UTC
Do you also send it for review?
Comment 7 Stanislav Lisovskiy 2018-11-28 13:12:28 UTC
Yes, I've sent it to igt-dev.
Comment 8 Jani Saarinen 2018-11-28 13:13:53 UTC
Thanks, ref: https://patchwork.freedesktop.org/series/53157/
Comment 9 Jani Saarinen 2018-12-11 12:47:34 UTC
Fix got merged:
author	Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>	2018-11-28 15:03:34 +0200
committer	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>	2018-12-11 10:08:54 +0100
commit	3b52e8a5809a4e860350c59476a456745cd9fee0
tree	4e347a7c2a6d6910ba2d7034d771af641488d78a
parent	4579ac1d445cf39f6de474071b20db790db575bd
Comment 10 Francesco Balestrieri 2018-12-28 08:59:51 UTC
Not seen after the fix, closing.


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.