Summary
On a Framework Desktop (Ryzen AI MAX+ 395), BIOS 3.04, the platform's UCSI implementation persistently returns unknown error 256 (status byte 0x100) on commands related to the connector serving the Dell U3423WE USB-C monitor. As a result, the kernel can never publish port2, port2-partner, or port2-cable in /sys/class/typec/, and con2 Alt-Mode registration fails 100% of the time. The same failure pattern reappears in spontaneous mid-uptime clusters (no suspend/resume needed) — apparently triggered by PD renegotiations from the monitor's normal DPMS standby cycles. Intermittently the failure also takes down USB enumeration through the monitor's built-in hub, requiring a physical USB-C cable unplug/replug to recover.
System
|
|
| Hardware |
Framework Desktop, AMD Ryzen AI MAX+ 395 / Radeon 8060S (gfx1151) |
| BIOS |
3.04 (ESRT 0.0.3.4, dated 2025-11-19) |
| EC |
(default, no overrides) |
| OS |
Linux Mint 22.3 |
| Kernel |
6.17.0-23-generic |
| Monitor |
Dell U3423WE (34" 3440×1440 ultrawide, USB-C hub w/ DP-Alt-Mode + 90W PD) |
| Monitor scaler firmware |
M2B103 (latest as of 2026-05-06; updated from M2B101 during investigation) |
| Monitor PD controller |
TI TPS65987DDJ, firmware version 5CD101 (latest shipping; unchanged by M2B103 update — Dell's M2B103 package contained the same PD firmware version that was already on the monitor) |
| Monitor scaler chip |
MST9U03RN-3 |
| Monitor USB hub silicon |
Microchip USB5734 + USB4206 downstream |
| Cable |
USB-C to USB-C, passive (exact provenance not confirmed — possibly Dell-supplied with the U3423WE; e-marker status not verified) |
Symptom
The connector to the Dell monitor (con2) never registers a partner or cable in the typec sysfs hierarchy across the entire boot — /sys/class/typec/port2, port2-partner, and port2-cable are absent, while port0 and port1 are populated normally. Despite this, DisplayPort video and USB enumeration through the monitor's built-in hub usually function — they appear to succeed via paths that don't depend on UCSI's partner/Alt-Mode registration.
The kernel logs show a continuous failure pattern from the moment of boot:
unknown error 256 from UCSI command responsesGET_CABLE_PROPERTY failed (-5)con2: failed to register partner alt modes (-5)- intermittently:
UCSI_GET_PDOS failed (-5) and (-70)
These reappear in clusters every few hours during ordinary uptime — apparently triggered by spontaneous PD renegotiations from the monitor (DPMS standby cycles, monitor power events, etc.) — without any suspend/resume action by the user.
In some boots the symptom escalates to a complete USB-side enumeration failure for the monitor's hub, recoverable only by a physical USB-C cable unplug/replug. In other boots (such as the current one), USB devices stay enumerated despite the persistent UCSI errors.
Devices behind the Dell hub (when working)
Bus 007 hierarchy:
Microchip USB4206 Smart Hub (Dell's upstream hub)
├── Realtek RTL8153 Gigabit Ethernet
└── Microchip USB4206 Smart Hub (Dell's downstream hub)
├── Logitech Unifying Receiver (mouse)
├── Logitech Illuminated Keyboard (USB-A)
├── Logitech Brio 101 webcam
└── Microchip USB2 Controller Hub
Kernel log evidence
Cold boot — single error 256 immediately, then con2: failed to register partner alt modes (-5) reappears throughout the entire uptime:
[ 3.092098] ucsi_acpi USBC000:00: unknown error 256
... (no further errors for ~18 hours) ...
[65925.284836] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
[66068.187279] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
[66114.944974] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
... (persistent reattempts thereafter) ...
Spontaneous mid-uptime cascade (no suspend/resume involved):
[104474.809502] ucsi_acpi USBC000:00: unknown error 0
[104474.809514] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
[104475.653433] ucsi_acpi USBC000:00: unknown error 256
[104475.653447] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[104476.460457] ucsi_acpi USBC000:00: unknown error 256
[104476.460466] ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)
The unknown error 256 is a UCSI status byte the kernel doesn't have a name for, returned from the platform's UCSI implementation (BIOS/EC). The downstream consequences:
GET_CABLE_PROPERTY returns -EIOUCSI_GET_PDOS returns -EIO or -EAGAIN- Alt-Mode registration for the partner (
con2) fails with -EIO
- The kernel never publishes
port2, port2-partner, or port2-cable to sysfs — userspace tools (typecstatus, lsusb -t -v typec section, etc.) see no information for connector 2 at all
- In some boots, the USB-side enumeration of the monitor's hub also fails — recoverable only by a physical USB-C unplug/replug
Workaround
When the symptom escalates to a USB enumeration failure: physically unplug and reconnect the USB-C cable. This forces a fresh PD/Alt-Mode handshake that succeeds at the USB-side level (though con2 partner/cable still does not appear in sysfs).
When the symptom remains at the "UCSI errors but USB still works" level: no action — the system remains usable, just with broken UCSI state.
Frequency
100% reproducible: every boot since BIOS 3.04 produces con2: failed to register partner alt modes (-5) errors, with port2* permanently absent from sysfs. On a representative current boot (uptime 2 days 16 hours, 0 suspend cycles), 4 distinct UCSI error cascades fired — at boot, then spontaneously at +18h, +18.5h, and +29h of uptime — with 269 total ucsi_acpi error log lines.
The user-visible USB-enumeration failure (cable replug required) is intermittent — appears on ~some fraction of cold boots and resumes-from-suspend, while other boots leave USB working despite the UCSI errors.
Why this isn't a kernel-side issue
The error originates inside the platform's UCSI command/response (status byte 0x100 = "error 256"), not in the kernel driver's state machine. The kernel cannot recover because it never receives valid cable/partner data. A physical replug recovers USB-side enumeration in the affected boots, but does not cause port2* to appear in sysfs — i.e. the platform's UCSI state for con2 stays broken even after replug. This points strongly at either the Framework EC's UCSI implementation, the AMD PMFW/SMU UCSI path, or the interaction between either of those and the Dell monitor's TI TPS65987DDJ PD controller.
Monitor side ruled out as the sole cause
The Dell U3423WE was updated to the latest firmware bundle (M2B103) during this investigation. Per Dell's firmware utility log, the M2B103 package's bundled PD-controller firmware (5CD101 for the TI TPS65987DDJ) matched the version already on the monitor — meaning the PD-side firmware on this monitor was already current, and the bug reproduces against the latest shipping PD firmware. The handshake failure must therefore originate in the platform UCSI implementation (BIOS/EC) or the PD-controller↔platform interaction, not in stale Dell firmware.
Relationship to BIOS 3.05
BIOS 3.05's release notes already list as a known issue: "Certain USB-C peripherals may exhibit intermittent compatibility issues during the PD or DisplayPort Alt Mode handshake." Multiple users with USB-C monitors have reported regressions on 3.05 and downgraded to 3.04. This bug therefore appears to be present in both 3.04 and 3.05; staying on 3.04 to avoid the additional 3.05 USB-C regressions.
What would help
- A UCSI/PD changelog entry in a future BIOS that addresses unknown status code 0x100 / cable-property failure
- Confirmation of whether this is a Framework EC firmware issue, an AMD PMFW/SMU issue, or a UCSI firmware issue — to know whether to expect a fix in BIOS or in an AGESA / PMFW update
- (Optional) A way to dump UCSI command/response traces for filing more detailed reports
Additional info on request
Happy to capture:
- Full
dmesg from a failing boot
lsusb -t -v output/sys/class/typec/port*/ dumps in failing vs working statesacpidump if the UCSI ACPI tables would help
Summary
On a Framework Desktop (Ryzen AI MAX+ 395), BIOS 3.04, the platform's UCSI implementation persistently returns
unknown error 256(status byte 0x100) on commands related to the connector serving the Dell U3423WE USB-C monitor. As a result, the kernel can never publishport2,port2-partner, orport2-cablein/sys/class/typec/, andcon2Alt-Mode registration fails 100% of the time. The same failure pattern reappears in spontaneous mid-uptime clusters (no suspend/resume needed) — apparently triggered by PD renegotiations from the monitor's normal DPMS standby cycles. Intermittently the failure also takes down USB enumeration through the monitor's built-in hub, requiring a physical USB-C cable unplug/replug to recover.System
Symptom
The connector to the Dell monitor (
con2) never registers a partner or cable in the typec sysfs hierarchy across the entire boot —/sys/class/typec/port2,port2-partner, andport2-cableare absent, whileport0andport1are populated normally. Despite this, DisplayPort video and USB enumeration through the monitor's built-in hub usually function — they appear to succeed via paths that don't depend on UCSI's partner/Alt-Mode registration.The kernel logs show a continuous failure pattern from the moment of boot:
unknown error 256from UCSI command responsesGET_CABLE_PROPERTY failed (-5)con2: failed to register partner alt modes (-5)UCSI_GET_PDOS failed (-5)and(-70)These reappear in clusters every few hours during ordinary uptime — apparently triggered by spontaneous PD renegotiations from the monitor (DPMS standby cycles, monitor power events, etc.) — without any suspend/resume action by the user.
In some boots the symptom escalates to a complete USB-side enumeration failure for the monitor's hub, recoverable only by a physical USB-C cable unplug/replug. In other boots (such as the current one), USB devices stay enumerated despite the persistent UCSI errors.
Devices behind the Dell hub (when working)
Kernel log evidence
Cold boot — single error 256 immediately, then
con2: failed to register partner alt modes (-5)reappears throughout the entire uptime:Spontaneous mid-uptime cascade (no suspend/resume involved):
The
unknown error 256is a UCSI status byte the kernel doesn't have a name for, returned from the platform's UCSI implementation (BIOS/EC). The downstream consequences:GET_CABLE_PROPERTYreturns-EIOUCSI_GET_PDOSreturns-EIOor-EAGAINcon2) fails with-EIOport2,port2-partner, orport2-cableto sysfs — userspace tools (typecstatus,lsusb -t -vtypec section, etc.) see no information for connector 2 at allWorkaround
When the symptom escalates to a USB enumeration failure: physically unplug and reconnect the USB-C cable. This forces a fresh PD/Alt-Mode handshake that succeeds at the USB-side level (though
con2partner/cable still does not appear in sysfs).When the symptom remains at the "UCSI errors but USB still works" level: no action — the system remains usable, just with broken UCSI state.
Frequency
100% reproducible: every boot since BIOS 3.04 produces
con2: failed to register partner alt modes (-5)errors, withport2*permanently absent from sysfs. On a representative current boot (uptime 2 days 16 hours, 0 suspend cycles), 4 distinct UCSI error cascades fired — at boot, then spontaneously at +18h, +18.5h, and +29h of uptime — with 269 totalucsi_acpierror log lines.The user-visible USB-enumeration failure (cable replug required) is intermittent — appears on ~some fraction of cold boots and resumes-from-suspend, while other boots leave USB working despite the UCSI errors.
Why this isn't a kernel-side issue
The error originates inside the platform's UCSI command/response (status byte 0x100 = "error 256"), not in the kernel driver's state machine. The kernel cannot recover because it never receives valid cable/partner data. A physical replug recovers USB-side enumeration in the affected boots, but does not cause
port2*to appear in sysfs — i.e. the platform's UCSI state for con2 stays broken even after replug. This points strongly at either the Framework EC's UCSI implementation, the AMD PMFW/SMU UCSI path, or the interaction between either of those and the Dell monitor's TI TPS65987DDJ PD controller.Monitor side ruled out as the sole cause
The Dell U3423WE was updated to the latest firmware bundle (M2B103) during this investigation. Per Dell's firmware utility log, the M2B103 package's bundled PD-controller firmware (
5CD101for the TI TPS65987DDJ) matched the version already on the monitor — meaning the PD-side firmware on this monitor was already current, and the bug reproduces against the latest shipping PD firmware. The handshake failure must therefore originate in the platform UCSI implementation (BIOS/EC) or the PD-controller↔platform interaction, not in stale Dell firmware.Relationship to BIOS 3.05
BIOS 3.05's release notes already list as a known issue: "Certain USB-C peripherals may exhibit intermittent compatibility issues during the PD or DisplayPort Alt Mode handshake." Multiple users with USB-C monitors have reported regressions on 3.05 and downgraded to 3.04. This bug therefore appears to be present in both 3.04 and 3.05; staying on 3.04 to avoid the additional 3.05 USB-C regressions.
What would help
Additional info on request
Happy to capture:
dmesgfrom a failing bootlsusb -t -voutput/sys/class/typec/port*/dumps in failing vs working statesacpidumpif the UCSI ACPI tables would help