https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4692/shard-kbl1/igt@kms_chv_cursor_fail@pipe-c-256x256-right-edge.html https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4692/shard-kbl1/igt@kms_flip@basic-flip-vs-modeset.html https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4692/shard-kbl3/igt@kms_flip@plain-flip-interruptible.html <3> [299.574169] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [303.098699] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [306.589383] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [310.095507] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible
Seems like these get triggered after executing: igt@kms_content_protection@*
This is the first time we have the kms_content_protection run on CI effectively. And catching a bug at IGT. As per the HDCP design at kernel if content protection property is left at DESIRED, then on subsequent modesets HDCP authentication will be attempted by kernel on its own. In Our IGT when we set "content protection" to DESIRED and wait for ENABLED state, on error case assert take us out of kms_content_protection, leaving the "content protection" at DESIRED state. To avoid HDCP authentication and related logs in sugsequent tests we need to fix this. And another point is even within kms_content_protection, we dont want dmesg errors incase of failure in authentication. So we need to cleanup all errors the authentication flow by converting them into debug/info logs. Will work on these solutions immediatly. Thanks
*** This bug has been marked as a duplicate of bug 108549 ***
Also seen a lot on SKL: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_135/fi-skl-6770hq/igt@kms_cursor_crc@cursor-64x64-sliding.html <3> [233.896257] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [248.789614] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [263.759868] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible
Possible only if SKL_DISP_PW_1 is not enabled when HDCP is requested. I prefer to wait till danvet's changehttps://patchwork.freedesktop.org/series/51604/ to land first in IGT. So that HDCP is executed at kms_content_protection alone.
https://bugs.freedesktop.org/show_bug.cgi?id=108549 is indeed fixed but this bug keeps happening. Re-opening!
Some examples: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5131/shard-kbl6/igt@kms_content_protection@legacy.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5131/shard-kbl2/igt@kms_content_protection@atomic.html Starting subtest: atomic (kms_content_protection:1369) CRITICAL: Test assertion failure function test_cp_enable_disable, file ../tests/kms_content_protection.c:181: (kms_content_protection:1369) CRITICAL: Failed assertion: ret (kms_content_protection:1369) CRITICAL: Last errno: 25, Inappropriate ioctl for device (kms_content_protection:1369) CRITICAL: Content Protection not enabled Subtest atomic failed. <3> [437.262963] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [461.365150] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible <3> [485.503782] [drm:_intel_hdcp_enable [i915]] *ERROR* HDCP key Load is not possible
Assuming fixed by commit 36dc998c9734a5aaa944a53b591cd50af51e6e55 Author: Imre Deak <imre.deak@intel.com> Date: Mon Nov 5 20:27:39 2018 +0200 drm/i915/gen9_bc: Work around DMC bug zeroing power well requests
(In reply to Imre Deak from comment #8) > Assuming fixed by > > commit 36dc998c9734a5aaa944a53b591cd50af51e6e55 > Author: Imre Deak <imre.deak@intel.com> > Date: Mon Nov 5 20:27:39 2018 +0200 > > drm/i915/gen9_bc: Work around DMC bug zeroing power well requests Looks good! Will wait a little longer, but it looks good!
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.