ucsi_acpi USBC000:00: unknown error 0

[tlvince]

Device Information

System Model or SKU

Please select one of the following

• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION

03.05

DIY Edition information

• Memory: Crucial CT2K16G56C46S5 32GB DDR5-5600 SODIMM
• Storage: SK hynix Platinum P41 1TB SSD

Port/Peripheral information

1. USB-C expansion card: Framework 60W charger
2. USB-C expansion card (no peripheral)
3. USB-C expansion card (no peripheral)
4. USB-C expansion card (no peripheral)

Standalone Operation

• Yes
• No

Describe the bug

acpi kernel logs on boot:

kernel: ucsi_acpi USBC000:00: unknown error 0
kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
kernel: ucsi_acpi USBC000:00: unknown error 256
kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)

Operating System (please complete the following information):

• OS/Distribution: NixOS
• Version: 24
• Linux Kernel Version: 6.11.6

Additional context

Various other reports of the same across kernel versions/distros: USB C Error on boot

[aginiewicz]

Having same issue with Intel® Core™ Ultra Series 1, kernel 6.14.3.

[Abdull]

I also get this error message (albeit a little different) during bootup on my Linux 13 AMD 7040, BIOS 03.05, Debian 12, (all kernels so far, including current 6.12.22).

May 02 15:33:26 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 15:33:26 foobar kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
May 02 15:33:26 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 15:33:26 foobar kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)

Laptop connected to Samsung M7 UHD monitor via USB-C vor USB-PD power delivery and video. Happens on both Framework 13 AMD USB-PD-capable ports 1 and 3.

Error messages also appear when unplugging and replugging this USB cable.

Sometimes then, charging/power supply via USB port completely stops (no more orange-/white-glowing USB port LED; also Debian 12 no longer reporting that charging is in progress, i.e. laptop is being powered from battery).

Repeateadly unplugging and replugging the USB-C cable while the laptop/Debian 12 desktop is running may eventually bring laptop/monitor to the state where monitor is providing laptop with power (i.e., LED on USB port will turn on with white or orange color).

May 02 16:28:46 foobar acpid[2001]: input device has been disconnected, fd 14
May 02 16:28:55 foobar kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* No EDID read.
May 02 16:28:56 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 16:28:56 foobar kernel: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
May 02 16:29:13 foobar kernel: amdgpu 0000:c1:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
May 02 16:29:14 foobar acpid[2001]: input device has been disconnected, fd 14
May 02 16:29:16 foobar kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* No EDID read.
May 02 16:29:17 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 16:29:17 foobar kernel: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)

May 02 16:29:47 foobar kernel: amdgpu 0000:c1:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
May 02 16:29:48 foobar acpid[2001]: input device has been disconnected, fd 14

May 02 16:30:02 foobar kernel: hub 5-1:1.0: activate --> -19
May 02 16:30:03 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 16:30:03 foobar kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
May 02 16:30:04 foobar kernel: ucsi_acpi USBC000:00: unknown error 0
May 02 16:30:04 foobar kernel: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
May 02 16:30:04 foobar kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* No EDID read.

Framework forum discussions maybe related to this issue:

• USB C Error on boot
• [RESPONDED] Linux kernel errors about cros_usbpd_charger
• Cros-usbpd-charger error -71

[pcoreyster]

During failure: xrandr --query shows only eDP-*; xrandr --output DP-1 --auto → “output DP-1 not found”.

Cross-checks
• Same monitor/cables/docks enumerate instantly on macOS (Apple Silicon) and on Framework Intel 11th/12th-gen.

Can attach on request
• journalctl -k / dmesg around monitor power-on
• xrandr --listproviders (good vs bad)
• /sys/class/typec snapshots (good vs bad)
• EDID blobs from macOS (good path) and Linux
• Exact cable models/lengths and Expansion Card P/Ns

[pjbuterbaugh]

Having the same issue on Framework Laptop 16 (AMD Ryzen™ 7040 Series). NixOS 25.11, kernel 6.18.5, BIOS 4.03.

[JohnAZoidberg]

The UCSI error messages mean that the kernel is unable to figure out the cable properties. Our firmware currently does not pass this information correctly to the kernel.
We have fixed this for some cases but some more cases remain.

This does not impact the functionality - so any functional problems we need to debug separately.

[vadi2]

Seeing a functional impact from this on a Framework Laptop 16 (Ryzen 9 7940HS), Bazzite Linux, kernel 6.17.7, BIOS up to date.

The charger (official Framework 180W) advertises all five PD source capabilities up to 20V/5A (100W) in sysfs, but the laptop only negotiates 5V/3A (15W). Since the laptop requires at least 9V to charge, it ends up discharging on battery despite the charger being plugged in.

The error in the journal is: ucsi_acpi USBC000:00: unknown error 256

Tested on multiple ports (port0, port3), same result on both. The charger's source-capabilities under /sys/class/typec/portX-partner/pd3/source-capabilities show the correct PDOs (5V/3A, 9V/3A, 15V/3A, 20V/5A) but the power supply stays at 5V. Replugging does not fix it.

This seems to contradict the note that the UCSI errors do not impact functionality, unless the PD negotiation failure is a separate issue.

[cmol]

I have a Kensington SD5560T Thunderbolt3 and USB-C Docking Station that I have issues connecting to sporadically with both the Ryzen and the intel board. I opened a bug here that I haven't had time to follow up on: https://bugs.launchpad.net/ubuntu/questing/+source/linux/+bug/2139079

The dock has no issues connecting to other devices across OS'es.

[pcoreyster]

@cmol
As the issue was created with Framework AMD 7040, would you share more on the Intel board inclusion?

As I have 5 different framework models from the 11th/12th gen Intel (3 different models) and AMD mainboards (the 7040 and hx series), I gave my detail as I saw this issue on my own AMD model. In my earlier post I never had any issue on the Intel mainboard, but now you stated such an issue.

Can you share more detail?
Your post made me curious as the Intel boards were certified (I believe) to follow thunderbolt standard — an Intel required for that classification.

I believe the AMD boards have USB3 chipset instead which would not be Thunderbolt certified either. Apple silicon MacBook Pro M1 thru M4 use the Intel chipset for Thunderbolt .

Technically the core ultra series 1 has all 4 ports identical but unless the 11th thru 12 gen mainboards. The chipset is said to be classified as Thunderbolt 4 / USB4.

The AMD mainboard uses usb3/usb4 and the various ports are not identical. On my hx 370 I can have no issue for a whole day but then have issue the next day - same hardware.

[hyperboly]

@vadi2 is there a way to get the 180W charger to charge? Seeing this issue on Framework 16 7840HS, NixOS 6.12.78, latest BIOS. Currently falling back to a 65W charger.

[taha-yassine]

Just wanted to add a data point that this isn't only a cosmetic boot message for everyone. On my FW13 AMD (BIOS 3.18, kernel 7.0.3, NixOS) it actively breaks USB-C device enumeration.

Concrete example: I have a pair of USB-C earphones with a built-in DAC. On one specific port they work most of the time but I sometimes need to unplug and replug a few times before the system sees them. On the other ports they basically never enumerate. Right now they're plugged in and lsusb doesn't show them at all.

What's interesting is that the type-C layer does see something. /sys/class/typec/port1-partner and port2-partner exist with accessory_mode: none, supports_usb_power_delivery: no, usb_power_delivery_revision: 0.0. So the partner gets registered but the USB data path never comes up and xHCI never enumerates. Meanwhile dmesg is full of:

ucsi_acpi USBC000:00: unknown error 0
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)

Reading drivers/usb/typec/ucsi/ucsi.c, the failure in ucsi_register_cable() is fatal and aborts the connection setup, which I think is why the USB side never gets enabled. I tried a local kernel patch that makes the failure non-fatal and falls back to assuming a passive USB-C cable, and that does fix it for me, devices enumerate reliably on every port. But carrying an out-of-tree kernel patch isn't great long term.

I had a quick look at the EC firmware (the fwk-lotus-azalea-19573 branch) and the UCSI handler just tunnels the command straight to the Cypress CCG chip, so the bad response is coming from the CCG firmware blob. The PD version in the 3.19 beta changelog is still 0.0.1C, same as 3.18, so I'm guessing 3.19 won't help here either, but happy to test if useful.

Happy to provide more logs, test builds, etc.