Troubleshooting hub USB-PD passthrough issues

Framework Laptop 16 Linux
1

Hey all,

I bought a StarTech DKT31CDHPD3 to try living that sweet one-cable life. Everything works great except for USB-PD passthrough.

When I plug the Framework 180W charger into the StarTech hub on kernel 6.7.12 (Debian trixie/sid), the hub delivers power, but not enough to charge the laptop. (Unfortunately, I do not have any other USB-C chargers I could try.) On kernel 6.8.12, it still does not deliver enough power, and the entire OS becomes extremely laggy.

In the kernel log for 6.7.12, when plugging in the hub, I see either ucsi_acpi USBC000:00: unknown error 0 ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5) or ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-70). In the kernel log for 6.8.12, when plugging in the hub, I see ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95).

The error messages and different behaviour between kernel versions make me think this is probably a kernel bug, but I am not sure how (or if it is possible) to get more detailed information about what, specifically, is failing. However, I also notice the BIOS release notes for 3.03 mention fixing UCSI messages on Linux for expansion cards, so I guess this could also be a partially-fixed BIOS issue that still impacts other devices?

Short of trying the absolute latest kernel to see if it is magically fixed, has anyone encountered this with their own hub and figured out a solution? I have had a surprisingly hard time finding any useful information online for troubleshooting USB-PD issues. I did try using both Port 1 and Port 2. For now, I am stuck living only a two-cable life.

Thanks,

2

Afaik the pd negotiation and charging behavior are not part of the kernel but of the embedded controller and the pd controllers themselves. You can theoretically ask the pd to do stuff from the kernel. The error messages may be red herrings here.

3

If you have any bios update available, I’ll do them right now. It’s always better to have an up to date bios.

Yeah I second @Adrian_Joachim on this one, I don’t see how this is a kernel bug, especially for power delivery that should mostly be handled by internal circuitry and with whom the kernel has almost nothing to act on.

Its pretty common to see error messages when plugging in USB adapters but most of them are actually harmless and temporary as the USB adapter starts (1-3 sec delay between when power is first received and everything is operational) it does a bunch of things, like declaring which ports it has etc. For example my ugreen usb dock also has an error in dmesg logs when I plug it in, but it doesn’t really impact anything.

Not having enough power on frameworks 16 is a common issue especially if you run a game or something demanding when charging. I would recommend you to plug the charger into the framework directly. Also, most USB C adapters can’t handle charge speeds over 100W so your laptop might actually receive only 100W of power but not “charge” as it uses more than 100W. And in the real world if you plug your charger into the dock and the dock can do 100W, the dock will receive close to 85W and your laptop will receive only 75-65W (10-20W power used by the dock itself!). Why? Because chargers advertised 100W usually draw 100W from the wall, not counting all losses from AC to DC conversion and other losses, and the level of output also depends on your battery level; if you have 65%+ then the charger will only draw 65W from the wall and that will mean you have 45W after your dock delivered to the laptop so it really can’t charge as it probably uses 30W idle.

So try to plug the framework in directly, not via the dock. Btw, from your vendor’s webpage: “RELIABLE PERFORMANCE: 100W Power Delivery Pass-Through, the adapter reserves 15W of power (85W for laptop charging)”

4

If you have any bios update available, I’ll do them right now. It’s always better to have an up to date bios.

Thanks, the BIOS was updated to 3.03 the day I got the laptop. I only brought it up to mention that UCSI fixes were explicitly mentioned in the 3.03 release notes, and so my confidence in those errors being kernel problems is not super high.

Its pretty common to see error messages when plugging in USB adapters but most of them are actually harmless and temporary

To be clear, these errors only appear when trying to use USB-PD. When the hub is not plugged into the adaptor, the kernel does not report any errors at all.

Not having enough power on frameworks 16 is a common issue especially if you run a game or something demanding when charging.

The laptop was using only 14W of power. Without the dGPU and without any other devices drawing power from the laptop I doubt it will ever use over 85W, but if it does, using the battery as a reserve is just fine.

Because chargers advertised 100W usually draw 100W from the wall, not counting all losses from AC to DC conversion and other losses

This is not correct (at least for any reputable manufacturer). Check the markings on the adaptor and you can verify the output power is the labelled power. On the Framework 180W adaptor, input is 100–240V 2.5A (250W) and output is 36V 5A (180W). In any case, power to the hub is already DC, and power between the laptop and hub is also DC, so AC–DC loss is irrelevant here.

So try to plug the framework in directly, not via the dock.

The whole point of this topic is to stop doing that. :frowning:

If PD negotiation relies exclusively on the EC then I guess I need to open a support ticket with Framework so they can help to investigate why their adaptor and/or laptop are incompatible with this hub, but I suppose I’d like to be able to say more than just “it doesn’t work and depending on the kernel version causes the laptop to lag”.

Thanks again for everyone’s feedback so far!

Edit: Looking at the EC source code on GitHub, it seems like there is no attempt to keep this code in sync with the upstream ChromeOS EC, so is missing almost four years of upstream fixes, including some ? :grimacing: I wouldn’t even know who to talk to about this. In particular I wonder about this change.

5

I don’t doubt they are related to pd, however I doubt they are actually the problem here.

Yeah that’s not how that works. Charger/power supply ratings are on the output side not the input. Cable and dc-dc conversion losses do still happen though.

6

Hi,

Have you maybe also tried a “windows to go” usb stick?
I have found some usb pd problems are common across both windows and Linux so do not appear os related.
On a related note, Has anyone found out which chip the usb CC1/CC2 pins connect to?

7

I have a feeling that this may be related to general PD issues on AMD systems, which are partially described in this thread - FW16 USB PD Battery Issues - #53 by Lukasz_Siudut . The kernel logs I’ve been seeing when connected the 140W capable power bank are consistent with those seen by the op.

TL;DR is that Framework is apparently working in improving compatibility with various PD devices.

2 Likes
8

Yeah OK, that’s problematic. Maybe your usb C dock does not play well with the framework adapter or the adapter you are using. At this point, only a ticket with framework directly can help you I think. Seems you know more than me on this topic so won’t be able to help you on this one.

9

I haven’t, but it does make sense to me now that the firmware is almost certainly the culprit (since, among other things, PD has to be negotiated even when the laptop is turned off). I don’t have a lot of motivation for messing with my daily driver so haven’t checked to see yet what happens from a power-off state/when booted to the BIOS.

Lagginess only after updating to kernel 6.8 is a little odd, but I have seen issues with USB devices causing system lag pre-boot so it is possible that some kernel change is now triggering that problem too, and it isn’t directly related to USB-PD (or, I suppose, USB bugs in the EC are the cause of both problems).

Yeah, I am getting that sense. It’s been three months since this post, so I am not sure if they think that they fixed PD issues and didn’t, or if “very soon” has a different meaning than I would expect. Unfortunately I don’t have other USB-C systems I can use for comparison. I will send a ticket and see if anything comes of it.

I personally don’t know. Maybe what you are looking for is discoverable from the firmware code? I absolutely don’t have a handle on EC stuff right now; somehow it had not even crystallised for me until today that the Intel models use a totally different EC chip and code branch.

No worries, thank you for trying! :slight_smile: