External USB-C dock displays not detected after unplugging dock (usb autosuspend)

changed the description

changed title from External USB-C dock displays not detected after unplugging dock to External USB-C dock displays not detected after unplugging dock (usb autosuspend)

added Community label

Cc : @ideak @vsyrjala @armurthy @surajk8

Can you try with latest drm-tip. There has been some fixes done lately that would be good to know if helping.

See https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html

I reproduced the issue with drm-tip v6.9-rc3-630-g7be27f645de2 - it did not occur immediately, but did occur on the fourth unplug/replug of the dock.

Do you have logs from last try this as instructed on how-to-file-i915 bugs? @ideak thoughts?

dmesg-drm-tip.txt

Log attached: booted with dock attached, login, laptop screen and one external monitor active, then unplug and replug dock, external monitor not detected on first replug attempt (end of log).

I see the unplug at

[ 163.031280] i915 0000:00:02.0: [drm:spt_irq_handler [i915]] hotplug event received, stat 0x00200000, dig 0x10001012, pins 0x00000020, long 0x00000020

and then no plug event signaled towards the graphics driver. That suggests the root cause is not in the graphics driver.

On Skylake the TypeC to Display Port conversion happens on an off-CPU chip on the motherboard, so not quite sure who's the next to check this; probably someone from USB/TBT team.

@chrisb :

Could you reproduce the problem by booting with drm.debug=0x10e thunderbolt.dyndbg=+p and doing a # echo "plugging/unplugging monitor" > /dev/kmsg before you plug/unplug the monitor?
Do you know if this is a regression and if so what's the working kernel version/any chance for a bisect?
Could you check if the dock/host have firmware/BIOS upgrades available?

New log: dmesg-new
I do not think this is a recent regression. I think that this may have worked by coincidence when the laptop was released back in 2018 - if I boot Ubuntu 18.04 ISO (which uses kernel 4.15.0-20) then the kernel log shows a "failed to suspend" usb4-1 on unplug and the replug does work. But that could just be because the USB bus suspend fails anyway. If I boot Ubuntu 20.04 or 22.04 ISOs then unplug/replug does not work.
Dock and laptop have latest firmware.

I went back to Ubuntu 18.04 and figured out why it worked. The kernel config didn't enable CONFIG_USB4. Disabling CONFIG_USB4 also fixes this issue on recent kernels, so unplugging and replugging the monitors works. I don't know why enabling CONFIG_USB4 affects a USB3.0 dock, as it appears to work fine when CONFIG_USB4 is disabled. lspci only shows the thunderbolt module being used for the "JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]" device. But somehow this seems to break the USB3/DisplayPort plugging.

Yeah, it is probably because when you have CONFIG_USB4 the power management may kick in and that puts the whole Alpine Ridge into low power state which interrupts the redrive more. However, this is not supposed to happen with these Alpine Ridge systems so I wonder if you can re-enable CONFIG_USB4 and boot with no dock connected. Then check lspci output if the Thunderbolt controller is there or not? These systems, most likely it is not there. If it is then this is RTD3 system which, again should not even enter D3 if it is in "redrive" mode but it could be that we are missing something.

Booting without the dock connected, lspci shows that the Thunderbolt controller is present (specifically 07:00.0 System peripheral: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] (rev 02) device and Kernel driver in use: thunderbolt.)

I watched /sys/bus/pci/devices/0000:07:00.0/power_state while plugging and unplugging the dock. The normal transition on unplug is D3hot -> D3cold -> D0. But sometimes it just does D3hot -> D3cold. This is the broken state where re-plugging is no longer detected.

The normal transition on unplug is D3hot -> D3cold -> D0

Actually sometimes the transition sequence after unplug was D3hot -> D3cold -> D0 -> D3hot -> D3cold. In those cases, the replug also worked.

I looked at the power state transitions of the xhci_hcd JHL6340 Thunderbolt 3 USB 3.1 Controller. Without the thunderbolt driver loaded, it just transitions to D3hot on unplug. With the thunderbolt driver loaded, the transitions are odd on unplug, like D3hot -> D3cold -> D0 -> D3hot -> D3cold. The fail condition seems to be that some sequence of transitions that leaves both in D3cold after unplug, but that alone is not sufficient. The exact sequence is:

nih=D3hot bususb4=suspended tbusb=D0
nih=D3hot bususb4=suspended tbusb=D3hot
nih=D3hot bususb4=suspended tbusb=D3cold
nih=D3cold bususb4=suspended tbusb=D3cold

After this, plugging in the dock results in both devices staying in D3cold instead of transitioning to D0.

Right, this is RTD3 system so power management of this is pretty complex but basically when all the devices (PCIe ports, NHI and xHCI) are in D3hot the root port can be turned into D3cold, and it is expected to wake from this if something is plugged in and also it is expected not to enter D3cold if there is anything plugged in to the xHCI ports. The firmware is supposed to keep the NHI up if there is an active DP stream (even in redrive mode).

Have you checked if there is a firmware update for this? Also have you done any BIOS changes from the default that might affect?

From the logs it looks like it is first enumerated as SuperSpeed. Here is the NIC on that dock:

[    2.038436] usb 4-1.4: new SuperSpeed USB device number 4 using xhci_hcd
[    2.060929] usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
[    2.062225] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[    2.063452] usb 4-1.4: Product: USB 10/100/1000 LAN
[    2.064674] usb 4-1.4: Manufacturer: Realtek
[    2.065887] usb 4-1.4: SerialNumber: 000001000000

Then after replug founds itself under the PCH xHCI, High-Speed:

[  209.673161] usb 1-11.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
[  209.673183] usb 1-11.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  209.673194] usb 1-11.4: Product: USB 10/100/1000 LAN
[  209.673202] usb 1-11.4: Manufacturer: Realtek
[  209.673209] usb 1-11.4: SerialNumber: 000001000000

It could be that the "mode" negotiation does not work as expected but this is something Heikki and Mathias are best to comment on.

In this system the USB 3.x (SuperSpeed) type-c pins are handled by xHC at 3d:00.0, while the USB 2.0 (High speed/Low speed/Full Speed) type-c pins are routed to a different PCH xHC at 00:14.0. If nothing wakes up xHC at 3d:00.0 from D3 when dock is reconnected then SuperSpeed device in that dock fail USB 3.0 link training, and eventually fall back to enumerate as USB 2.0 devices behind the other xHC. So even if mode is set up to support USB 3.x (SS) it might still fail USB 3.0 enumeration if 3d:00.0 remains in D3.

The firmware is supposed to keep the NHI up if there is an active DP stream (even in redrive mode).

It goes to D3cold after unplug, presumably this is ok as there won't be active stream at that point. Also, I did just reproduce this twice with the external displays physically connected but not active (as in, no image being displayed), if that makes a difference.

Have you checked if there is a firmware update for this? Also have you done any BIOS changes from the default that might affect?

There are no BIOS updates. Just to be sure it wasn't some config I changed, I reset the BIOS to default configuration and still reproduced the issue.

Do you have another Type-C USB 3.x device such as memory stick or so? If yes, does it wake up when you do:

Boot without anything connected.
Once booted up, wait for additional ~15-20s for the whole Alpine Ridge to enter D3cold.
Plug in the Type-C memory stick.

Also does it enumerate as USB 3.x device or USB 2.x?

I tried an external nvme drive, booting plugged in then unplugging and plugging 20 times, but couldn't reproduce the issue. The drive connected as USB3 SuperSpeed each time.

I also tried a USB-C to DP adaptor with a DP MST hub, plugging and unplugging 20 times, and couldn't reproduce the issue. There were many warnings/errors though, like

[ 1717.797638] pcieport 0000:00:1d.4: PME: Spurious native interrupt!
[ 1717.923747] pcieport 0000:00:1d.4: PME: Spurious native interrupt!
[ 1718.438694] nouveau 0000:01:00.0: Enabling HDA controller
[ 1727.146742] usb usb4-port1: attempt power cycle
[ 1839.621317] nouveau 0000:01:00.0: Enabling HDA controller
[ 1840.645983] xhci_hcd 0000:3d:00.0: xHC error in resume, USBSTS 0x401, Reinit
[ 1840.645995] usb usb3: root hub lost power or was reset
[ 1840.646000] usb usb4: root hub lost power or was reset
[ 1845.980913] workqueue: delayed_fput hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND
[ 1857.217095] nouveau 0000:01:00.0: Enabling HDA controller
[ 1891.252378] workqueue: pm_runtime_work hogged CPU for >10000us 67 times, consider switching to WQ_UNBOUND

With the USB-C DP adaptor and MST hub plugged in, the NHI and USB go to D3cold while the DP outputs are active and displaying the desktop. This is contrary to what you wrote about the firmware keeping the NHI up, and it does not happen with the HP USB-C dock. However, replugging still works in this case. Maybe the condition that triggers the fault requires both USB3 devices and DisplayPort to be present, like in the dock, so lone USB3 devices or MST hubs wouldn't be problematic. It's hard to say for sure when the problem is intermittent.

It could be that when you plug in USB-C DP adapter it is not in redrive mode, instead the internal DP source is muxed directly out from that port. In this case the firmware does not need to keep the controller powered.

added feature: display/DP feature: display/USB-C platform: SKL labels

Adding @westeri.

After talking with Mathias and Heikki from USB/TypeC side, this looks like an issue where not even the USB super-speed devices get enumerated after re-plug. They promised to take a look at this and suggest a way to further narrow down the root case. (One thing would be to reproduce the problem w/o the monitors connected to the hub and see if that way the super-speed USB peripherals are usable on the dock after re-plug and provide a dmesg log for that sequence.)

@chrisb , could you also try disabling the Nvidia graphics card from BIOS setup?

(One thing would be to reproduce the problem w/o the monitors connected to the hub and see if that way the super-speed USB peripherals are usable on the dock after re-plug and provide a dmesg log for that sequence.)

I do not think this is possible - the problem only occurs if one or more external monitors are active on unplug, and two or more external monitors are physically connected on replug.

could you also try disabling the Nvidia graphics card from BIOS setup?

The BIOS does not have an option to disable the discrete card, so I tried booting with module_blacklist=nouveau and confirmed that the nvidia module was not loaded. The dock unplug/replug still failed.

@chrisb , could you please attach the output of acpidump?

acpidump.txt

Thanks.

Could you check the following both in the working case and after the problem is reproduced (needs CONFIG_TYPEC enabled at least, but distros should have this):

# grep . /sys/bus/typec/devices/*/active
        /sys/bus/typec/devices/port0-partner.0/active:yes
        /sys/bus/typec/devices/port0-partner.1/active:no
        ...

Then for the active portX-partner.Y:

# cat /sys/bus/typec/devices/port0-partner.0/svid
        8087

/sys/bus/typec/devices is empty. The typec kernel module is loaded. I checked with the Ubuntu 22.04.4 6.5.0 kernel and my own kernel build. dmesg does not contain any output from the typec module.

(Just to be sure, I plugged the same dock into an AMD laptop, and there /sys/bus/typec/devices/port0-partner.0 is present and dmesg contains typec port0: bound usb1-port2 (ops connector_ops), so I do not think this is a problem with my testing).

The typec module isn't automatically loaded on boot, presumably this means the kernel isn't detecting a typec controller?

@chrisb , ok thanks for the info. Not sure why the sysfs entries are not available, I'm only conveying the clues I get from Heikki in the USB team. It's possible that your platform doesn't support UCSI at all which would be needed for this.

Could you still check if the

CONFIG_TYPEC  
CONFIG_TYPEC_UCSI  
CONFIG_UCSI_ACPI  
CONFIG_TYPEC_DP_ALTMODE

options are enabled in your (local built or distro) kernel config and if not yet enabled recheck the above sysfs entries after enabling them?

Also with the options enabled could you provide the output of

# cat /sys/bus/acpi/devices/USBC000\:00/status  
# ls -R /sys/class/typec

Those config options are enabled (modules). The modules aren't loaded automatically so I would guess it isn't supported by the hardware. I booted the Ubuntu kernel and tried manual modprobe ucsi_acpi typec_displayport, lsmod shows loaded all modules loaded (ucsi_acpi, typec_ucsi, typec_displayport, typec) but still nothing in /sys/bus/typec/devices.

root@blade:/# cat /sys/bus/acpi/devices/USBC000\:00/status  
0
root@blade:/# ls -R /sys/class/typec  
/sys/class/typec:
(empty dir)

External USB-C dock displays not detected after unplugging dock (usb autosuspend)

Child items ...

Activity

Admin message

External USB-C dock displays not detected after unplugging dock (usb autosuspend)

Activity