Fix: Linux PC Wakes Up Instantly After You Suspend It

The Problem

You hit suspend. Screen goes black. A second later, it's back on, showing the lock screen. Every time.

This isn't random, and it isn't just your machine being weird. Something in your hardware is sending a wake signal the moment the system tries to sleep, so the kernel just does what it's told.

This Is a Known, Recurring Bug

This exact issue has been reported for years across Arch, Ubuntu, Fedora, Linux Mint, and Unraid, showing up on laptops, desktops, and even AMD B550 and X670E motherboards. It's been discussed on the Arch forums, Ubuntu's bug tracker, Linux Mint forums, GitHub issues, and even the kernel.org bug tracker itself. An AMD kernel engineer has confirmed it's a long-standing hardware quirk rather than a new bug, and it just started showing up more clearly in logs after kernel 5.17.

So if you're stuck on this at 1am, you're not the only one, and it's fixable.

What's Actually Causing It

Two components are responsible for almost every case:

1. Your NVMe SSD's PCIe port
Your NVMe drive sits on a PCIe root port that has "wake-up" enabled by default. Sometimes that port sends a wake signal, called a PME, and it gets stuck "on" instead of clearing properly. The next time you suspend, the kernel sees that stuck signal and immediately wakes the system back up.

2. Your USB controller (xHCI)
Check your logs, and if you see something like this right after a failed suspend, this is your culprit:

xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit

That means your USB controller couldn't cleanly suspend, so it had to restart itself. This is common with wireless mouse and keyboard dongles or USB touchscreens.

Both problems look identical from the outside, since either one causes the same pattern: suspend, then instant wake, every time.

Step 1: Confirm What's Happening

Before fixing anything, check what's actually going on.

Check if it's really an instant wake:

journalctl --since "10 minutes ago" -g "PM:|resume|suspend"

Look for a suspend entry immediately followed by resume lines, within a second or two of each other. If you also see xhci_hcd and USBSTS mentioned, that's your USB-side clue.

Check which PCI devices can wake your system:

grep -l enabled /sys/bus/pci/devices/*/power/wakeup

This usually points to one PCIe bridge, and that's your suspect.

Find which PCIe port your NVMe drive sits on:

lspci -tv | head -30

Look for your SSD in the tree, then note the address just above it, something like 00:01.1.

Confirm that port has actually fired a wake signal:

cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup_count
cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup_last_time_ms

A number above zero means it's really happened, not just a theory.

Also check ACPI-level wake sources:

cat /proc/acpi/wakeup

Look for anything marked *enabled, especially entries starting with XHC (USB controller) or GPP (PCIe root port). Keep in mind this list won't always match the sysfs check above, so treat the sysfs check as the real answer for the NVMe issue, and this list as the real answer for the USB issue.

Step 2: Fix It

Fix A: a udev rule that runs at boot

Replace 0000:00:01.1 with the address you found above:

echo 'ACTION=="add", SUBSYSTEM=="pci", KERNEL=="0000:00:01.1", ATTR{power/wakeup}="disabled"' | sudo tee /etc/udev/rules.d/99-disable-nvme-pme-wake.rules

sudo udevadm control --reload-rules
sudo udevadm trigger --action=add --sysname-match=0000:00:01.1
sudo udevadm settle

cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup   # should now say "disabled"

Fix B: a systemd service that runs before every suspend

A udev rule only applies once at boot, so if anything re-enables the wake flag later, whether that's a driver, a power tool, or a kernel update, the udev rule won't catch it again until your next reboot. This service re-applies the fix every single time you suspend, so it's the one that actually closes the loop:

sudo tee /etc/systemd/system/disable-nvme-wake.service <<'EOF'
[Unit]
Description=Disable NVMe PCIe PME wake before suspend
Before=suspend.target systemd-suspend.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo disabled > /sys/bus/pci/devices/0000:00:01.1/power/wakeup'

[Install]
WantedBy=suspend.target
EOF

sudo systemctl enable --now disable-nvme-wake

If it's a USB controller rather than a PCIe bridge, use the same service, but point it at the USB entry instead:

ExecStart=/bin/sh -c 'echo XHC0 > /proc/acpi/wakeup'

Other Things Worth Trying First

Check your BIOS/UEFI. Look for "Wake on PCI-E," "PCIe device wake," or "Wake on PME." Turning this off in firmware fixes it before Linux even gets involved, and it survives reinstalls. Be careful with a setting called "ErP Ready," since it can also affect suspend, sometimes for better and sometimes for worse.

How to Actually Test It

One successful suspend doesn't prove anything, so test it properly:

1. Reboot, then check the flag is already disabled with no manual steps.
2. Suspend once, and confirm it actually stays asleep for a couple of minutes.
3. Wake it, then suspend again immediately. This second suspend is the real test, since it tells you whether something re-armed the wake flag after the first resume. If both rounds stay asleep, you're done.

Undo It (If You Ever Need To)

sudo rm /etc/udev/rules.d/99-disable-nvme-pme-wake.rules
sudo udevadm control --reload-rules
sudo systemctl disable --now disable-nvme-wake
sudo rm /etc/systemd/system/disable-nvme-wake.service

Quick Reference

This has been independently reported on AMD B550 and X670E boards, NVMe laptops, and USB touchscreen all-in-ones, across Arch, Ubuntu, Mint, and more. It's a well-known issue with a well-known fix.