[TRACKING] USB C Error on boot

Framework Laptop 13 Linux
83

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

4 Likes
84

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.

85

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.

86

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
87

@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
88

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)

89

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.

90

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.

1 Like
91

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.

92

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
93

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

94

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ā€¦

95

for me it started a few days after upgrading the firmware to 0.0.3.17. I downgraded the Firmware, put that didnā€™t help, and my Work Laptop (Thinkpad with Windows) and my Steamdeck both work fine with the Monitor over USB-C. also tried Multiple Kernels, but none worked, even older ones

96

I started to get this issue since F41 ā†’ F43 move. Iā€™m currently on 6.18.10-200.fc43.x86_64 and 0.0.3.5. Mostly likely kernel related. Iā€™ve reached out to the team via support ticket, but you did not investigate into kernel, limiting things with some parts replacement. Which ultimately did not helped with this issue. Iā€™ve since tried a workaround with quirks usb-storage.quirks= and I though it helped for a moment, but after some time it did not, and Iā€™m again facing issue with Storage expansion card detection on boot. After re-plug it is detected, though.

For now, Iā€™ll try to workaround this issue with re-plugging port controller on boot. Letā€™s see if its a stable solution.

Code 
cat /usr/local/bin/framework-xhci-reset
#!/usr/bin/env bash
# Framework USB enumeration workaround: reset xHCI if device 32ac:0005 not seen.
# https://community.frame.work/t/tracking-usb-c-error-on-boot/52012
# PCI address from hardware.laptop.xhci_pci (default 0000:c3:00.3 for FW13 AMD).
set -euo pipefail
CTRL="0000:c3:00.3"
if lsusb | grep -q "32ac:0005"; then exit 0; fi
DRV="/sys/bus/pci/drivers/xhci_hcd"
if [ ! -d "$DRV/$CTRL" ]; then exit 0; fi
echo "$CTRL" | tee "$DRV/unbind" >/dev/null
sleep 1
echo "$CTRL" | tee "$DRV/bind" >/dev/null

cat /etc/systemd/system/framework-xhci-reset.service
[Unit]
Description=Framework xHCI reset workaround (USB enumeration)
After=basic.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/framework-xhci-reset
TimeoutStartSec=15

[Install]
WantedBy=multi-user.target
97

Update on my workaround:

  • unit applied successfully, resetting the port
  • unfortunately Storage is still ā€œdisappearingā€ after some time. I have suspicion its related to how standby is handled.

Considering that full port reset does not brings back the device, there is something going on in Storage controller also.

Event logs

With device not detected:

lsusb|grep -i frame
Bus 003 Device 003: ID 32ac:001c Framework Laptop Webcam Module (2nd Gen)

After physically re-plugging the device:

[  123.695026] usb 6-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[  123.707013] usb 6-1: New USB device found, idVendor=32ac, idProduct=0005, bcdDevice= 1.10
[  123.707025] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  123.707026] usb 6-1: Product: 1TB Expansion Card
[  123.707028] usb 6-1: Manufacturer: Framework
[  123.707028] usb 6-1: SerialNumber: xxx
[  123.731558] usbcore: registered new interface driver usb-storage
[  123.738353] scsi host0: uas
[  123.738512] usbcore: registered new interface driver uas
[  123.742193] scsi 0:0:0:0: Direct-Access     FRMW     1TB Card         PMAP PQ: 0 ANSI: 6
[  123.776932] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  123.779382] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[  123.781479] sd 0:0:0:0: [sda] Write Protect is off
[  123.781483] sd 0:0:0:0: [sda] Mode Sense: 5f 00 00 08
[  123.785611] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  123.813692] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[  123.813701] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[  123.859867]  sda: sda1
[  123.860012] sd 0:0:0:0: [sda] Attached SCSI disk
[  124.013009] ucsi_acpi USBC000:00: unknown error 256
98

I had what I thought were lockup, but it turned out that something just didnā€™t open the display manager correctly. Ctrl+alt+fX got me to tty login and one thing got me to the manager.

I donā€™t know the exact layout/setup I had, but I was powered w/FW charger and back ports were usb-c front left hdmi and front right usb a.

I had a small, 3 port USB hub plugged in with my UHK and a couple of adafruit feathers. I havenā€™t tried reproducing.