EGPU Not Recognized on Framework Desktop (GET_CABLE_PROPERTY failed (-5))

Framework Desktop Linux
1

Which Linux distro are you using?
OS: Kubuntu 26.04 (Resolute Raccoon) x86_64
Issue persists on Arch

Which kernel are you using?
Kernel: Linux 7.0.0-14-generic

Which BIOS version are you using?
BIOS: 03.05 (Released 01/21/2026) (Persists on 03.04)

Which Framework Desktop model are you using?
Model: Ryzen AI Max+ 395 w/ Radeon 8060s (128GB)

Body:
Hello, I hope someone can help me out.
I’m having trouble connecting an AdLink A500 EGPU to my Framework Desktop. I have verified the EGPU, cable, and power brick work by connecting the EGPU to another USB-4 capable device, and it’s recognized immediately without restarts.

On my Framework Desktop, however - the device is not recognized ever, at all. Connecting it causes this error to appear in dmesg

greenbean@greenframework:~$ sudo dmesg | grep -i ucsi | tail -10
[ 582.216998] ucsi_acpi USBC000:00: unknown error 256
[ 582.217011] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[ 582.369435] ucsi_acpi USBC000:00: unknown error 256
[ 582.369447] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
[ 583.383595] ucsi_acpi USBC000:00: unknown error 256
[ 583.383609] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
[ 2104.127782] ucsi_acpi USBC000:00: unknown error 256
[ 2104.127790] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[ 2104.514787] ucsi_acpi USBC000:00: unknown error 256
[ 2104.514795] ucsi_acpi USBC000:00: con1: failed to register partner alt modes (-5)
greenbean@greenframework:~$ sudo dmesg | grep -i ucsi | tail -10

I’ve tried executing PCIe rescan with `sudo sh -c "echo 1 > /sys/bus/pci/rescan"`, rebooting the desktop while the EGPU is connected, disabling ASPM using pcie_aspm=off in /etc/default/grub, and ensured the ucsi_acpi module is loaded.

The GPU does not appear in boltctl list, in lspci | grep -i thunderbolt, or in lspci | grep -i nvidia, and is not recognized in nvtop. I am connecting using the back USB 4 ports, and I have followed the manual of the A500. The above error occurs every time the device is plugged in, with the port matching the one I use.

Attempting to manually set aspm to performance with echo performance > /sys/module/pcie_aspm/parameters/policy returns operation not permitted. I don’t know if that’s significant.

I saw a post mentioning a similar error, but it appeared their post wasn’t directly adjacent to an actual fault occurring and was just mentioning GET_CABLE_PROPERTY failing without a connection - in my case, the failure appears tied to the unrecognized EGPU, which is why I feel it’s unique enough to make a separate post. If I’m incorrect, I apologize.

I am aware that the Radeon 8060s significantly outclasses the EGPU; this EGPU is required for my specific use case, and I’m okay with it being weaker.

Any help would be appreciated, as the functionality of the EGPU is critical to my work. Thank you.

1 Like
2

I would not focus on the GET_CABLE_PROPERTY failed, at least on the fw 13 we also get those when it is working.

3

Ah, I see then. I’m not sure what the issue could be besides that, though; that’s the only output I ever get, and it consistently matches up with when I plug in the device. Do you have any suggestions for commands or logs I can check in order to better get a grip on this problem? If not, that’s okay!

4

The message is part of the plugin event so getting it on plugin is normal, would be nice if they fixed that at some point but it doesn’t seem to interfere with functionality.

dmesg without the grep would be interesting, you can also do dmesg -w to watch what is going on during plugin. But if it doesn’t even show up in boltctl that is not a great sign.

You could try installing windows2go on an usb stick (rufus lets you do that) and see if it works under windows.

1 Like
5

Thanks for your response,

I have performed dmesg -w as you suggested, but the only logs that appear are the ones I already sent:

[   91.889989] ucsi_acpi USBC000:00: unknown error 256
[   91.890008] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[   92.264755] ucsi_acpi USBC000:00: unknown error 256
[   92.264769] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)

Instead of win2go, I have popped in an entire fresh install of Windows 11, and the driver failed to find any nvidia hardware + the A500 did not appear in device manager nor task manager.

To make sure I’m not insane, I plugged the A500 back into the laptop where it’s working, ensuring I’m using the same cable, power brick, etc, and the A500 works fine on that device.

Perhaps I’m miseducated on how USB4 works? I assumed a Thunderbolt 3 device works on USB4, am I mistaken?

6

Hi again,

I downgraded to bios revision .03, and the device is detected and recognized.

I am performing tests to verify it’s uplink is fully functional. It appears a bad bios revision is the cause, though.

I’ll keep you updated.

7

Hi,

5 days have passed of troubleshooting, analyzing the problem, and considering my next steps.

I have noticed that, without fail - flashing a new bios (such as .03 to 0.05 while the A500 is plugged in) results in it working perfectly for the duration of the connection, until it is replugged.

I have tested with Windows, and the device works during these cases, until I replug, in which it fails.

This leads me to think the framework desktop is at fault - specifically, my guess is an issue with PCIe allocation for the device, considering how it gives absolutely no response in Windows or Linux. Since the A500 specifically mentions power management, it’s possible the BIOS, in its restricted and virtually config free state, has some kind of invisible ASPM override or power restriction that gets temporarily bypassed during the flash, allowing the device to initalize, then once the device is reconnected it possibly recognizes and reverts? I’m no expert on BIOS or low level systems, so I’m just guessing.

Regardless, I’m unsure of my next steps. Do you think I should email framework directly? This seems to be an issue with the desktop, but it’s possible some OS level flag can be set to circumvent this issue that I’m just not aware of - I’m just worried framework won’t care about me since I have a “edge case”, I mean - not alot of people are even using EGPU’s.

8

^ Sorry for double-messaging, I accidentally replied to myself instead of you. I wrote something above.