<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][RESUME] igt@kms_chamelium@hdmi-edid-change-during-suspend - skip - Test requirement: !(!link_status_failed[0][p] && link_status_failed[1][p]), SKIP" href="https://bugs.freedesktop.org/show_bug.cgi?id=110386#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][RESUME] igt@kms_chamelium@hdmi-edid-change-during-suspend - skip - Test requirement: !(!link_status_failed[0][p] && link_status_failed[1][p]), SKIP" href="https://bugs.freedesktop.org/show_bug.cgi?id=110386">bug 110386</a> from <a class="email" href="mailto:arkadiusz.hiler@intel.com" title="Arek Hiler <arkadiusz.hiler@intel.com>"> Arek Hiler</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>