Skip to content

ucsi_acpi USBC000:00: unknown error 0 #3

New issue
New issue
Open
Open
ucsi_acpi USBC000:00: unknown error 0#3
Assignees
JohnAZoidberg
Labels
3.05Laptop 13 - AMD Ryzen 7040Framework Laptop 13 (AMD Ryzen™ 7040 Series)type-cIssues related to type-c

Description

@tlvince
tlvince
opened on Nov 6, 2024

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

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

Activity

  1. DHowett
    added
    Laptop 13 - AMD Ryzen 7040Framework Laptop 13 (AMD Ryzen™ 7040 Series)
    type-cIssues related to type-c
    3.05
    on Nov 21, 2024

  2. aginiewicz commented on Apr 25, 2025

    @aginiewicz
    aginiewicz
    on Apr 25, 2025

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

  3. Abdull commented on May 2, 2025

    @Abdull
    Abdull
    on May 2, 2025

    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:

  4. pcoreyster commented on Sep 20, 2025

    @pcoreyster
    pcoreyster
    on Sep 20, 2025

    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

  5. befrvnk
    added a commit that references this issue on Dec 23, 2025

    fix(framework): blacklist UCSI modules to reduce I/O pressure

    5784817

  6. pjbuterbaugh commented on Jan 21, 2026

    @pjbuterbaugh
    pjbuterbaugh
    on Jan 21, 2026

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

  7. JohnAZoidberg
    self-assigned this
    on Jan 24, 2026

  8. JohnAZoidberg commented on Mar 4, 2026

    @JohnAZoidberg
    JohnAZoidberg
    on Mar 4, 2026
    Member

    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.

  9. vadi2 commented on Apr 4, 2026

    @vadi2
    vadi2
    on Apr 4, 2026

    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.

  10. cmol commented on Apr 10, 2026

    @cmol
    cmol
    on Apr 10, 2026

    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.

  11. pcoreyster commented on Apr 10, 2026

    @pcoreyster
    pcoreyster
    on Apr 10, 2026

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

  12. hyperboly commented on Apr 24, 2026

    @hyperboly
    hyperboly
    on Apr 24, 2026

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

  13. taha-yassine commented on May 30, 2026

    @taha-yassine
    taha-yassine
    on May 30, 2026

    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.

  14. pheiduck commented on May 30, 2026

    @pheiduck
    pheiduck
    on May 30, 2026

    Is this upstreamed?: FrameworkComputer/linux@0012550

  15. Serafean commented on May 31, 2026

    @Serafean
    Serafean
    on May 31, 2026 via email

  16. taha-yassine commented on Jun 1, 2026

    @taha-yassine
    taha-yassine
    on Jun 1, 2026

    Is this upstreamed?: FrameworkComputer/linux@0012550

    FWIW that commit only demotes the dev_err to dev_dbg for one specific case: GET_ALTERNATE_MODES returning UCSI_ERROR_UNDEFINED against a passive cable (recipient SOP'/SOP''). It doesn't touch GET_CABLE_PROPERTY and doesn't change any behavior, so even if it were upstream it wouldn't help with the functional issues some of us are hitting here.

  17. cmol commented on Jun 1, 2026

    @cmol
    cmol
    on Jun 1, 2026

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

    I have had the issue with the Intel ultra 7 165H and the AMD Ryzen AI 9 HX 370 boards.

    It's intermittent for me though. Sometimes the laptop works fine with the dock, other times it fails. A reboot does not solve it consistently. As mentioned, I don't have issues with that dock and other hardware running Linux.

  18. alvorithm commented on Jun 3, 2026

    @alvorithm
    alvorithm
    on Jun 3, 2026

    This is what works for me.

    My setup

    Debian 13 with all backported kernels since April 2026 and up to currently 7.0.9, Wayland / Niri.

    AMD 7840 with 2 external monitors, one 4k via DP-to-USB-C external adapter, the other 6k directly via USB-C.

    Kernel parameter in /etc/kernel/cmdline: amdgpu.dcdebugmask=0x10 (I am not sure this is necessary; happy to hear how it goes for you. What I can say is that no amount of playing with blacklisting or unloading/reloading of kernel modules ucsi_acpi and typec_ucsi seemed to make a difference for me.)

    Port assignment (critical)

    • 6K on port 1 (top left). Unfortunately the PD confusion that underlies the endless problems we are having with the Framework Embedded Controller prevents the monitor from feeding power.
    • 4K on port 4 (bottom right).
    • Power on port 3 (top right). Needed because no PD available via port 1.

    I stress any change here ruins the setup for me (no charging or a display won't be recognized), and I am pretty sure some of my ports do not have the full advertised functionality - e.g. never got the DP adapter to work, some don't charge at all. I forgot the details (probably have a note) and it is traumatic for me to recall them now. Belongs to the EC-gate feeling I have with Framework.

    Power-off/on liturgy to please the EC gods

    • Always start from hibernate / power off with ONLY power attached. In particular, if I attach first the PD monitor I might get the display working, but the laptop won't charge no matter what I connect before or later.
    • Only connect the monitors once the graphical session has started.

    The laptop seems to easily get confused as soon as I take it on battery, I think mostly if there is an intermediary hibernate before returning to the desktop setting. The only think that helps (but it predictably helps!) when it just decides that (usually) the 6k display is not connected, is a prolonged (>30s) poweroff, no cables attached. Powering off the monitor for that time may also help. If a >30s poweroff does not help (rare), I continue the vodoo by a loooong (>30s) press of the power button.

    Conclusion

    I am writing this from memory and I am sure the protocol can be refined further to understand which parts of the vodoo are really necessary. But this has turned my Framework from a useless paperweight into an expensive and capricious rain-dance god. So better to share with you now: despite the frustrating long boots (when combined with 64G wake-from-hibernate and LUKS passwords and thick fingers) since I discovered this after dozens and dozens of hours of testing and forum-reading, I can pretend I don't have to RMA the machine, which I have read is a hurdle-full procedure likely ending in PSTD.

    It's still very frustrating though and I am positively shocked that after years of endless and detailed accounts in forum threads and now here, there is no definite resolution from Framework, either via a firmware update or a kernel patch. Or a recall action, if it needs be.

  19. MozillasJC commented on Jun 14, 2026

    @MozillasJC
    MozillasJC
    on Jun 14, 2026

    Draft comment for #3

    Adding a data point from a Framework Desktop (AMD Ryzen AI Max "Strix Halo", BIOS 03.05, CachyOS, kernel 7.0.11) — and findings suggesting the UCSI errors in this issue are a symptom of a deeper PD-controller firmware problem that can also manifest as a failed display at boot.

    Setup

    • Monitor on bottom rear USB-C (DP alt-mode)
    • VIA Labs USB hub on top rear USB-C (billboard devices 2109:8817, 2109:8822)
    • Both rear USB-C ports share a single UCSI PPM (USBC000:00 — typec port0 = hub, port1 = monitor)

    Symptoms

    1. The kernel-side errors already documented in this issue (unknown error 256, GET_CABLE_PROPERTY failed (-5)) fire on hub hot-plug.
    2. More seriously: intermittent black screen at boot when both devices are connected. The monitor's DP alt-mode is never negotiated; amdgpu initializes with no connected display (Cannot find any crtc or sizes, all DP connectors empty) while Linux otherwise boots normally underneath.

    Evidence this is firmware, not the kernel

    We blacklisted the kernel UCSI stack entirely (ucsi_acpi + typec_ucsi via modprobe.d, verified zero UCSI messages in the journal) and reproduced the boot failure anyway: hub enumerated fine, monitor alt-mode never came up. With the kernel driver completely out of the picture, the race has to be inside the PD controller firmware at power-on — the hub's billboard enumeration appears to race the monitor's DP alt-mode negotiation on the shared PPM, and the monitor sometimes loses.

    USB authorization deferral (udev) can't help either, since device authorization has no effect on PD alt-mode negotiation timing.

    Workarounds found

    • Recovery on a bad boot: unplug/replug the monitor's USB-C cable — forces PD re-negotiation, display comes up, no restart needed.
    • Prevention: move the hub to a USB-A port; with only the monitor on USB-C the failure never occurs.

    Happy to provide full journals from the failed boot if useful. Since the kernel was provably uninvolved, this looks like it needs a BIOS/PD-firmware fix.

  20. pheiduck commented on Jul 9, 2026

    @pheiduck
    pheiduck
    on Jul 9, 2026

    Issue still present on 3.20
    System Information:

    System:
  Host: framework13 Kernel: 7.1.3-1-MANJARO arch: x86_64 bits: 64
  Desktop: Cinnamon v: 6.6.8 Distro: Manjaro Linux
CPU:
  Info: 6-core AMD Ryzen 5 7640U w/ Radeon 760M Graphics [MT MCP] speed (MHz):
    avg: 1116 min/max: 406/4972
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Phoenix1 driver: amdgpu v: kernel
  Device-2: Framework Laptop Webcam Module (2nd Gen) driver: uvcvideo
    type: USB
  Display: x11 server: X.org with: Xwayland v: 24.1.13 driver: gpu: amdgpu
    resolution: 2256x1504~60Hz
  API: OpenGL v: 4.6 vendor: amd mesa v: 26.1.4-arch1.1 renderer: AMD
    Radeon 760M Graphics (radeonsi phoenix ACO DRM 3.64 7.1.3-1-MANJARO)
  Info: Tools: api: eglinfo,glxinfo x11: xprop,xrandr
Drives:
  Local Storage: total: 465.76 GiB used: 24.32 GiB (5.2%)
Info:
  Memory: total: 32 GiB note: est. available: 30.65 GiB used: 3.93 GiB (12.8%)
  Processes: 392 Uptime: 0m Shell: Zsh inxi: 3.3.41

  21. taha-yassine commented on Jul 9, 2026

    @taha-yassine
    taha-yassine
    on Jul 9, 2026

    Issue still present on 3.20
    Post my System Information later.

    I can confirm I'm still experiencing this issue on 3.20 too

  22. daniel-g-carrasco commented on Aug 25, 2026

    @daniel-g-carrasco
    daniel-g-carrasco
    on Aug 25, 2026

    Another data point, with a workaround that may help narrow this down.

    Hardware: Framework Laptop 13 AMD 7040 (7640U), BIOS 03.18, board FRANMDCP05. Dock: StarTech DK31C2DHSPD (USB-C, DisplayPort Alt Mode + MST, not Thunderbolt), on the rear right port. Fedora-based bootc image, kernel 7.2.

    Symptom: plugging the dock in with the system running brings up everything except the display. Mouse, keyboard, hubs, ethernet all enumerate. No DisplayPort connector ever reaches connected, forcing a re-probe of the GPU changes nothing, and the kernel logs nothing except:

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

    Attached at boot, the display works every time.

    What the dock says: its USB Billboard descriptor reports the DisplayPort alternate mode (SVID 0xFF01) as "configuration not attempted" (bmConfigured = 01) in the failing case, and "configuration successful" (bmConfigured = 03) whenever the display works. So from the dock's side the host never even tried to enter the mode. The kernel's typec sysfs exposes no altmode entries for the partner on this machine, which I assume is the same UCSI gap.

    Workaround, reproducible: rebinding the driver makes the negotiation happen on the second try.

    echo USBC000:00 > /sys/bus/platform/drivers/ucsi_acpi/unbind
sleep 2
echo USBC000:00 > /sys/bus/platform/drivers/ucsi_acpi/bind

    Seven out of seven plug-ins on this machine, display up within about seven seconds each time, and the dock's Billboard then reads "successful", also with no monitor attached to it. Cost: everything on the dock drops for about a second. A data role swap on the port was tried first and is refused.

    I have this wired to a udev rule on typec partner add events, gated on the dock's Billboard verdict so it never touches a dock that negotiated fine. Happy to share the script if useful.

    Two things this does not cover, in case they matter for the root cause: the display stays black when the dock is attached during POST on 3.18, which #170 says is fixed from 3.19; and I have not yet tested 3.20 because of the bricking reports in the community thread.

  23. taha-yassine commented on Aug 25, 2026

    @taha-yassine
    taha-yassine
    on Aug 25, 2026

    @JohnAZoidberg sorry for the wild tag but you're the only one from the Framework team that ever replied here, and this issue has been open for more than 2 years now with new reports every now and then and no feedback from you guys. Can we expect the team to look into this any time soon?

  24. alvorithm commented on Aug 31, 2026

    @alvorithm
    alvorithm
    on Aug 31, 2026

    @JohnAZoidberg sorry but not sorry for the tag: can you clarify if Framework is interested at all in solving the EC issues, widely reported here and in other issues, as well as in endless threads in the forum?

    At this point what we need is not zombie issues and self-help groups in the Framework community forum, but a clear statement from you, Framework, that you will invest resources in this, or that you own the disaster that the (seemingly fantastic) 4xUSB-C port choice has ended up being, and have no intention to fix.

    Anything but wasting more of our time here speculating that our Frameworks will be fully functional one day.

  25. alvorithm commented on Sep 3, 2026

    @alvorithm
    alvorithm
    on Sep 3, 2026

    Also, let's stop pretending that this is one more open-source project to which we dedicate unpaid work to help the community and ourselves. This is defective hardware (actually firmware) in a product we paid often upwards of 2000€ for. Meanwhile Framework found better things to do with our money, such as new products, or subsidising the fascist kapo of Omarchy, a clearly disadvantaged individual.

    We are left with worse that a closed issue: a zombie thread to vent our frustration with no perspective of fix whatsoever, and no closure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.05Laptop 13 - AMD Ryzen 7040Framework Laptop 13 (AMD Ryzen™ 7040 Series)type-cIssues related to type-c

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions