Confirming on Ryzen 7 7840U, running Bluefin (based on Fedora 42) with kernel 6.14.4-300.fc42.x86_64. This consistently happens on boot, I have a USB-C connected display with PD on back left port, a Launch 76 Keyboard on front left port, an sd card on front right, and nothing in back right.
I have noticed lockups during boot when I see these messages, I unplug my Launch Keyboard and they go away, plug it back in the messages spin up again. I’ve tried multiple cables, and keyboard appears fine on other computers just not the Framework.
System firmware was at 0.0.3.5, I noticed an update (0.0.3.7) just now and will give it a go…
**Update: After updating to 0.0.3.7 I’m not seeing the kernel messages, but I’m still seeing the lock up when the Launch keyboard is connected to the front left and back right ports. The cable doesn’t appear to be the issue. I unplug the keyboard and it continues booting. Could this be a power draw issue?
I’m seeing this issue on the new AMD Ryzen AI 9 HX 370 board in a FW13.
System Information:
- Model: Framework Laptop 13 (AMD Ryzen AI 300 Series)
- CPU: AMD Ryzen AI 9 HX 370 w/ Radeon 890M
- BIOS Version: 03.03 (Release Date: 03/10/2025)
- OS: Manjaro Linux
- Kernel: 6.12.25-1-MANJARO
Firmware Versions:
- System Firmware: v771
- CPU Microcode: 0x0b20401b
- AMD GPU Firmware: STRIX_B0_GENERIC v1
- SMU Firmware: 93.4.0
UCSI Error Pattern:
The system is showing repeated UCSI errors even with ucsi.disable=1 in kernel parameters:
1. "unknown error 256" followed by "GET_CABLE_PROPERTY failed (-5)"
2. "unknown error 0" followed by "UCSI_GET_PDOS failed (-5)"
3. "failed to register partner alt modes (-5)" for both con1 and con3
Just my 2c, because support is asking me about ucsi_acpi errors for the battery flipping thread. This has been happening for me for months. I don’t recall exactly when it started but it’s been months for sure. Definitely since 6.12. I am running a Ryzen 7040 series FW 13, Arch Linux on 6.14.7. I was on BIOS 3.05, and it’s still happening on BIOS 3.09.
Seems to be the same errors as this post. I also don’t notice anything overtly wrong with the functionality of any of my ports.
Yes, it is still happening and has been at least since early to mid 2024. I’m on a FW13 Ryzen 7840 as well running Tumbleweed with 6.14 kernel and 3.09 firmware. Seems like a kernel issue but no one has sorted it out and has been some time now.
I’m poking around in the kernel source code a bit.
This is where the GET_CABLE_PROPERTY failed error is generated.
I added some debug lines to see if maybe it was failing once and then retrying and succeeding, but it seems it just tries ucsi_register_cable() once and then gives up. I would guess the whole init process is a one-shot thing.
Interestingly, this ucsi_register_cable() is called by ucsi_check_cablehere that deals with cable identity and alt modes. One thing I see mentioned is PD (something that Framework struggles with), so that could be why they’re finally asking me about this in my support ticket in that thread.
I’d like to understand more about this interface and what it accomplishes.
I found this slide deck that gives me the gist online.
What would be nice is if I could find out what in the framework 13 ucsi_run_command() was communicating with. I guess it’s something like CPU → ??? → USB-C Device plugged in.
But this is happening on every FW laptop AFAIK so if it was something on this schematic at fault it would have to be common among all models. The USB-C data path seems to differ between models though, so probably not that.
God forbid the EC is involved. If it is, I will need @\James3 's help.
If it’s something in the BIOS, we’re all cooked.
But the fact that it’s so common probably means a kernel bug.
I might do some more exploring of the code path in the kernel tonight if I feel like it. I would be curious to know if Windows/BSD users experience a similar problem.
Certainly has been a primary suspect I can say I do not remember seeing these from Day 1 as one post mentioned. If memory serves correct it was around the time of kernel 6.9 when the USB-C capability detection features were introduced and could be encountering issues (misinterpretations of responses, missing handling instructions) with the existing Framework firmware.
One user here mentioned reverting to kernel 6.6 LTS and the problem magically went away, so does seem to support something along these lines.
Yeah, I don’t think this problem was introduced with Kernel 6.9, I think it was exposed. I traced through the kernel source code, and I don’t think it’s the kernel’s fault. It’s getting bad responses from whatever is on the other end.
I think Adrian might be onto something about the PD controller. All Framework boards seem to use CYPD8225, CYPD6227, or CYPD6228.
From the datasheet, I can see that this thing has flash. I would be very interested to know what is on that flash chip.
I should be hearing back from support any day now, and hopefully they can provide more information about this situation. I have been having chronic issues with external displays and I can’t help but wonder if this nonsense is related.
There is definitely some special sauce on the pd controllers since the power architecture of the framework with 4 pd inputs (2 controllers) and smart power muxes is not the 1 or 2 input single controller with just simple mosfets as power mux the datasheet asumes.
The overly agressive ocp issue and the 5v charging issue are both also likely in that firmware, but the ec part also seems a bit half baked judging by the ammount of “todos” left in the code (and how well it generally works XD).
This is kind of the downside of doing cool stuff like having more than 2 pd inputs or being the first to do 240w pd, you start coloring outside the lines of off the shelve stuff and start to have to do stuff in non standard ways, combine that with very lean resources (dell and lenovo also do very non standard stuff but I assume they can just throw a couple dozen engineers at the problem and hit it with a rock till it works pretty well, framework seems to just have a few doing everything plus a lot of external suppliers and only hit it with a rock till it works at all) and you get the mess we currently got.
The pd controller handles alt mode switching so it is quite probable. Problems can always be on multiple levels at the same time though.
Can you reproduce display issues on 6.15? There were some compatibility patches added for some displays that are really slow in their response to aux requests.
Our Engineering team has officially filed a ticket to see about getting this issue resolved. What that means is that they are using our production line to test your issue to find the best resolution. We will continue to keep an eye on this issue for you and provide future updates when we have them.
Hi All,
i just received my fw 13 AI Ryzen 9 370, on kernel 6.14 on fedora 42 and i’m actually facing the same issues with my external monitor plugged in usb-c with power delivery.
The laptop don’t charge and don’t recognize my monitor when plugged in usb-c (it works on hdmi).
dmesg is printing this error :
I can say I do not remember seeing these from Day 1 as one post mentioned. If memory serves correct it was around the time of kernel 6.9 when the USB-C capability detection features were introduced and could be encountering issues (misinterpretations of responses, missing handling instructions) with the existing Framework firmware.