AMD USB-C Monitor Not Charging After Sleep on Linux: Cause and Workaround

dmesg showing ucsi_acpi ETIMEDOUT PPM init failed error on Linux after sleep resume

You suspend your AMD laptop, come back 20 minutes later, and the USB-C monitor is showing your desktop just fine — but the battery is at 61% and dropping. The cable is seated, the display works, but charging has silently stopped. This is a real kernel bug affecting any AMD Ryzen laptop using s2idle with a USB-C monitor that carries both video and power delivery over a single cable. The ThinkPad E14 Gen 7 AMD is where this has been extensively documented, but the failure mode hits broadly across AMD platforms and is not a hardware defect you can RMA your way out of.

Symptoms: How to Know You Have This Bug

The frustrating part of this bug is that it looks fine on the surface. The monitor has an image. The USB-C cable is plugged in. Nothing in the system tray is screaming at you. What's actually happening: the monitor is drawing power from your laptop's battery while delivering zero watts back through PD. The system reports the AC line as online because the cable is electrically connected, but the power delivery contract was never renegotiated after resume.

Specific symptoms to check for:

Monitor displays video normally after wake — no blank screen, no flicker
Battery percentage is falling despite the USB-C cable being connected
No charging indicator in your desktop environment, or it shows "plugged in, not charging"
Physically unplugging and replugging the USB-C cable does not fix it
Only a full power cycle of the monitor resolves it

Confirm the charging state at the terminal:

upower -i /org/freedesktop/UPower/devices/line_power_AC0
# Should show: online: yes AND charging rate > 0W
# If online: yes but rate is 0 or missing — you have this bug

If online: yes but there's no energy-rate or it shows 0.000 W, the PD contract is dead. The kernel thinks you're connected to power. You are not receiving any.

Confirm the Root Cause in Your Logs

After a failed resume — one where the monitor shows video but isn't charging — immediately check dmesg before anything else touches the system. The errors decay quickly in busy log buffers.

sudo dmesg | grep -E "ucsi|PME|typec|pd" | tail -20

You're looking for two specific strings. If both appear in the output following a resume event, you've confirmed the exact bug described in this article:

# The two errors that confirm this bug:
# ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
# pcieport 0000:00:08.1: PME: Spurious native interrupt

The ETIMEDOUT: PPM init failed line means the UCSI (USB Type-C Connector System Software Interface) driver attempted to re-initialize the AMD USB-C controller after waking from sleep and hit a timeout. The PPM (Platform Policy Manager) didn't respond in time. The UCSI driver gives up, marks the controller as failed, and power delivery negotiation never happens.

The Spurious native interrupt line is the second failure compounding the first. The PCIe port is generating interrupts the kernel isn't expecting post-resume, which consumes CPU time in interrupt handling and interferes with the timing window the UCSI driver needs to complete PPM init. These two failures are causally linked — the PME interrupt storm makes the UCSI timeout more likely and more severe.

To get a timestamped view that shows these errors in context with the resume sequence:

sudo journalctl -k --since "10 minutes ago" | grep -E "ucsi|PME|typec|resume|suspend"

Why This Happens: The Triple Failure

This bug is the product of three separate failures that only become visible together. Understanding each layer matters because it explains why every obvious fix doesn't work.

Layer 1 — AMD UCSI controller fails to re-initialize after s2idle. The AMD UCSI controller is an ACPI-managed device. When the system enters s2idle (modern standby), the controller's internal state machine is reset. On resume, the Linux kernel's generic ucsi_acpi driver attempts to reinitialize the PPM — the component that manages USB-C policy including power delivery. On AMD hardware, this re-init requires specific sequencing that AMD's proprietary Windows driver handles through a custom resume path. The Linux 6.17 generic driver doesn't implement this AMD-specific sequencing. The PPM init attempt times out. The controller is left in a half-initialized state and the USB-C port operates as display-only with no PD capability.

Layer 2 — PCIe port spurious PME interrupt loop. Simultaneously, PCIe port 0000:00:08.1 begins generating Power Management Events after resume that the kernel classifies as spurious. These aren't AER (Advanced Error Reporting) events — they're PME interrupts from the port itself stuck in a loop because its wake state wasn't cleanly restored. This interrupt flood isn't fatal, but it consumes scheduling bandwidth and critically, it contends with the interrupt handling that UCSI initialization depends on, pushing the already-marginal PPM init timing past the timeout threshold.

Layer 3 — LG monitor firmware PD state machine. The LG 34WR55QK-B (and monitors with similar firmware architectures) requires a full power cycle to reset their internal PD state machine when the PD contract is dropped uncleanly. When the laptop goes to sleep, the monitor sees the PD contract terminate. On resume, if the host-side UCSI isn't ready to renegotiate quickly and cleanly, the monitor's firmware ends up in a state where it will pass DisplayPort signal but will not re-enter PD negotiation without a power cycle. This is a firmware limitation of the monitor, not a Linux bug per se — but it exposes the kernel bug by removing the fallback path that a more lenient monitor might provide.

Why Windows doesn't have this problem: AMD ships a proprietary UCSI driver for Windows that handles the AMD-specific PPM re-initialization sequence on resume. It knows the exact register sequence and timing required to bring the controller back from s2idle cleanly. The generic Linux ucsi_acpi driver implements the UCSI spec but doesn't account for AMD's vendor-specific resume requirements. This is not a Windows-vs-Linux quality argument — it's a closed specification problem. AMD hasn't published the resume sequencing requirements needed for the Linux driver to match Windows behavior.

Everything That Doesn't Fix It (And Why)

This section exists because every approach below looks reasonable, and every one of them fails for a specific technical reason. Work through the list before you spend an hour on any of them.

What Was Tried	Why It Fails
systemd-sleep hook: `modprobe -r ucsi_acpi` on suspend, reload on resume	The module reloads but reads the same stale ACPI state. The ACPI namespace still holds the pre-sleep controller state, and the module re-attaches to a broken foundation. You're reloading the driver, not resetting the hardware it talks to.
`pci=noaer` kernel parameter	Suppresses AER error logging only. The spurious PME interrupt loop continues to run — you've just made it invisible. The interrupt contention with UCSI init is unchanged.
`modprobe -r amd_pmc`	AMD PMC (Power Management Controller) handles S0ix state transitions at a different layer. It is not in the UCSI re-init call path. Unloading it changes nothing for PD negotiation.
udev rule to keep LG device awake during suspend	The udev rule fires too late in the resume sequence. By the time udev processes device events post-resume, the UCSI driver has already attempted and failed PPM init. You cannot prevent the failure from userspace at udev timing.
Disabling TLP	TLP manages runtime power management for active devices. Suspend and resume are handled directly by the kernel's sleep subsystem. TLP has no involvement in this path at all.
`setpci -s 0000:00:08.1 0xF4.B=0x20`	Writing to the PCIe config register doesn't clear the spurious PME state after resume because the PME status bit is re-asserted by the port hardware on the next cycle. The write clears it once; the hardware sets it again immediately.
`echo 1 > /sys/bus/pci/rescan`	PCI rescan enumerates devices and re-reads BARs. It does not reset the ACPI device state for UCSI, which lives in the ACPI namespace above the PCI layer. The UCSI device remains in its failed init state.
USB device remove + rescan via sysfs	See the next section. Included with a code example because it appears most likely to work and specifically doesn't.

The Only Working Workaround

Power off the monitor completely. Not standby — full power off via the power button or by switching off at the wall socket or power strip. Leave it off for 2 to 3 minutes. Then power it back on.

Here's why this works when nothing else does: a full power cycle resets the LG monitor's internal PD state machine to cold state. When the monitor comes back up from cold, it performs a fresh PD advertisement. The laptop's UCSI controller, even in its partially-failed state, can sometimes complete a PD negotiation when the monitor initiates cleanly from cold — because the monitor sends the full capabilities message rather than expecting the host to resume a previous contract. It's not that the UCSI driver is now fixed; it's that the monitor is making it easier by starting completely fresh. The 2-3 minute window matters: some monitor firmware will re-enter a degraded state if powered on too quickly after shutdown.

If your monitor has a physical power button on the front bezel and is easy to reach, this is annoying but manageable — 2 minutes, you come back, everything works. If the monitor is wall-mounted and the power switch is behind the panel, or if it's on a powered hub with no individual outlet control, this workaround is genuinely painful. A smart plug on the monitor's power socket controlled via Home Assistant or a simple timer outlet can automate the power cycle, but that's environmental infrastructure, not a fix.

The following USB-layer approach is documented here specifically because it is the first thing a sysadmin will reach for, and it does not work:

# This does NOT fix it — UCSI failure is at ACPI layer, above USB enumeration
# Included here because it seems like it should work and it doesn't
echo 1 | sudo tee /sys/bus/usb/devices/7-1/remove
sleep 3
echo 1 | sudo tee /sys/bus/usb/rescan

This simulates a USB disconnect and reconnect at the USB enumeration layer. The reason it fails: the UCSI failure is at the ACPI layer, which sits above USB. USB enumeration depends on UCSI having successfully initialized and negotiated PD. When you remove and rescan the USB device, you're asking the USB stack to re-enumerate a device on a port where the underlying PD contract doesn't exist. The device removal succeeds. The rescan finds nothing to bring back because the physical layer condition (PD contract) hasn't changed. Your device node number (7-1) may also differ — check lsusb -t to identify yours — but the layer problem remains regardless of which device node you target.

Affected Hardware: Is This Your Bug?

This bug was documented on a ThinkPad E14 Gen 7 AMD running Zorin OS with kernel 6.17 and BIOS 1.19, connected to an LG 34WR55QK-B ultrawide via a single USB-C cable. But the failure conditions are not specific to this combination. The bug affects any AMD Ryzen laptop where all three conditions are present simultaneously.

You are likely hitting this same bug if:

Your laptop has an AMD Ryzen 6000, 7000, or 8000 series CPU
Your system uses s2idle (modern standby) as its sleep mode
You are running a single USB-C cable that carries both DisplayPort Alt Mode video and Power Delivery charging (not a separate charger + separate video cable)
Your monitor requires a full power cycle to recover — unplugging the USB-C from the laptop and replugging does not help

# Check your sleep mode
cat /sys/power/mem_sleep
# If output includes [s2idle] — you're in the same situation

# Check your CPU
grep "model name" /proc/cpuinfo | head -1

If mem_sleep shows [s2idle] as the active mode (the bracketed entry is the current selection), you're using the same suspend path where this bug manifests. If it shows [deep] instead, your sleep behavior is different — S3 deep sleep handles the UCSI controller state differently and this specific PPM init timeout may not apply, though you may have separate issues.

The monitor brand is less relevant than the monitor firmware behavior. Any monitor that requires a clean PD renegotiation from cold state — rather than accepting a host-initiated reconnect mid-session — will trigger the same symptom when the UCSI driver fails its PPM init. LG ultrawide firmware happens to be particularly strict about this, but it's not a defect in the monitor.

Current Status and How to Track the Fix

As of June 2026, kernel 6.17 does not contain a fix for this. A patch targeting the UCSI resume handling on AMD platforms has been posted to the linux-kernel mailing list but has not been merged into mainline. BIOS 1.19 is the latest available for the ThinkPad E14 Gen 7 AMD — Lenovo has not addressed this from the firmware side, and there's no indication they plan to since the root cause is in the kernel driver, not the BIOS.

To track progress on the fix:

Watch the linux-kernel mailing list archives at lore.kernel.org for threads containing "ucsi_acpi: fix resume handling" or "amd: ucsi: PPM init timeout"
Monitor the drivers/usb/typec/ucsi/ directory in the kernel git tree for commits referencing AMD or resume
After any kernel upgrade, check immediately whether the fix has landed before declaring it resolved

# After a kernel upgrade, check if UCSI got patched
sudo dmesg | grep -i ucsi
# A successful resume shows: ucsi_acpi USBC000:00: registered — without ETIMEDOUT

# Search kernel changelogs for ucsi changes after upgrade
grep -i ucsi /usr/share/doc/linux*/changelog.gz 2>/dev/null | less

The changelog grep is imperfect — package maintainers don't always expand every commit in the changelog — but a successful UCSI resume will show clean registration messages in dmesg without the ETIMEDOUT line. Do a test suspend/resume cycle after each kernel upgrade and check dmesg immediately. That's the definitive test.

Don't hold your breath for an OEM firmware update. Lenovo's BIOS updates for this platform have addressed other issues but the UCSI resume path is a kernel driver problem. AMD providing the necessary documentation or a reference implementation for the Linux UCSI driver would unblock this, but there's no public commitment to that timeline.

If You Find a Fix That Works

If you've found a workaround that actually works — a kernel patch you've backported, a specific kernel version where this doesn't reproduce, a BIOS setting that changes the behavior, or a smart plug automation that makes the power cycle tolerable — please share it. This article is actively maintained and the failure documentation here only gets better with data from more hardware combinations.

Use the comments section below or reach out directly via the contact page at tuxai.dev. Include your CPU model, kernel version, monitor model, and what sleep mode you're using. If you've found that a specific kernel between 6.17 and whatever current is has resolved this, that's the most useful signal possible for other users still hitting it.