[TRACKING] USB C Error on boot

Hi @Daniel_Schaefer would you mind explain more here?

1 Like

We have PD controllers, one for each side (two ports each).
The PD controller firmware handles most of the PD negotiation only communicating with the EC about events it needs to know.

Most Chromebooks have the logic implemented in the EC firmware, where it talks to TCPCs (Type-C Port Controllers). The EC is responsible for the protocol and higher level logic, TCPC just for sending the data out.

The error messages here are from the UCSI subsystem in the OS that it can use through ACPI (BIOS) to talk to the ā€œPD subsystemā€. In our case it’s mostly passed through from the EC to the PD and then back to the OS. And it’s mostly about informing the OS about Type-C cable, device and port information to display helpful messages, like when you are using a cable or port that does not support display output.
Windows and ChromeOS have a lot of those popups, GNU/Linux does not, as far as I know.
But you can get at that information in sysfs, for example /sys/class/usb_power_delivery

3 Likes

Two interesting data points. I remember following this thread a long time ago because I was seeing this exact issue on Arch. I’m now running NixOS and seeing slightly different output in dmesg:

āÆ sudo dmesg | grep ucsi

āÆ sudo dmesg | grep acpi
[    0.024880] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.024881] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.024881] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.024882] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.024882] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.024882] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.024883] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.024883] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.024884] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[    0.024884] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[    0.024884] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[    0.024885] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[    0.024885] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[    0.024885] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[    0.024886] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[    0.024886] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[    0.024886] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[    0.024887] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[    0.024887] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[    0.024887] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[    0.024888] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[    0.024888] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[    0.024889] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[    0.024889] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.111175] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.725274] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    0.729026] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability LTR]
[    1.438661] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    1.492444] hpet_acpi_add: no address or irqs in _CRS

āÆ sudo dmesg | grep cros
[    0.095653] Timer migration: 2 hierarchy levels; 8 children per group; 2 crossnode level
[   14.725956] Adding 16760828k swap on /dev/mapper/swap.  Priority:-2 extents:1 across:16760828k SS
[   14.970170] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000006
[   14.970264] cros_ec_lpcs cros_ec_lpcs.0: got AML mutex 'ECMT'
[   14.978169] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
[   14.993685] cros-charge-control cros-charge-control.5.auto: Framework charge control detected, preventing load
[   15.025997] cros-usbpd-charger cros-usbpd-charger.6.auto: No USB PD charging ports found
[   15.038764] cros-usbpd-charger cros-usbpd-charger.6.auto: Unexpected number of charge port count
[   15.038768] cros-usbpd-charger cros-usbpd-charger.6.auto: Failing probe (err:0xffffffb9)
[   15.038770] cros-usbpd-charger cros-usbpd-charger.6.auto: probe with driver cros-usbpd-charger failed with error -71
[   96.531358] cros-ec-dev cros-ec-dev.1.auto: Some logs may have been dropped...

This isn’t showing up on the boot screen, I’ve got everything muted there in this setup so I’m not sure if it would or not normally right now.

In both cases, I don’t recall having any issues with USB devices though, it was only when i booted while plugged into wall power that i saw the messages and they seemed harmless but confusing like you said.

Oh, I thought maybe it might be a difference in something NixOS was doing, but it may just be a change in a recent kernel then. I’m running nixos-unstable (26.05) with kernel 6.18.4 for comparison with this person who was seeing the same error message.

Yep this is exactly what I mean. The cros-usbpd-charger gets loaded because we have the same EC firmware base as Chromebooks but a totally different PD subsystem, so that driver doesn’t find anything and ends up exiting immediately.

1 Like

@Daniel_Schaefer, perhaps, someone could send a patch to the kernel to make that check redundant? Or, is it checking, then exiting, already as efficient as it can be, so the error is solely an expected consequence of very verbose logging?

1 Like

I am experiencing an issue related to PD and I am seeing this error message, but I do not know if the two are related. When plugging in my AMD 13 7040 laptop into my Lenovo Universal Thunderbolt 4 Dock (40B00135US), there is a 10%-20% chance that it won’t start charging. All the peripherals work (along with displayport for the monitor) but the LED on the framework laptop never turns on and the laptop doesn’t charge. All of my other devices always charge when plugged into that dock. Unplugging and plugging the cable back in will usually get it to start charging.

Framework firmware 3.17

Lenovo dock firmware V1.0.18 (latest)

Using port 1 (from this diagram)

I have a Similar Error on Fedora 43 on AMD 7640U, BIOS Version 0.3.17 and 0.3.16, When connecting my Gigabyte M32QC via USB-C. What is weird about it, it worked fine just a few weeks ago. I tried with multiple Kernels, including 6.18.x, 6.12.x, 6.6.x.

I started having errors this week. Ubuntu 25.10, 6.17.0-8-generic, Intel(R) Coreā„¢ Ultra 7 165H, firmware 0.0.3.6 (latest available through fwupd). Thunderbolt 3 dock is not connecting, but is instead stuck in a loop trying to connect. journalctl dumps out an error in the driver:

[Mon Jan 19 09:15:19 2026] ucsi_acpi USBC000:00: unknown error 0
[Mon Jan 19 09:15:19 2026] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)

[... lots more ] 

And then does that again and again every ~2s.

The dock works fine with another vendor laptop running ubuntu 24.04 and did work fine before this week.

I have tried multiple USB-C modules in different ports of the laptop.

Not sure if it’s an issue with the driver in the kernel or the framework firmware.

Hi folks,

  • When did the issue first occur? Kernel change or firmware update?
  • If working right before, any new tweaks or kernel parameters? TLP?

On the surface, I suspect kernel regression. Worth getting into a support ticket so we can isolate this better to determine from logs, flows, and patterns where this lands.

I’ve always had these errors show up in dmesg since I purchased this laptop. Across very old kernels to current mainline. Only seen it on Frameworks.

1 Like

I am using my Framework 12 and just installed Ubuntu. Im seeing this issue in my logs but I have yet to test for issues. Unsure if I should be worried

I’m seeing this issue on my Framework DESKTOP on startup. I don’t even have any cards because I use a third party case.

I only have a front USB type C plugged in, the other USB type E (that’s the plugs on the mainboard for anyone who doesn’t know) is unused.

On the rear USB-C ports, I can’t get a screen to work. It did work a few times, but not really in Linux anymore. It’s kinda dumb…