Skip to content

🕵️ Inspector Suspend

I have a Linux laptop that is Intel all the way down and when locked, it never suspends... It's great when your laptop is dead nearly every time you pick it up 😮‍💨

🔎 Let's Find Out

nuckle crack time to bust out our investigation skills to track down this frustrating condition.

I'm using NixOS which is a systemd distro so the first place I'm heading is journalctl.

journalctl -b | grep -i suspend

In the output we see something telling, It never actually went to sleep.

The device attempted to suspend but comes back without entering sleep

System returned from sleep operation 'suspend'

This kernel line indicates the kernel started suspend but bailed out almost immediately 

printk: Suspending console(s)
PM: suspend exit

This is exactly what happens when some hardware or driver vetoes suspend, especially on Intel laptops with problematic ACPI tables, dGPUs, or network devices. Let's track down the culprits and debug it.

We can check out systemd-inhibit for anything that may be keeping our system awake.

systemd-inhibit --list but sadly none of these are blocking suspend. If something were blocking you would see MODE = block.

Suspend is not being blocked by systemd or user-space. That means the problem is kernel / hardware / ACPI / a specific device driver.

🤔 Where do we go from here.

Does the kernel attempt to freeze tasks?

journalctl -b -u systemd-suspend --no-pager

This log will show:

  • Whether the kernel actually entered freeze stage

  • Which device refused it

  • Whether ACPI aborted the transition

  • If a driver vetoed D3 suspend (common on Intel laptops)

Also, lets use dmesg to check the kernel for errors

  • “Freezing of tasks failed”

  • “Some devices didn’t suspend”

  • “ACPI: EC: failed to transition”

  • “PM: device xyz refused to enter D3cold”

dmesg | grep -Ei "fail|error|acpi|pm|pci|d3|freeze"

The Smoking Gun

The laptop is not entering suspend at all.

systemd asks the kernel to suspend → kernel starts suspend → kernel immediately aborts → systemd thinks you “resumed”.

So far we are only seeing the wrapper and not the actual kernel reason, to find the actual cause we need the kernel-level PM logs. They are not in systemd-suspend.service, but in the kernel ring buffer.

Lets expand the dmesg command to get more detail

dmesg | grep -Ei "fail|failed|error|acpi|pm|pci|d3|freeze|usb|iwl|wifi|btusb|i915"

  • "PM: Some devices failed to suspend"
  • "ACPI: EC: failed to transition"
  • "pci_pm_suspend(): X failed"
  • "iwlwifi: Error in power management"
  • "i915: GPU not idle"
  • "btusb: can't suspend"
  • "Freezing of tasks failed"

In the sea of output we see the issue!

[ 3299.828267] PM: suspend entry (s2idle)
[ 3300.016489] ACPI: EC: interrupt blocked
[85823.417118] ACPI: EC: interrupt unblocked
[85823.561808] mei_me 0000:00:16.0: hbm: dma setup response: failure = 3 REJECTED
[85823.830198] PM: suspend exit
[91734.184423] PM: suspend entry (s2idle)
[91734.351756] ACPI Error: No handler or method for GPE 6B, disabling event (20240827/evgpe-839)
[91734.372617] ACPI: EC: interrupt blocked
[124574.790810] ACPI: EC: interrupt unblocked
[124574.930381] mei_me 0000:00:16.0: hbm: dma setup response: failure = 3 REJECTED
[124575.200265] PM: suspend exit

The kernel is trying suspend using s2idle:

PM: suspend entry (s2idle)

The Embedded Controller (EC) interrupts become blocked during the attempt:

ACPI: EC: interrupt blocked

The Intel Management Engine Interface (MEI / mei_me) reports DMA setup failures:

mei_me 0000:00:16.0: hbm: dma setup response: failure = 3 REJECTED

Then the kernel immediately aborts suspend and returns:

PM: suspend exit

The kernel driver / firmware (likely the MEI device mei_me, and possibly the EC/ACPI firmware) is rejecting the suspend transition, which causes an immediate “instant resume”. This is a very common pattern on modern Intel laptops, especially when the system uses s2idle (the shallow S0-based idle) instead of a deeper S3-style sleep.

I would have thought a coreboot first Linux laptop wouldn't have these issues or an active MEI, but here we are 😠 I will need to add a declarative test after NixOS rebuilds to make sure it doesn't become enabled again.

Finding A Fix

Let's begin with testing temporary fixes, then turn it into a permanent fixture of this laptops deployment.

Driver blacklist

Since we saw the mei_me errors - unloading the driver is my go to.

sudo modprobe -r mei_me

Then test suspend:

systemctl suspend

If suspend now works after removing mei_me, that strongly implicates the MEI driver.

If modprobe -r refuses because of device in use, check lsmod | grep mei or sudo lsof /dev/mei* to find the culprit. If you are unable to kill the process and get driver to unload, you may need to just rebuild with the blacklist kernel params and reboot the device.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash modprobe.blacklist=mei,mei_me"

deep sleep

Check the devices supported and current modes cat /sys/power/mem_sleep for sleep.

sudo sh -c 'echo deep > /sys/power/mem_sleep'
systemctl suspend

If deep doesn't fix the sleep issue test some other options in your kernelParams

Add one or more of these, one at a time, to see if they help:

  • mem_sleep_default=deep (first choice)

  • acpi.ec_no_wakeup=1 (prevents EC from waking; helps some EC-firmware bugs)

  • pcie_aspm=off (if a PCI device refuses suspend)

  • pci_power_delays=0 (rare)

Hail Mary

Capture live kernel logs while reproducing.

If suspend still fails, capture the kernel output live to see the exact failing driver. Run both these commands and attempt to suspend the device:

sudo dmesg -wH
sudo systemctl suspend

NixOS Fix

{
  # Disable Intel ME interfaces: safe when ME is neutered (System76)
  boot.blacklistedKernelModules = [
    "mei"
    "mei_me"
    "mei_hdcp"
    "mei_pxp"
  ];
}

dmesg | grep -i mei you should not see any “mei_me” or “MEI device” messages anymore.

⚠️ Notes

This does not disable Intel ME firmware itself, only the Linux driver that talks to it.

Disabling mei_me breaks:

  • Intel AMT / vPro
  • Some laptop hotkeys on enterprise hardware (rare)

Most consumer laptops work perfectly fine without it.