After a USB-C hotplug event, the Embedded Controller entered a hung state. Port 4 (USB4-capable) lost DisplayPort Alt Mode output, USB Power Delivery charging, and downstream USB audio — while USB data continued to pass. Further hotplug events caused the ACPI EC event processor to escalate from hanging 4 times to 11 times, ultimately causing the Framework internal input module (32ac:0018) to disappear from the USB bus entirely, leaving the keyboard and trackpad unresponsive.
A full shutdown and power drain did not recover the EC. Recovery required physical disassembly and pressing the chassis intrusion switch 10 times (~2 seconds each).
Steps to reproduce
Not yet fully determined — the EC appeared to enter the bad state spontaneously. The failure was noticed when a previously-working USB-C DisplayPort cable stopped working on port 4.
Symptoms observed
Port 4: no display output via DP Alt Mode
Port 4: no USB-C charging (no red LED on monitor/dock)
Port 4: daisy-chained USB audio device not functioning
USB data through port 4 continued working throughout
lsusb showed 32ac:0018 (Framework input module) missing from all broken boots
Built-in keyboard and trackpad became completely unresponsive
Kernel log evidence
GPU Alt Mode negotiation timing out at boot:
amdgpu 0000:c1:00.0: [drm] Alt mode has timed out after 212 ms
EC hogging CPU on every USB-C plug event (escalating):
workqueue: acpi_ec_event_processor hogged CPU for >10000us 4 times
workqueue: acpi_ec_event_processor hogged CPU for >10000us 7 times
workqueue: acpi_ec_event_processor hogged CPU for >10000us 11 times
UCSI completely absent (no Alt Mode or PD negotiation possible):
There are a few threads with overlapping symptoms, though none that combine the full chain I described. This thread (#52012), this one (#47846), and this one (#38762) all document UCSI ACK failures and DisplayPort losses on FW16 AMD — Framework acknowledged at the time that it was related to AMD’s PD controller behaviour. Thread #48089 covers USB-C PD charging failures specifically, and Framework confirmed a PD firmware fix was in the works.
The closest match I found to the full EC hang was thread #82578 from May 2026 — a FW13 AMD 7040 going fully unresponsive with port-specific charging failure during the hung state. Different model but very similar pattern.
If you’re on Windows and have seen the AMD UCM-UCSI Error 43 with the left side going completely dead, thread #63645 covers the same failure there.
For anyone digging into the EC itself, DHowett’s thread (#12846) is the best reference — it explains the chassis intrusion counter and why pressing the switch seems to shake the EC out of a bad state.
You are responding to an AI Bot. Both posts are just AI. While we all await framework fixing the ec issues, AI posts like this do very little to help. People need to post constructive, correct, reports on the relevant GitHub issues for the framework 16 EC.
Yeah, the second one especially has a “search online for this problem” feel. Thread IDs instead of URLs, user handles without the @, and apparently the cloud-end scraper couldn’t “scroll” the Discourse thread enough to surface the 20-second workaround.
RCA: Insufficient caffeination.
Nothing wrong with AI assistance for debugging, but quantity of information does not always have (the right kind of) quality of its own when it comes to bug reports - curation still needed.
I wonder if this was the result of an ad-hoc chat vs. say a claude code session with some directives about but report content. Come to think of this, lots of repos have markdown forms to guide bug submission. Wtih the github CLI and some brief directives, I bet claude code can create better bug reports.
Now if there’s something that’s safe enough to hand a browser to (for solving the scraping problem locally, thus avoiding reddit-style blocks and “missing” dynamic content like we seem to have here)… Maybe a containerized sub-agent that runs a headless browser, hm…
This thread so far is a little confusing.
It would be easier if you just said what devices (make, model) are plugged into each of the slots. And which device was “usb-c hotplug”.
Please also include some syslog log messages showing the problem point and also a good quantity of log messages before that.
This is not a EC problem. It is more likely a USB-PD firmware problem.
use “sudo ectool console” to gather logs from the EC, and you will see that it is still outputting new messages, so it had not hung.
You can also easily reset the EC without opening anything up.
Power off laptop.
Remove power adapter
Wait 120 seconds ( There is a delay before the EC powers itself off.)
Insert power adapter
Power on laptop. ( This turns the EC back on)
You can use “sudo ectool console” to see if the timestamps have been reset to back to zero to prove the EC reset.
What other USB devices disappear when the problem happens.
“lsusb” before the problem.
then
“lsusb” after the problem and see what is missing.
unfortunately it is a human. after spending half my working day trying to figure it out. I used the copilot cli to narrow down options, and make sure i am not wasting humans time.
The working setup before “usb-pd” or the “ec” bug surfaced was.
On port:
1 usb-c module connected to usb 3 hub, with keyboard, mouse and usb webcam
2 hdmi module, connected to a display
3 empty,
4 usb c module, connected to a display, it provides power and has a microphone attached. This is the one that originally stopped working.
5 empty
6 empty
the fact that thee laptop keyboard and the trackpad went AWOL, was what shocked me.
anywho.
i did try the 20 second power button press. From the laptop being on, and the laptop being off.
it did not work.
i had in the past have the bad charging scenario, where the laptop would not charge. and a combination of random power button presses and leaving the laptop for a while did recover it. And it started charging.
@jared_kidd thanks for letting me know there is a github page. you are the best
@James3 to confirm what you are saying the “USB-PD problem” stops the framework laptop keyboard from working and the trackpad. only an external keyboard worked.
i did not know about the sudo ectool console.
for the lsub, it was originally anything attached to port 4.
The port 1 hub might be drawing too much power from the laptop.
Is it an externally powered hub? The FW cannot supply much power from its ports. Expansion Card Slot functionality on Framework Laptop 16 (AMD Ryzen™ AI 300 Series)
Ports 1,2,4,5 are shared on a first come first serve basis. So they are 1.5A by default, but one port from any of these can negotiate 3A over PD. Once that is taken, the other ports are limited to 1.5A. Ports 3,6 are 900mA.
All those Amps are at 5V. So 3A = 15W, 1.5A = 7.5W, 0.9 = 4.5W
The display supplying power to port 4 might be the problem if it has a fault in it.
Earth currents. When multiple devices are plugged in, and they each have their own 2-Pin mains power adapters, The voltage on the USB-C shields “floats”. So that when you connect two devices over USB-C and both sides is connected to its own 2-Pin mains, problems can occur. There is a big rush of current until the “floats” equalize. The easiest fix for this is to have all devices using 3-pin mains power plugs, like the FW16 power adapter has. The USB-C shields then do not float, and are all tied to the same GND.
You have two displays, and my guess is they are using 2-pin power adapters.
Being that a majority of the problems are with this port, I suspect (2) is the most likely problem.
(1)I have been using the laptop for about 2 years, on the same setup.
This is the first time it has went so far wrong, i had to open the laptop. So that is pretty good.
Having to open it, caught me out.
(2)
It is a samsung display, and a cheap one at that. It could be.
(3)
the big monitor is a LG c2 and i am in the UK. So it is not a removable cable, and it is on 3 prongs.
the samsung monitor uses a kettle lead, C13 cable.
Now i know how to fix, it. it is grand.
I wanted to know
if there was an obvious fix.
put up my findings, so someone might get to a solution faster.