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:
- Reboot, then check the flag is already disabled with no manual steps.
- Suspend once, and confirm it actually stays asleep for a couple of minutes.
- 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
| Symptom | Suspend, then instant wake, every time |
| Cause | A stuck PCIe wake signal, usually from your NVMe's port, or a USB controller failing to suspend cleanly |
| Find it |
grep -l enabled /sys/bus/pci/devices/*/power/wakeup, lspci -tv, cat /proc/acpi/wakeup
|
| Fix it | A udev rule paired with a systemd service, both disabling wake-up on the port |
| Test it | Reboot, then suspend, then wake, then suspend again |
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.
Top comments (0)