Starting subtest: hdmi-edid-change-during-suspend [cmd] rtcwake: wakeup from "mem" using /dev/rtc0 at Tue Apr 9 11:12:04 2019 Test requirement not met in function test_suspend_resume_edid_change, file ../tests/kms_chamelium.c:411: Test requirement: !(!link_status_failed[0][p] && link_status_failed[1][p]) Subtest hdmi-edid-change-during-suspend: SKIP (9.276s)
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: igt@kms_chamelium@hdmi-edid-change-during-suspend - skip - Test requirement: !(!link_status_failed[0][p] && link_status_failed[1][p]), SKIP - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5891/re-icl-u/igt@kms_chamelium@hdmi-edid-change-during-suspend.html
re-icl-u is a new configuration in our CI that has Chamelium connected to DP, so this is why this failure is new. The test hdmi-edid-change-during-suspend test the following: 1. changes the EDID on the connector 2. flushes hotplug events 3. puts machine to sleep 4. wakes it up 5. waits for hotplug events 6. goes through **all** connectors checking its link-status and skip if on any of them it was GOOD before suspend and BAD after. This is why we skip on HDMI tests because of DP. The reason for the skip is well explained in the commit introducing it (by Paul Kocialkowski): > It may occur that a hotplug uevent is detected at resume, even though it > does not indicate that an actual hotplug happened. This is the case when > link training fails on any other connector. > > There is currently no way to distinguish what connector caused a hotplug > uevent, nor what the reason for that uevent really is. This makes it > impossible to find out whether the test actually passed or not. > > To circumvent this problem, the link status of each connector is > collected before and after suspend and compared to skip the test if > the state was good before and turned to bad after resume. > > This only concerns the EDID change test, where we cannot check the > connector state (that is not supposed to have changed). For actual > hotplug tests, the tests should be safe since they check each > connector's state after receiving the uevent. > > The situation described here happens with DP-VGA bridges that fail link > training after resume, as they need some more time to response on their > AUX channel. In the dmesg, right after resume we can spot: <3> [710.790487] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training Which explains the link-status being BAD when we wake up. So it's a link training issue.
*** This bug has been marked as a duplicate of bug 110390 ***
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.