Bug 111045 - [CI][BAT] fi-icl-u4 USB-C igt@kms_chamelium@.* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
Summary: [CI][BAT] fi-icl-u4 USB-C igt@kms_chamelium@.* - fail - Failed assertion: igt...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
: 111046 111049 111084 111096 111155 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-03 06:51 UTC by Lakshmi
Modified: 2019-08-20 12:49 UTC (History)
7 users (show)

See Also:
i915 platform: ICL
i915 features: display/Other


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshmi 2019-07-03 06:51:26 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5079/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
	
Starting subtest: dp-hpd-fast
(kms_chamelium:2871) CRITICAL: Test assertion failure function test_basic_hotplug, file ../tests/kms_chamelium.c:246:
(kms_chamelium:2871) CRITICAL: Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
Subtest dp-hpd-fast failed.
**** DEBUG ****
(kms_chamelium:2871) igt_chamelium-DEBUG: Resetting the chamelium
(kms_chamelium:2871) DEBUG: Waiting for DP-3 to disconnect...
(kms_chamelium:2871) DEBUG: Reprobing DP-3...
(kms_chamelium:2871) DEBUG: Waiting for DP-4 to disconnect...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) DEBUG: Reprobing DP-4...
(kms_chamelium:2871) igt_debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0'
(kms_chamelium:2871) igt_debugfs-DEBUG: Setting HPD storm threshold to 0
(kms_chamelium:2871) igt_chamelium-DEBUG: Plugging DP-3
(kms_chamelium:2871) CRITICAL: Test assertion failure function test_basic_hotplug, file ../tests/kms_chamelium.c:246:
(kms_chamelium:2871) CRITICAL: Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
(kms_chamelium:2871) igt_core-INFO: Stack trace:
(kms_chamelium:2871) igt_core-INFO:   #0 ../lib/igt_core.c:1514 __igt_fail_assert()
(kms_chamelium:2871) igt_core-INFO:   #1 ../tests/kms_chamelium.c:255 test_basic_hotplug.constprop.40()
(kms_chamelium:2871) igt_core-INFO:   #2 ../tests/kms_chamelium.c:2108 __real_main2069()
(kms_chamelium:2871) igt_core-INFO:   #3 ../tests/kms_chamelium.c:2069 main()
(kms_chamelium:2871) igt_core-INFO:   #4 ../csu/libc-start.c:344 __libc_start_main()
(kms_chamelium:2871) igt_core-INFO:   #5 [_start+0x2a]
****  END  ****
Subtest dp-hpd-fast: FAIL (21.245s)
Comment 1 Lakshmi 2019-07-03 06:52:46 UTC
Is this configuration issue?
Comment 2 CI Bug Log 2019-07-03 06:53:18 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3220/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3220/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5079/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5079/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3221/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3221/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3223/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3223/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3224/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3224/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6396/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6396/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13489/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13489/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13490/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13490/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3222/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3222/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13491/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13492/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13492/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3227/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3227/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6397/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13493/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13493/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6398/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6398/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13494/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13494/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13497/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13497/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13498/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13498/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4533/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4533/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13499/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3228/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3228/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
Comment 3 CI Bug Log 2019-07-03 06:54:07 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(HDMI|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter
Comment 4 CI Bug Log 2019-07-03 06:54:52 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(HDMI|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter
Comment 5 Tomi Sarvela 2019-07-03 07:00:42 UTC
This is a new host, so yes, there might be configuration mismatch. Port names and port IDs match though, so I'd be more inclined to think that the issue is in the USB-C hotplug side: that has never been tested before in our CI with Chamelium.

One USB-C port has USB-C-to-DP dongle, other has USB-C-to-HDMI dongle.

.igtrc:

[Chamelium]
URL=http://192.168.1.227:9992

[Chamelium:DP-3]
ChameliumPortID=1

[Chamelium:DP-4]
ChameliumPortID=3

/sys/kernel/debug/dri/0/i915_display_info:

connector 191: type eDP-1, status: connected
	physical dimensions: 290x170mm
	subpixel order: Unknown
	CEA rev: 0
	DPCD rev: 12
	audio support: no
	fixed mode:
		"3840x2160": 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0xa
...
connector 220: type DP-3, status: connected
	physical dimensions: 1020x570mm
	subpixel order: Unknown
	CEA rev: 3
	DPCD rev: 12
	audio support: yes
	DP branch device present: no
	modes:
		"1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
...
connector 223: type DP-4, status: connected
	physical dimensions: 1020x570mm
	subpixel order: Unknown
	CEA rev: 3
	DPCD rev: 12
	audio support: yes
	DP branch device present: yes
		Type: HDMI
		ID: 176GB0
		HW: 1.0
		SW: 7.38
		Max TMDS clock: 600000 kHz
		Max bpc: 12
	modes:
		"1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
Comment 6 Imre Deak 2019-07-03 10:32:39 UTC
There could be a chamelium config issue wrt. HDMI, since there is no HDMI sinks connected (even the USBC->HDMI dongle will show up as DP), but the HDMI chamelium subtests are not skipped as they should be. 

However probably all the DP kms_chamelium tests will fail expectedly on DP-alt outputs. The exceptions could be kms_chamelium subtests where the subtest properly handles hotplug events: enables/disables the output according to the connect/disconnect hotplug event it receives. That's not the case atm with most of the kms_chamelium subtests.

So we'll have to blacklist at least kms_chamelium@dp-hpd-fast on iclu4 (if it'll keep the DP-alt only config in CI).

Next we'll have to add new kms_chamelium subtests that handle hotplug events properly which could be enabled with DP-alt outputs too.
Comment 7 emersion 2019-07-03 10:34:53 UTC
Hotplug events are intentionally left out of Chamelium tests because some tests trigger HPD storms which make the driver disable HPD.
Comment 8 Imre Deak 2019-07-03 10:42:39 UTC
(In reply to emersion from comment #7)
> Hotplug events are intentionally left out of Chamelium tests because some
> tests trigger HPD storms which make the driver disable HPD.

Not sure what you mean here. Hotplug uevents are handled already by all the tests (those are the events the test is waiting for), the handling just lacks the corresponding output enabling/disabling.
Comment 9 emersion 2019-07-03 10:44:19 UTC
(In reply to Imre Deak from comment #8)
> Not sure what you mean here. Hotplug uevents are handled already by all the
> tests (those are the events the test is waiting for), the handling just
> lacks the corresponding output enabling/disabling.

No, hotplug events aren't handled by kms_chamelium. Instead, the tests poll for the connector to become connected. See wait_for_connector.
Comment 10 emersion 2019-07-03 10:47:27 UTC
Well, depends on the tests I guess. Some tests use igt_hotplug_detected.
Comment 11 Imre Deak 2019-07-03 10:53:14 UTC
(In reply to emersion from comment #9)
> (In reply to Imre Deak from comment #8)
> > Not sure what you mean here. Hotplug uevents are handled already by all the
> > tests (those are the events the test is waiting for), the handling just
> > lacks the corresponding output enabling/disabling.
> 
> No, hotplug events aren't handled by kms_chamelium. Instead, the tests poll
> for the connector to become connected. See wait_for_connector.

Oh, ok. Missed this fact. The solution for DP-alt in case of these tests is anyway (1) black-list them for the DP-alt machines, and then (2) add new tests that do the enabling/disabling when they detected the connector status via polling, or just disable the output for the whole duration of the subtest (and then restore the state to the pre-subtest state).

(In reply to emersion from comment #10)
> Well, depends on the tests I guess. Some tests use igt_hotplug_detected.

Ok, so these will need the same handling as above (1) and optionally (2).
Comment 12 CI Bug Log 2019-07-03 12:28:00 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter
Comment 13 emersion 2019-07-04 14:06:39 UTC
*** Bug 111049 has been marked as a duplicate of this bug. ***
Comment 14 emersion 2019-07-04 14:18:26 UTC
(In reply to Imre Deak from comment #6)
> There could be a chamelium config issue wrt. HDMI, since there is no HDMI
> sinks connected (even the USBC->HDMI dongle will show up as DP), but the
> HDMI chamelium subtests are not skipped as they should be. 

I think the configuration is fine. I routinely run HDMI tests on my DP port with lspcon, and configuring .igtrc to map the DUT DP output to the Chamelium HDMI input works.

> However probably all the DP kms_chamelium tests will fail expectedly on
> DP-alt outputs. 

Can you elaborate? I'm not sure I understand.

> The exceptions could be kms_chamelium subtests where the
> subtest properly handles hotplug events: enables/disables the output
> according to the connect/disconnect hotplug event it receives. That's not
> the case atm with most of the kms_chamelium subtests.

Why is this needed? If a user plugs a USB-C to HDMI dongle, the DRM client should see a hotplug event even if the output hasn't been enabled yet, right?

Some tests currently assert HPD on the Chamelium side and expect a hotplug. Is this supposed not to work with DP-ext?
Comment 15 Imre Deak 2019-07-04 15:14:29 UTC
(In reply to emersion from comment #14)
> (In reply to Imre Deak from comment #6)
> > There could be a chamelium config issue wrt. HDMI, since there is no HDMI
> > sinks connected (even the USBC->HDMI dongle will show up as DP), but the
> > HDMI chamelium subtests are not skipped as they should be. 
> 
> I think the configuration is fine. I routinely run HDMI tests on my DP port
> with lspcon, and configuring .igtrc to map the DUT DP output to the
> Chamelium HDMI input works.

With DP++ connectors that should work (with a DP++->HDMI dongle), but here we're talking about a USB-C connector which does not have HDMI output support. The driver doesn't even register an HDMI output for these connector.

You can connect a USB-C connector to an HDMI input via a TypeC-DP-alt->HDMI dongle, but that is still a DP connector from the driver's and the igt test's POV, and so all the Chamelium HDMI subtests should be skipped - which is what I talked about above.

> 
> > However probably all the DP kms_chamelium tests will fail expectedly on
> > DP-alt outputs. 
> 
> Can you elaborate? I'm not sure I understand.

If unplugging a DP-alt display while there is an active modeset on it, and then replugging the DP-alt display, the HW/FW/driver won't signal the corresponding plug-in hotplug event until the mode is disabled.

> > The exceptions could be kms_chamelium subtests where the
> > subtest properly handles hotplug events: enables/disables the output
> > according to the connect/disconnect hotplug event it receives. That's not
> > the case atm with most of the kms_chamelium subtests.
> 
> Why is this needed? If a user plugs a USB-C to HDMI dongle, the DRM client
> should see a hotplug event even if the output hasn't been enabled yet, right?

The failing tests do this:

- <have the output enabled>
- unplug the display, keeping the output enabled
- wait/poll for the disconnect status -> success
- replug the display, while the output is still enabled
- wait/poll for the connect status -> fail

This sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above. 

> Some tests currently assert HPD on the Chamelium side and expect a hotplug.
> Is this supposed not to work with DP-ext?

If there wouldn't be any mode enabled for the whole duration of the sequence, or the client would enable/disable the mode according to the output's connected/disconnected status, then all the hotplug uevents, polling would work as the test expects.
Comment 16 Imre Deak 2019-07-05 10:47:08 UTC
(In reply to Imre Deak from comment #15)
> (In reply to emersion from comment #14)
> > (In reply to Imre Deak from comment #6)
> > > There could be a chamelium config issue wrt. HDMI, since there is no HDMI
> > > sinks connected (even the USBC->HDMI dongle will show up as DP), but the
> > > HDMI chamelium subtests are not skipped as they should be. 
> > 
> > I think the configuration is fine. I routinely run HDMI tests on my DP port
> > with lspcon, and configuring .igtrc to map the DUT DP output to the
> > Chamelium HDMI input works.
> 
> With DP++ connectors that should work (with a DP++->HDMI dongle), but here
> we're talking about a USB-C connector which does not have HDMI output
> support. The driver doesn't even register an HDMI output for these connector.
> 
> You can connect a USB-C connector to an HDMI input via a TypeC-DP-alt->HDMI
> dongle, but that is still a DP connector from the driver's and the igt
> test's POV, and so all the Chamelium HDMI subtests should be skipped - which
> is what I talked about above.

Ah, now I got how the chamelium HDMI subtests work, they also allow a DP source connected to an HDMI sink. So you are right the HDMI subtests should also be run for DP-alt connectors, but they have the same problem as discussed below about having a mode enabled all the time while toggling HPD.

> 
> > 
> > > However probably all the DP kms_chamelium tests will fail expectedly on
> > > DP-alt outputs. 
> > 
> > Can you elaborate? I'm not sure I understand.
> 
> If unplugging a DP-alt display while there is an active modeset on it, and
> then replugging the DP-alt display, the HW/FW/driver won't signal the
> corresponding plug-in hotplug event until the mode is disabled.
> 
> > > The exceptions could be kms_chamelium subtests where the
> > > subtest properly handles hotplug events: enables/disables the output
> > > according to the connect/disconnect hotplug event it receives. That's not
> > > the case atm with most of the kms_chamelium subtests.
> > 
> > Why is this needed? If a user plugs a USB-C to HDMI dongle, the DRM client
> > should see a hotplug event even if the output hasn't been enabled yet, right?
> 
> The failing tests do this:
> 
> - <have the output enabled>
> - unplug the display, keeping the output enabled
> - wait/poll for the disconnect status -> success
> - replug the display, while the output is still enabled
> - wait/poll for the connect status -> fail
> 
> This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> dongle), as I described above. 
> 
> > Some tests currently assert HPD on the Chamelium side and expect a hotplug.
> > Is this supposed not to work with DP-ext?
> 
> If there wouldn't be any mode enabled for the whole duration of the
> sequence, or the client would enable/disable the mode according to the
> output's connected/disconnected status, then all the hotplug uevents,
> polling would work as the test expects.
Comment 17 Lakshmi 2019-07-08 11:38:40 UTC
@Simon / Imre,
Based on the impact, can you please set the severity/priority of this bug appropriately?
Comment 18 Imre Deak 2019-07-08 14:03:12 UTC
(In reply to Lakshmi from comment #17)
> @Simon / Imre,
> Based on the impact, can you please set the severity/priority of this bug
> appropriately?

For the end-user this doesn't have an impact, since user space is expected to react to hotplug events by enabling/disabling the output accordingly - in which case subsequent hotplug events will be reported as expected by the driver.

As for the kms_chamelium tests, I suggest not running the current ones on iclu4, which has only DP-alt sinks connected.
Comment 19 Lakshmi 2019-07-08 16:33:42 UTC
Thanks Imre, setting the priority to Medium based on the assessment.
Comment 20 CI Bug Log 2019-07-09 07:53:54 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_321/fi-icl-u4/igt@kms_chamelium@dp-edid-change-during-suspend.html
Comment 21 emersion 2019-07-10 07:15:08 UTC
*** Bug 111046 has been marked as a duplicate of this bug. ***
Comment 22 emersion 2019-07-10 07:19:01 UTC
(In reply to Imre Deak from comment #15)
> If unplugging a DP-alt display while there is an active modeset on it, and
> then replugging the DP-alt display, the HW/FW/driver won't signal the
> corresponding plug-in hotplug event until the mode is disabled.

Hmm, I see.

> The failing tests do this:
> 
> - <have the output enabled>
> - unplug the display, keeping the output enabled
> - wait/poll for the disconnect status -> success
> - replug the display, while the output is still enabled
> - wait/poll for the connect status -> fail
> 
> This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> dongle), as I described above. 

Thanks for the explanation!

> If there wouldn't be any mode enabled for the whole duration of the
> sequence, or the client would enable/disable the mode according to the
> output's connected/disconnected status, then all the hotplug uevents,
> polling would work as the test expects.

I'll try to send a patch to do this.
Comment 23 emersion 2019-07-10 07:41:32 UTC
*** Bug 111084 has been marked as a duplicate of this bug. ***
Comment 24 Imre Deak 2019-07-10 10:17:19 UTC
(In reply to emersion from comment #22)
> (In reply to Imre Deak from comment #15)
> > If unplugging a DP-alt display while there is an active modeset on it, and
> > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > corresponding plug-in hotplug event until the mode is disabled.
> 
> Hmm, I see.
> 
> > The failing tests do this:
> > 
> > - <have the output enabled>
> > - unplug the display, keeping the output enabled
> > - wait/poll for the disconnect status -> success
> > - replug the display, while the output is still enabled
> > - wait/poll for the connect status -> fail
> > 
> > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > dongle), as I described above. 
> 
> Thanks for the explanation!
> 
> > If there wouldn't be any mode enabled for the whole duration of the
> > sequence, or the client would enable/disable the mode according to the
> > output's connected/disconnected status, then all the hotplug uevents,
> > polling would work as the test expects.
> 
> I'll try to send a patch to do this.

Ok, thanks a lot for looking into that. Btw, are you planning to add new subtests that work according to the above (instead of modifying the existing ones) and black list somehow the existing ones (at least for now) for DP-alt connectors? That would be ideal, since we should still keep the existing ones as-is to retain the coverage for all that scenarios.

Running the old ones (with reduced timeout) on DP-alt would be still good to check for any kernel breakage with enabled outputs, but atm that slows things down a lot since each subtest incurs a 20sec timeout on DP-alt...
Comment 25 emersion 2019-07-10 11:59:42 UTC
*** Bug 111096 has been marked as a duplicate of this bug. ***
Comment 26 emersion 2019-07-10 12:17:38 UTC
(In reply to Imre Deak from comment #24)
> Ok, thanks a lot for looking into that. Btw, are you planning to add new
> subtests that work according to the above (instead of modifying the existing
> ones) and black list somehow the existing ones (at least for now) for DP-alt
> connectors? That would be ideal, since we should still keep the existing
> ones as-is to retain the coverage for all that scenarios.

Hmm, that's a little bit annoying. What about adding a single test that doesn't disable an output when unplugged, and converting all existing tests to work on DP-alt? IMHO this would make more sense because userspace not disabling an output when unplugged is an edge-case.
Comment 27 Imre Deak 2019-07-10 12:35:59 UTC
(In reply to emersion from comment #26)
> (In reply to Imre Deak from comment #24)
> > Ok, thanks a lot for looking into that. Btw, are you planning to add new
> > subtests that work according to the above (instead of modifying the existing
> > ones) and black list somehow the existing ones (at least for now) for DP-alt
> > connectors? That would be ideal, since we should still keep the existing
> > ones as-is to retain the coverage for all that scenarios.
> 
> Hmm, that's a little bit annoying. What about adding a single test that
> doesn't disable an output when unplugged, and converting all existing tests
> to work on DP-alt? IMHO this would make more sense because userspace not
> disabling an output when unplugged is an edge-case.

Changing existing tests has been considered as bad, since that can introduce new issues into the CI bug-tracking system as regressions, whereas they would be an issue always present, just not tested before.

So I don't feel easy about changing the existing tests, but I suppose you could do it if:
- The change is simple like disabling the output only once before the subtest for the whole duration and not adding more complexity like dynamic enabling/disabling based on the connector state.
- You've discussed about the policy of changing existing tests with the CI folks (your team?) and Ville, Daniel, they're the best to decide about this.
Comment 28 CI Bug Log 2019-07-11 06:48:40 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: reprobe_connector(data, port) == DRM_MODE_CONNECTED
  (No new failures associated)
Comment 29 CI Bug Log 2019-07-11 06:51:00 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished
  (No new failures associated)
Comment 30 emersion 2019-07-11 11:13:50 UTC
(In reply to Imre Deak from comment #27)
> Changing existing tests has been considered as bad, since that can introduce
> new issues into the CI bug-tracking system as regressions, whereas they
> would be an issue always present, just not tested before.

I've just sent an RFC that tries to fix it. We'll see if there are regressions and decide what to do from there.
Comment 31 CI Bug Log 2019-07-16 09:26:39 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_322/fi-icl-u4/igt@kms_chamelium@dp-hpd.html
Comment 32 CI Bug Log 2019-07-16 10:56:04 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_322/fi-icl-u4/igt@kms_chamelium@hdmi-edid-change-during-suspend.html
Comment 33 CI Bug Log 2019-07-19 06:51:51 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_325/fi-icl-u4/igt@kms_chamelium@hdmi-hpd.html
Comment 34 emersion 2019-07-22 13:00:53 UTC
(In reply to Imre Deak from comment #15)
> If unplugging a DP-alt display while there is an active modeset on it, and
> then replugging the DP-alt display, the HW/FW/driver won't signal the
> corresponding plug-in hotplug event until the mode is disabled.

What happens if legacy userspace doesn't react to hotplug events? We need to re-enable the output automatically on hotplug. As of now, legacy userspace won't work on DP-alt.

I'm leaning towards marking this as a kernel bug. If userspace doesn't disable the mode, the kernel should re-enable it on hotplug.
Comment 35 emersion 2019-07-23 10:06:07 UTC
*** Bug 111155 has been marked as a duplicate of this bug. ***
Comment 36 Imre Deak 2019-08-05 13:43:52 UTC
(In reply to emersion from comment #34)
> (In reply to Imre Deak from comment #15)
> > If unplugging a DP-alt display while there is an active modeset on it, and
> > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > corresponding plug-in hotplug event until the mode is disabled.
> 
> What happens if legacy userspace doesn't react to hotplug events? We need to
> re-enable the output automatically on hotplug. As of now, legacy userspace
> won't work on DP-alt.
> 
> I'm leaning towards marking this as a kernel bug. If userspace doesn't
> disable the mode, the kernel should re-enable it on hotplug.

The same is true for anything connected in DP-MST mode too though: you connect an MST display, disconnect, then reconnect it, then the mode won't be re-enabled automatically on the display, unless user space processes the hotplug events. So the requirement for user space to do proper hotplug event processing is not specific to USB-C connectors.

Why do you think we should handle USB-C connectors specially (and have the user space hotplug processing requirement only for DP-MST connectors)? We would need a very good justification listing the actual legacy userspace instances you mentioned (since there hasn't been any actual complaints for these even for MST).
Comment 37 CI Bug Log 2019-08-06 08:45:35 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@hdmi-hpd-storm - fail - Failed assertion: igt_hpd_storm_detected(data-&gt;drm_fd)
  (No new failures associated)
Comment 38 CI Bug Log 2019-08-08 08:52:36 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished +}


  No new failures caught with the new filter
Comment 39 CI Bug Log 2019-08-15 11:04:15 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished +}


  No new failures caught with the new filter
Comment 40 CI Bug Log 2019-08-15 11:08:15 UTC
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter
Comment 41 CI Bug Log 2019-08-19 09:22:57 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-after-suspend - fail -  Failed assertion: wait_for_hotplug(mon, &amp;timeout)
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_346/fi-icl-u4/igt@kms_chamelium@dp-hpd-after-suspend.html
Comment 42 emersion 2019-08-20 12:49:49 UTC
It's still not clear what's the best way to proceed.

From a kernel perspective, the best solution so far would be to do an implicit modeset on hotplug if the pipe is still active. Hotplug-aware userspace will disable the pipe on unplug event so the implicit modeset shouldn't happen. Apparently, there are still some questions about power management that need to be answered.

From an IGT test point-of-view, I think I'd still prefer to have one test for the legacy behavior (skipped on MST and on ICL USB-C), and other tests doing the Right Thing.

WIP patch adding the legacy test: https://patchwork.freedesktop.org/series/65182/


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.