[RESPONDED][AMD] HP Thunderbolt Dock G2: not detected under Linux (FC39 & Ubuntu23.10 & Arch) but works on Windows11

Peter_Bohner · January 4, 2024, 10:41pm

Hi,
I have a Ryzen 7 AMD Framework 13 running FC39 and an HP Thunderbolt 3 G2 120W Dock.
This dock only works in normal USB mode, not in TB/USB4 mode under Linux.
As such, there is limited functionality (only 1 display works, for example)

On Windows, it only worked after installing the driver package.

On Linux, it is not detected as a thunderbolt device:

-# dmesg | grep thunderbolt
[   20.951668] ACPI: bus type thunderbolt registered
-# boltctl list -a
 ● Framework Laptop 13 (AMD Ryzen 7040Series)
   ├─ type:          host
   ├─ name:          Laptop 13 (AMD Ryzen 7040Series)
   ├─ vendor:        Framework
   ├─ uuid:          b89f3804-a064-86c9-ffff-ffffffffffff
   ├─ generation:    USB4
   ├─ status:        authorized
   │  ├─ domain:     b89f3804-a064-86c9-ffff-ffffffffffff
   │  └─ authflags:  none
   ├─ authorized:    Thu 04 Jan 2024 22:08:45 UTC
   ├─ connected:     Thu 04 Jan 2024 22:08:45 UTC
   └─ stored:        no

 ● Framework Laptop 13 (AMD Ryzen 7040Series)
   ├─ type:          host
   ├─ name:          Laptop 13 (AMD Ryzen 7040Series)
   ├─ vendor:        Framework
   ├─ uuid:          b89f3804-a164-86c9-ffff-ffffffffffff
   ├─ generation:    USB4
   ├─ status:        authorized
   │  ├─ domain:     b89f3804-a164-86c9-ffff-ffffffffffff
   │  └─ authflags:  none
   ├─ authorized:    Thu 04 Jan 2024 22:08:45 UTC
   ├─ connected:     Thu 04 Jan 2024 22:08:45 UTC
   └─ stored:        no

Troubleshooting steps taken:

Updated firmware (to 3.03)
UEFI settings:

disabled secure boot and quick boot
switched between UMA_GAME_OPTIMIZED and the other setting
disable link switching

Different Distros

FC39 live boot
Ubuntu 23.10 live boot
arch linux live image
FC40 rawhide

Compiling and using a vanilla upstream kernel (as of 2024-01-02)
removing amdgpu.sg_display=0 and amd_iommu=off

None of these made a difference. What am I missing?

I am happy to provide more info

dmesg of fedora rawhide (FC39 and Ubuntu looked pretty much the same) (attaching device at 1252.402488 and detaching at 1269.662155)
full logs
excerpt:

[ 1252.402488] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5)
[ 1252.434851] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5)
[ 1252.502831] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5)
[ 1252.617891] ucsi_acpi USBC000:00: possible UCSI driver bug 1
[ 1252.617902] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-22)
[ 1254.303973] usb 8-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ 1254.320002] usb 8-1: New USB device found, idVendor=2109, idProduct=0820, bcdDevice=70.13
[ 1254.320010] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1254.320014] usb 8-1: Product: USB3.1 Hub             
[ 1254.320017] usb 8-1: Manufacturer: VIA Labs, Inc.         
[ 1254.341559] hub 8-1:1.0: USB hub found
[ 1254.341840] hub 8-1:1.0: 4 ports detected
[ 1254.870544] usb 8-1.3: new SuperSpeed USB device number 3 using xhci_hcd
[ 1254.882655] usb 8-1.3: New USB device found, idVendor=0424, idProduct=5807, bcdDevice= 2.04
[ 1254.882663] usb 8-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1254.882667] usb 8-1.3: Product: USB5807 Hub
[ 1254.882669] usb 8-1.3: Manufacturer: Microchip
[ 1254.901341] hub 8-1.3:1.0: USB hub found
[ 1254.901458] hub 8-1.3:1.0: 7 ports detected
[ 1255.011470] hub 8-1.3:1.0: hub_ext_port_status failed (err = -71)
[ 1255.018514] usb 8-1: USB disconnect, device number 2
[ 1255.018524] usb 8-1.3: USB disconnect, device number 3
[ 1255.270178] usb 7-1: new high-speed USB device number 2 using xhci_hcd
[ 1255.404054] usb 7-1: New USB device found, idVendor=2109, idProduct=2820, bcdDevice=70.13
[ 1255.404066] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1255.404072] usb 7-1: Product: USB2.0 Hub             
[ 1255.404076] usb 7-1: Manufacturer: VIA Labs, Inc.         
[ 1255.461446] hub 7-1:1.0: USB hub found
[ 1255.461739] hub 7-1:1.0: 5 ports detected
[ 1256.233641] usb 7-1.3: new high-speed USB device number 3 using xhci_hcd
[ 1256.379023] usb 7-1.3: New USB device found, idVendor=0424, idProduct=2807, bcdDevice= 2.04
[ 1256.379028] usb 7-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1256.379030] usb 7-1.3: Product: USB2807 Hub
[ 1256.379031] usb 7-1.3: Manufacturer: Microchip
[ 1256.420518] hub 7-1.3:1.0: USB hub found
[ 1256.420814] hub 7-1.3:1.0: 7 ports detected
[ 1256.554171] usb 7-1.5: new high-speed USB device number 4 using xhci_hcd
[ 1256.635500] usb 7-1.5: New USB device found, idVendor=2109, idProduct=8888, bcdDevice= 0.01
[ 1256.635505] usb 7-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1256.635507] usb 7-1.5: Product: USB Billboard Device   
[ 1256.635508] usb 7-1.5: Manufacturer: VIA Labs, Inc.         
[ 1256.635509] usb 7-1.5: SerialNumber: 0000000000000001
[ 1256.785173] usb 7-1.3.5: new high-speed USB device number 5 using xhci_hcd
[ 1257.450187] usb 7-1.3.5: New USB device found, idVendor=03f0, idProduct=0269, bcdDevice= 0.17
[ 1257.450199] usb 7-1.3.5: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 1257.450205] usb 7-1.3.5: Product: USB Audio
[ 1257.450209] usb 7-1.3.5: Manufacturer: Generic
[ 1257.450212] usb 7-1.3.5: SerialNumber: 201604140001
[ 1257.540689] usb 8-1: new SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd
[ 1257.546725] input: Generic USB Audio Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1.3/7-1.3.5/7-1.3.5:1.3/0003:03F0:0269.0006/input/input19
[ 1257.555632] usb 8-1: New USB device found, idVendor=2109, idProduct=0820, bcdDevice=70.13
[ 1257.555639] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1257.555642] usb 8-1: Product: USB3.1 Hub             
[ 1257.555644] usb 8-1: Manufacturer: VIA Labs, Inc.         
[ 1257.588946] hub 8-1:1.0: USB hub found
[ 1257.589235] hub 8-1:1.0: 4 ports detected
[ 1257.598377] input: Generic USB Audio as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1.3/7-1.3.5/7-1.3.5:1.3/0003:03F0:0269.0006/input/input20
[ 1257.598788] hid-generic 0003:03F0:0269.0006: input,hiddev97,hidraw5: USB HID v1.11 Device [Generic USB Audio] on usb-0000:c3:00.4-1.3.5/input3
[ 1257.675944] usb 7-1.3.7: new full-speed USB device number 6 using xhci_hcd
[ 1258.129944] usb 8-1.3: new SuperSpeed USB device number 5 using xhci_hcd
[ 1258.141372] usb 8-1.3: New USB device found, idVendor=0424, idProduct=5807, bcdDevice= 2.04
[ 1258.141381] usb 8-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1258.141384] usb 8-1.3: Product: USB5807 Hub
[ 1258.141387] usb 8-1.3: Manufacturer: Microchip
[ 1258.164432] hub 8-1.3:1.0: USB hub found
[ 1258.164479] hub 8-1.3:1.0: 7 ports detected
[ 1259.212233] usb 8-1.3.3: new SuperSpeed USB device number 6 using xhci_hcd
[ 1259.224820] usb 8-1.3.3: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
[ 1259.224831] usb 8-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 1259.224834] usb 8-1.3.3: Product: USB 10/100/1000 LAN
[ 1259.224837] usb 8-1.3.3: Manufacturer: Realtek
[ 1259.224840] usb 8-1.3.3: SerialNumber: 000001000000
[ 1259.290353] usbcore: registered new device driver r8152-cfgselector
[ 1259.460261] r8152-cfgselector 8-1.3.3: reset SuperSpeed USB device number 6 using xhci_hcd
[ 1259.514907] r8152 8-1.3.3:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 1259.538561] r8152 8-1.3.3:1.0 eth0: v1.12.13
[ 1259.538632] usbcore: registered new interface driver r8152
[ 1259.543966] usbcore: registered new interface driver cdc_ether
[ 1259.544983] usbcore: registered new interface driver r8153_ecm
[ 1260.107527] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 1263.196087] usb 7-1.3.7: New USB device found, idVendor=03f0, idProduct=0667, bcdDevice= 1.00
[ 1263.196101] usb 7-1.3.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1263.196107] usb 7-1.3.7: Product: WinUSB
[ 1263.196111] usb 7-1.3.7: Manufacturer: Cypress Semiconductor
[ 1263.196114] usb 7-1.3.7: SerialNumber: 1.0
[ 1263.310679] hid-generic 0003:03F0:0667.0007: hiddev98,hidraw6: USB HID v1.11 Device [Cypress Semiconductor WinUSB] on usb-0000:c3:00.4-1.3.7/input1
[ 1263.987863] usbcore: registered new interface driver snd-usb-audio
[ 1269.662155] usb 7-1: USB disconnect, device number 2
[ 1269.662167] usb 7-1.3: USB disconnect, device number 3
[ 1269.662172] usb 7-1.3.5: USB disconnect, device number 5
[ 1269.700433] usb 8-1: USB disconnect, device number 4
[ 1269.700445] usb 8-1.3: USB disconnect, device number 5
[ 1269.700450] r8152-cfgselector 8-1.3.3: USB disconnect, device number 6
[ 1269.700623] r8152 8-1.3.3:1.0 eth0: Stop submitting intr, status -108
[ 1269.828220] usb 7-1.3.7: USB disconnect, device number 6
[ 1269.892181] usb 7-1.5: USB disconnect, device number 4
[ 1274.955069] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)

Loell_Framework · January 5, 2024, 3:12am

Hi @Peter_Bohner , maybe on more bleeding edge kernel this is already supported? would you be able to check with Fedora Rawhide?

If it’s still not supported even on bleeding edge distros, then it may be a waiting game.

Peter_Bohner · January 5, 2024, 9:52am

Dear @Loell_Framework ,

I’d really appreciate, if support actually read posts in their entirety, not just the first sentence
I have already tried rawhide (with kernel 6.7.0-0.rc8.61.fc40.x86_64) and compiled my own upstream latest 6.7.0-rc8.

That being said, thanks for the quick albeit not very helpful reply.

Regards,
Peter

Alex_S · January 6, 2024, 11:48pm

If I can get one of these from a friend of mine next week, I’ll see if I can do some F39 testing as well. As of the time of this writing I’m on kernel 6.6.8, but there may be updates next week as well.

tim_jordan · January 9, 2024, 5:05pm

Probably not helpful for you, but I had one of these which worked flawlessly for my previous Intel processor Tuxedo infinitybook laptop.
When I received my AMD 13 I tried to use it and it was hit or miss in Windows and rarely worked in Linux.
I ended up buying a Microsoft audio dock to replace it as mine had the conferencing bit on the top and selling the HP one.
That works reliably in Windows and Linux and has been happy sailing ever since.
The only thing I did do with the HP dock was to boot into windows and grab the latest firmware package for the dock and run that ( there was one from mid last year ) and that seemed to make the display work 3 out of 10 times in linux as opposed to 1 out of 10.

jwp · January 9, 2024, 10:51pm

I have several thunderbolt3 docks.

Most of them implement their peripherals as ‘normal old’ usb hubs. The only things that are ‘thunderbolt’ specific are any secondary USB-C TB port (which can be used for Thunderbolt3 networking) and in SOME (but not all) cases the Displayport ports which implement DP Alt mode over USB. I’ve got several which use displaylink over usb for their HDMI outputs.

What functionality specifically are you missing?

Peter_Bohner · January 10, 2024, 6:55pm

the ability to run my 4k display (works under Windows)
I need all the USB bandwidth for my peripherals to work.

Mario_Limonciello · January 10, 2024, 7:18pm

From the description it sounds like the PD controller in the laptop didn’t negotiate TBT3 alt mode quickly enough and so the PD controller in the dock went into USB alt mode instead.

This might be worth trying to debug from the EC debug console to understand it(assuming PD controller emits debug there).

Linux shouldn’t be influencing that though - it should all be happening between PD controllers.

I don’t think it’s likely to change your problem but there is a series going into 6.9 that will change the behavior for tunnels from preboot to OS:

https://lore.kernel.org/linux-usb/cc53d5e2-b9ef-2c48-6c94-0b279f11263f@amd.com/T/#t

It wouldn’t hurt to try it. I think it would only help if the dock was plugged in before OS started though.

Peter_Bohner · January 10, 2024, 7:35pm

Okay, then I’ll check those. once a release candidate exists.

Unfortunately, there is no output (besides the periodic ---) when plugging in/out the device in sudo ./framework_tool --driver portio --console follow

Is there anything more I need/can do to get some debug output?

Peter_Bohner · January 10, 2024, 7:39pm

Then I will likely have to solve this problem, the Captilalism™ way aswell

I get that USB4 is new and finicky, but nonetheless I can’t say I am too thrilled about the firmware/drivers of the AMD Framework laptop (this issue + no XMP + no s3 sleep). Unfortunately, it is too late to exchange it for an Intel version.

Mario_Limonciello · January 10, 2024, 8:00pm

I’ve personally never used the EC console from Linux. I’ve only used it with an external serial interface with it. If you’re able to interact (send commands) to the console, there should be a command for turning up PD debugging output. What you get out of it might not really be helpful to you though too.

@jwp @DHowett, help maybe?

no s3 sleep

What is wrong with s2idle? If you’re having issues you should run scripts/amd_s2idle.py · master · drm / amd · GitLab for your first steps in debugging if you haven’t already.

Peter_Bohner · January 10, 2024, 8:18pm

s2idle is OT here, but: I have had spurious wakeups, which I was not able to diagnose using that script (it always said “power button”), but that is not very important. My problem is the relatively high (1-2%/h) power draw while sleeping, since I frequently left my previous laptop asleep over the weekend, which I can’t really do with this one.
The faster wakeup from sleep is not something I personally benefit from.

Mario_Limonciello · January 10, 2024, 8:26pm

OK. Probably best to set up suspend then hibernate for your use case. If you want to talk more about it open up another issue and tag me.

DHowett · January 10, 2024, 10:08pm

Unfortunately, you can’t get access to the console without an external serial interface.

You are restricted to only the host command binary interface.

However, that’s all moot! The EC is not in charge of PD itself on the existing versions of the Framework Laptop 13, and so it won’t be able to give you much more info than you already have.

Mario_Limonciello · January 10, 2024, 11:18pm

I was hoping that even with EC not being in charge that it has an i2c bus with PD controller that can be used to verify command sequences and negotiation results.

But to really solve this issue I think it probably needs PD traces and to be fixed from PD controller side.

Peter_Bohner · January 27, 2024, 8:56pm

Sadly that patchset did not solve my issue

Still, I’d like to thank you for taking time to respond and trying to help

Peter_Bohner · January 28, 2024, 9:13am

One more thing that I just found out and may be relevant:

When plugging in/out the dock it does start to probe, but finds nothing:

~# boltctl monitor
Bolt Version  : 0.9
Daemon API    : 1
Client API    : 1
Security Level: user
Auth Mode     : enabled
Ready


1706432994033421 Probing started
1706433001040091 Probing done
1706433002975196 Probing started
1706433005978100 Probing done

Mario_Limonciello · January 28, 2024, 1:00pm

That at least jives with this being a PD controller bug. The right mode didn’t negotiate so you got the fallback one when the interrupt fires.

I don’t really understand how that only happens in Linux. That whole negotiation happens without the OS.

Peter_Bohner · January 28, 2024, 1:31pm

Is there any firmware for the PD controller that has to be loaded by the OS?
Maybe there is a difference in the versions shipped by fwupd and the Windows driver bundle (the latter I needed to install before getting the dock working under Windows)?

Mario_Limonciello · January 28, 2024, 2:05pm

Typically the PD controller has its own SPI chip and when you do a BIOS update the BIOS update will flash something to that PD controller.

The only thing I really think that could be different is that the UCSI driver state machine behaved differently with this PD controller than expected.

Linux is (allegedly) spec compliant. We have no idea if Windows is.
If there is a bug with the implementation in Linux against the spec it should be a quirk.

Let me give you an example:
https://lore.kernel.org/linux-usb/20240121204123.275441-1-lk@c--e.de/

You can see in this thread by comparison to the UCSI spec there is definitely something out of spec going on for that hardware. So the proposal is to add a set of code detected by the DMI data for that machine which changes the flow handling.