DP alt mode displays (most often) fail link training if plugged during cold boot

changed the description

added usbc label

changed the description

This morning I found that if I boot up the laptop without the dock plugged in, then plug in the dock after reaching my login screen, the external display initializes every time. I've updated the description and title of this issue.

changed title from Displays over USB4 dock (most often) fail link training to Displays over USB4 dock (most often) fail link training if plugged during boot

changed title from Displays over USB4 dock (most often) fail link training if plugged during boot to Displays over USB4 dock (most often) fail link training if plugged during cold boot

# CONFIG_USB4 is not set

To start out; you should fix this. Without this set you're going to have other bigger problems.

I am connecting external displays to my System76 Pangolin12, but most of the time the displays fail link training and my system continues to frequently hang for several seconds while retrying until the displays are unplugged. I say "most of the time", because about 1 in every 10 or so cold boots with the dock and displays plugged in, the displays come up just fine with no errors or warnings.

If you have it plugged in over cold boot, do you have display in BIOS? Something that Linux does differently than Windows is that it will (attempt) to re-use the tunnels that were initialized by BIOS.

This has exposed a variety of incompatibilities with BIOS/OS assumptions that don't cause problems in Windows.

To start out; you should fix this. Without this set you're going to have other bigger problems.

Thanks. I didn't realize that the USB4 and Thunderbolt drivers were unified. I've made this change and rebuilt the kernel (same version).

If you have it plugged in over cold boot, do you have display in BIOS?

On this laptop if I cold boot into the BIOS configuration utility with the external displays connected, the only display being output to is the builtin panel.

Thanks. I didn't realize that the USB4 and Thunderbolt drivers were unified. I've made this change and rebuilt the kernel (same version).

JFYI this would have also broken suspend on your laptop.

On this laptop if I cold boot into the BIOS configuration utility with the external displays connected, the only display being output to is the builtin panel.

It's still possible that it initialized the DP tunnels. With that kernel with USB4 enabled can you still reproduce? If so, can you please share dynamic debugging for thunderbolt enabled (IE thunderbolt.dyndbg=+p)? This should show whether the DP tunnel was set up and used or not.

With that kernel with USB4 enabled can you still reproduce? If so, can you please share dynamic debugging for thunderbolt enabled (IE thunderbolt.dyndbg=+p)? This should show whether the DP tunnel was set up and used or not.

Yes I can still reproduce the issue. I enabled CONFIG_DYNAMIC_DEBUG in my kernel and added thunderbolt.dyndbg=+p to the kernel commandline args, but I don't see any meaningful output from the thunderbolt module. I verified that dyndbg is enabled for it:

# grep thunderbolt /proc/dynamic_debug/control
drivers/net/thunderbolt/main.c:310 [thunderbolt_net]start_login =_ "login started\n"
drivers/net/thunderbolt/main.c:326 [thunderbolt_net]stop_login =_ "login stopped\n"
drivers/net/thunderbolt/main.c:385 [thunderbolt_net]tbnet_tear_down =_ "sending logout request %u\n"
drivers/net/thunderbolt/main.c:413 [thunderbolt_net]tbnet_tear_down =_ "network traffic stopped\n"
drivers/net/thunderbolt/main.c:446 [thunderbolt_net]tbnet_handle_packet =_ "remote login request received\n"
drivers/net/thunderbolt/main.c:453 [thunderbolt_net]tbnet_handle_packet =_ "remote login response sent\n"
drivers/net/thunderbolt/main.c:476 [thunderbolt_net]tbnet_handle_packet =_ "remote logout request received\n"
drivers/net/thunderbolt/main.c:479 [thunderbolt_net]tbnet_handle_packet =_ "remote logout response sent\n"
drivers/net/thunderbolt/main.c:638 [thunderbolt_net]tbnet_connected_work =_ "login successful, enabling paths\n"
drivers/net/thunderbolt/main.c:676 [thunderbolt_net]tbnet_connected_work =_ "network traffic started\n"
[...]

Nonetheless here is the dmesg output from this boot. Please let me know if I'm doing something wrong

I don't see any USB4 controllers (PCI class 0x0c0340) in your kernel log. Does this system not enable USB4?

If that's the case this is purely a case of a DP alt mode problem not a USB4 problem.

Ah ha. According to the technical specifications for this laptop, the USB-C port is not Thunderbolt compliant.

Got it, that makes a lot more sense thanks for looking into it.

I'm updating the description and title of this issue to help avoid confusion.

added Dock usb4 labels

removed usb4 label

changed title from Displays over USB4 dock (most often) fail link training if plugged during cold boot to DP alt mode displays (most often) fail link training if plugged during cold boot

changed the description

Can you check if you can still reproduce the cold boot failures with https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next? If you can, please note the hash you used to test.

I was able to reproduce the exact same behavior using c5a7d38c2c7fc525e64fdbdeed400e5794457151. For completeness attached is a dmesg from this boot. dmesg3.log

Thanks for checking that.

Can you turn on logbuflen=50M drm.debug=0x116 and try again? I think we'll need to see the entire sequence it goes through for training to understand what's wrong.

AFAICT your dock does support MST, so this could be related to some bandwidth negotiation problems.

For example https://gitlab.gnome.org/GNOME/mutter/-/issues/3008

There's quite a bit of output with those args, so there were some missed messages. I saved what I could and attached it here. dmesg4.log

Just wanted to bump this issue, as I have almost the exact same issue as OP. I'm on a system76 pangolin (pang14), trying to get two monitors to show up over a USB-C docking station. It does work on rare occasion, but usually fails. Unlike op, plugging in the docking station after boot does not typically make it work. I have tried two docking stations (Anker A8389 https://www.amazon.com/dp/B0CF52HF6D?psc=1&ref=ppx_yo2ov_dt_b_product_details and FALWEDI "15 in 1" (no model number) https://www.amazon.com/dp/B0CMH57CQB?ref=ppx_yo2ov_dt_b_product_details&th=1) both with the same results. I'm running wayland on debian bookworm. With the machine on and dock plugged in, this info shows up in journalctl when I plug one of my monitors into the docking station: (see attached file)

journalctl.txt

dj@sys76:~$ uname -a

Linux sys76 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

I just recently heard about a case that fwupd can cause problems racing with the kernel. If you mask fwupd.service does that help?

I'm afraid I didn't have fwupd installed at the time (but I've been working at this all day, so I have some updates haha). Some googling around shows that people with seemingly similar issues had luck downgrading their firmware to 20230404.2e92a49f (https://bbs.archlinux.org/viewtopic.php?id=286847 and tangentially related?: #2666 (closed)). I did try that, but quite frankly, I have no idea if I did it correctly (I'm a bit of a noob at this kernel/firmware stuff; all the examples I found pertained to arch, and I found no noob-friendly debian alternative, so I just grabbed that firmware from kernel.org, unzipped it and coppied everything to /lib/firmware ... not sure if I was supposed to do something else, but that seemed to have no effect haha). This is probably erroneous information, but other things I tried that didn't work: installing linux-image-amd64 (linux-image-6.6.13+bpo-amd64) from bookworm-backports, and installing prebuilt binaries of the system76 drivers from some random person on the internet lol (https://khumba.net/debian/). I did actually end up installing fwupd, although I unfortunately don't remember what the outcome was with that; ultimately, I did a fresh install of debian (I've only had this machine for about a week, so not much progress was lost by doing a fresh install), and lo an behold, the dock and monitors are working reliably again! That being said, I'm going to continue to install stuff to get my system back to the way it was when this issue started happening. I'll be paying particularly close attention to see what specific change breaks it again. I'll give fwupd another whirl if/when it does break. Some interesting things to note: dmesg does complain about not seeing gc_11_0_1_mes_2.bin, which I see you are already familiar with, Mario: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053856 Additionally, even though things are working for me now, I still see an amdgpu related warning and call trace show up in journalctl when the docking station connectsjournalctl.txt, which I think might be related to https://patchew.org/linux/20230117171239.2714855-1-arnd@kernel.org/ but I'm not really sure. IDK how to interpret that warning message. Furthermore, after the fresh install, the monitors weren't being recognized at first; I think they only started being recognized after I installed xwayland specifically, but I'm not positive about that.

mentioned in issue #3485

DP alt mode displays (most often) fail link training if plugged during cold boot

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Log files (for system lockups / game freezes / crashes)

Designs

Child items ...

Activity

Admin message

Admin message

DP alt mode displays (most often) fail link training if plugged during cold boot

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Log files (for system lockups / game freezes / crashes)

Activity