[CI][BAT] fi-icl-u4 USB-C igt@kms_chamelium@.* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)

added CI feature: display/Other platform: ICL platform: SKL priority::medium severity::normal + 1 deleted label

LAKSHMINARAYANA VUDUM @l4kshmi said:

Is this configuration issue?

CI Bug Log said:

The CI Bug Log issue associated to this bug has been updated.

New filters associated

CI Bug Log said:

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

CI Bug Log said:

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

Tomi Sarvela @tsa said:

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

Imre Deak @ideak said:

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.

Simon Ser @emersion said:

Hotplug events are intentionally left out of Chamelium tests because some tests trigger HPD storms which make the driver disable HPD.

Imre Deak @ideak said:

(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.

Simon Ser @emersion said:

(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.

Simon Ser @emersion said:

Well, depends on the tests I guess. Some tests use igt_hotplug_detected.

Imre Deak @ideak said:

(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).

CI Bug Log said:

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

Simon Ser @emersion closed a related bug:

*** Bug 111049 has been marked as a duplicate of this bug. ***

Simon Ser @emersion said:

(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?

Imre Deak @ideak said:

(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:

- ``
- 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.

Imre Deak @ideak said:

(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:
>
> - ``
> - 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.

LAKSHMINARAYANA VUDUM @l4kshmi said:

@Simon / Imre,
Based on the impact, can you please set the severity/priority of this bug appropriately?

Imre Deak @ideak said:

(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.

LAKSHMINARAYANA VUDUM @l4kshmi said:

Thanks Imre, setting the priority to Medium based on the assessment.

[CI][BAT] fi-icl-u4 USB-C igt@kms_chamelium@.* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)

Submitted by LAKSHMINARAYANA VUDUM `@l4kshmi`

Description

Child items ...

Activity

New filters associated

Admin message

Admin message

[CI][BAT] fi-icl-u4 USB-C igt@kms_chamelium@.* - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)

Submitted by LAKSHMINARAYANA VUDUM @l4kshmi

Description

Activity

New filters associated

Submitted by LAKSHMINARAYANA VUDUM `@l4kshmi`