igt@kms_chamelium@* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT), Timed out waiting for hotplug uevent
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7829/re-tgl-cham/igt@kms_chamelium@dp-hpd-fast.html
Starting subtest: dp-hpd-fast
(kms_chamelium:955) CRITICAL: Test assertion failure function test_basic_hotplug, file ../tests/kms_chamelium.c:264:
(kms_chamelium:955) CRITICAL: Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
(kms_chamelium:955) CRITICAL: Timed out waiting for hotplug uevent
Subtest dp-hpd-fast failed.
````Activity
added CI feature: display/Other platform: KBL platform: TGL labels
The CI Bug Log issue associated to this bug has been updated.
New filters associated
- CHAMELIUM: igt@kms_chamelium@* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT), Timed out waiting for hotplug uevent
Cc: @ideak
Few findings:
- you don't get the HPD interrupts over DP via USB-C at all, even when manually unplugging and plugging a display - nothing in the dmesg, nothing through udev
- you can poll for them by doing atomic modeset - the hotplug event only arrives after a "shot in the dark" modeset, this can be either done by the test or the fbcon (if it is bound)
[1224242.161575] i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:323:DP-5] [1224242.161661] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0 [1224242.161743] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 1 [1224242.161816] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TBT PLL [1224242.161934] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 1 [1224242.162010] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 2 [1224242.162088] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 3 [1224242.162241] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 4 [1224242.162531] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 5 [1224242.162715] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] TC PLL 6 [1224242.164803] [drm:icl_tc_phy_connect [i915]] Port G/TC#4: PHY not ready [1224242.164873] i915 0000:00:02.0: [drm:__intel_tc_port_lock [i915]] Port G/TC#4: TC port mode reset (dp-alt -> tbt-alt) [1224242.182280] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling power well 3 [1224242.182400] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling power well 2 [1224242.182510] i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:152:pipe B] [1224242.185025] Console: switching to colour frame buffer device 480x135 [1224242.191777] i915 0000:00:02.0: [drm:gen8_de_irq_handler [i915]] hotplug event received, stat 0x00080000, dig 0x0000a888, pins 0x00000400, long 0x00000400 [1224242.191914] [drm:intel_hpd_irq_handler [i915]] digital hpd on [ENCODER:322:DDI G] - long [1224242.192030] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 10 - cnt: 10 [1224242.192192] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:322:DDI G] - longMy guess that the
verify_connector_state()that is being called on the atomic_commit path does something that discovers the device is actually there and only then we get the interrupt.@adrinael has a gut feeling that it may be related to:
drm:__intel_tc_port_lock [i915]] Port G/TC#4: TC port mode reset (dp-alt -> tbt-alt)It's easy to reproduce with:
diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c index 5c4a1892..ba2d3d1f 100644 --- a/tests/kms_chamelium.c +++ b/tests/kms_chamelium.c @@ -518,26 +518,13 @@ prepare_output(data_t *data, struct chamelium_port *port, enum test_edid edid) set_edid(data, port, edid); chamelium_plug(data->chamelium, port); - wait_for_connector(data, port, DRM_MODE_CONNECTED); igt_display_reset(display); output = igt_output_from_connector(display, connector); /* Refresh pipe to update connected status */ - igt_output_set_pipe(output, PIPE_NONE); - - for_each_pipe(display, pipe) { - if (!igt_pipe_connector_valid(pipe, output)) - continue; - - found = true; - break; - } - - igt_assert_f(found, "No pipe found for output %s\n", igt_output_name(output)); - - igt_output_set_pipe(output, pipe); + igt_output_set_pipe(output, PIPE_B); drmModeFreeConnector(connector);Without the patch
dp-crc-singlesubtest fails on waiting for the connector to go up, with the patch applied the modeset goes through and we get the late interrupt.-
dp-crc-single without the patch:
igt_without_patch.txt dmesg_without_patch.txtdp-crc-single with the patch forceing modeset:
igt_with_patch.txt dmesg_with_patch.txt -
here you go: dmesg_full.txt
first execution of the test is with the forced modeset and it succeeds
second one that ends in failure is the one that times out on waiting for the interrupt and then after the test exit you can see fbcon kicking in with its own modest which leads to the interrupt discovery
Thanks, it's a known issue, which we haven't unfortunately addressed earlier (Simon has left):
The following sequence is unsupported on TypeC ports, due to a suboptimal TypeC firmware implementation:
- Enable a mode
- Unplug (interrupt will occur, but we keep the mode enabled).
- Replug while the previous mode is still enabled. Interrupt will not happen until the mode gets disabled.
I have the kernel patches to work around this firmware limit, but at one point we decided that it's not an important enough use case: user space normally will always do a modeset disabling in response to an unplug event (at point 2. above), so the problem will not happen for these regular users.
IGT does the above sequence nevertheless, so imo such tests would need to be skipped on TypeC ports and in tests we want to run on TypeC ports too we would need to do a proper mode set disable in response to an unplug event.
-
Thanks for clarification! I find this a bit surprising.
This is the case even when the previous mode is not utilizing the given connector? So here we are counting here on any modeset after unplug, otherwise no hotplug events?
If this is a known behavior that we commit to it should be easy enough to work around in IGT.
"This is the case even when the previous mode is not utilizing the given connector?"
The issue is present only in the case where the given connector (on which we expect the hotplug) is enabled with a mode.
"So here we are counting here on any modeset after unplug, otherwise no hotplug events?"
Yes. Modeset-disable in response to an unplug event and only re-enable the mode upon a subsequent plug event.
Edited by Imre Deak-
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: CHAMELIUM: igt@kms_chamelium@* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT), Timed out waiting for hotplug uevent
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-kbl-7567u", "fi-cml-u2", "fi-icl-u4", "re-ehl-cham", "fi-icl-u2", "fi-kbl-7500u", "re-icl-u", "fi-skl-6700k2", "re-tgl-cham"] OR machine_tag IS IN ["CHAMELIUM"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@kms_chamelium@hdmi-cmp-nv61", "igt@kms_chamelium@dp-crc-fast", "igt@kms_chamelium@hdmi-aspect-ratio", "igt@kms_chamelium@hdmi-cmp-nv12", "igt@kms_chamelium@hdmi-cmp-nv16", "igt@kms_chamelium@hdmi-cmp-yu12", "igt@kms_chamelium@hdmi-cmp-nv21", "igt@kms_chamelium@hdmi-cmp-yv12", "igt@kms_chamelium@hdmi-cmp-yv16", "igt@kms_chamelium@dp-hpd-after-hibernate", "igt@kms_chamelium@hdmi-hpd", "igt@kms_chamelium@hdmi-hpd-after-suspend", "igt@kms_chamelium@hdmi-hpd-storm-disable", "igt@kms_chamelium@vga-hpd-after-suspend", "igt@kms_chamelium@hdmi-hpd-storm", "igt@kms_chamelium@dp-hpd", "igt@kms_chamelium@vga-hpd-after-hibernate", "igt@kms_chamelium@hdmi-crc-single", "igt@kms_chamelium@dp-hpd-storm-disable", "igt@kms_chamelium@vga-hpd", "igt@kms_chamelium@dp-hpd-after-suspend", "igt@kms_chamelium@vga-hpd-without-ddc", "igt@kms_chamelium@dp-hpd-storm", "igt@kms_chamelium@hdmi-cmp-planes-random", "igt@kms_chamelium@hdmi-crc-planes-random", "igt@kms_chamelium@hdmi-hpd-fast", "igt@kms_chamelium@vga-hpd-fast", "igt@kms_chamelium@dp-edid-change-during-hibernate", "igt@kms_chamelium@hdmi-mode-timings", "igt@kms_chamelium@dp-mode-timings", "igt@kms_chamelium@hdmi-hpd-after-hibernate", "igt@kms_chamelium@hdmi-edid-change-during-hibernate", "igt@kms_chamelium@dp-frame-dump", "igt@kms_chamelium@dp-hpd-fast", "igt@kms_chamelium@vga-frame-dump", "igt@kms_chamelium@hdmi-edid-read", "igt@kms_chamelium@hdmi-crc-rgb888", "igt@kms_chamelium@hdmi-crc-xbgr8888", "igt@kms_chamelium@hdmi-crc-bgr888", "igt@kms_chamelium@hdmi-crc-argb1555", "igt@kms_chamelium@hdmi-crc-rgb565", "igt@kms_chamelium@hdmi-crc-xrgb1555", "igt@kms_chamelium@hdmi-crc-argb8888", "igt@kms_chamelium@hdmi-crc-bgr565", "igt@kms_chamelium@hdmi-crc-abgr8888", "igt@kms_chamelium@hdmi-crc-fast", "igt@kms_chamelium@hdmi-crc-xrgb8888", "igt@kms_chamelium@common-hpd-after-hibernate", "igt@kms_chamelium@hdmi-edid-change-during-suspend", "igt@kms_chamelium@common-hpd-after-suspend", "igt@kms_chamelium@dp-edid-change-during-suspend", "igt@kms_chamelium@dp-edid-read", "igt@kms_chamelium@dp-crc-multiple", "igt@kms_chamelium@hdmi-crc-multiple", "igt@kms_chamelium@vga-edid-read", "igt@kms_chamelium@dp-audio", "igt@kms_chamelium@dp-link-status", "igt@kms_chamelium@hdmi-frame-dump", "igt@kms_chamelium@hdmi-audio", "igt@kms_chamelium@hdmi-audio-edid", "igt@kms_chamelium@dp-audio-edid", "igt@kms_chamelium@dp-crc-single", "igt@kms_chamelium@hdmi-cmp-yu16"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["fail"])) AND stderr ~= 'Failed assertion: igt_hotplug_detected\(mon, HOTPLUG_TIMEOUT\)\n.*imed out waiting for hotplug uevent'
New failures caught by the filter:
marked this issue as a duplicate of #323 (closed)
mentioned in commit lyudess/linux@b4df5405
