Testing & Validation Checklist – Ensuring Reliable Suspend/Resume in Linux

By the time you’ve configured ACPI, systemd, drivers, and firmware, you should not just trust that suspend/resume works. A broken wake-up device, half-suspended GPU, or stuck USB controller can ruin your power management.
This checklist ensures your laptop/server reliably sleeps, wakes, and conserves energy.

1. Baseline: Kernel & Firmware Verification

Before testing suspend cycles, confirm the kernel and firmware expose the expected interfaces.

1.1 Check kernel version & power support

uname -r

• Ensure it’s a modern kernel (≥ 5.x preferred). Older kernels may lack fixes for ACPI/NVMe.

dmesg | grep -i acpi

• Look for ACPI errors.

Example good output:

ACPI: Power Resource [WRST] (on)
ACPI: Waking GPE events enabled

1.2 Confirm ACPI tables are loaded

ls /sys/firmware/acpi/tables/

• Should list DSDT, SSDT*, FACP, etc.
• Missing DSDT usually means broken firmware → cannot proceed until fixed.

2. Validate Available Sleep States

Check what your system claims to support:

cat /sys/power/state

• freeze = light suspend
• mem = S3 (suspend-to-RAM)
• disk = S4 (hibernation)

Example of output:

freeze mem disk

If mem is missing, S3 is likely not supported → fallback is S2Idle (more CPU drain).

3. Test Suspend/Resume Cycles

Run a manual suspend from shell (not just closing lid).

systemctl suspend

• Screen should blank, fans stop, system enters S3.
• On wake, log back in.

3.1 Automated test loop

for i in {1..5}; do
  echo "Cycle $i: suspending..."
  systemctl suspend
  sleep 10
done

• Verifies multiple cycles, useful for catching race conditions.

Check journal after each cycle:

journalctl -b | grep -i suspend

Good signs:

PM: suspend entry (deep)
PM: suspend exit

4. Resume Latency & Wake Sources

Check what devices woke the system:

cat /proc/acpi/wakeup

Example of output:

Device  S-state   Status   Sysfs node
XHC     S3        *enabled  pci:0000:00:14.0

• XHC = USB controller
• If your laptop wakes randomly, this is usually the culprit.

Disable noisy devices (e.g., USB mouse):

echo XHC > /proc/acpi/wakeup

5. USB & Peripheral Testing

Verify autosuspend for USB devices

for dev in /sys/bus/usb/devices/*/power/control; do
  echo $dev: $(cat $dev)
done

• Expected: auto
• If on → device never suspends → drains battery.

Enable autosuspend manually:

echo auto | sudo tee /sys/bus/usb/devices/1-1/power/control

6. GPU & Driver State

For NVIDIA/Intel systems, GPU is often the #1 problem.

Check runtime power state

cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status

• suspended → good
• active → still consuming power

If stuck active, verify driver:

dmesg | grep -i nvidia

Or for Intel:

journalctl -k | grep -i i915

7. Network Adapters

7.1 Wi-Fi (Intel/Realtek)

Check power management:

iwconfig wlan0

Look for: Power Management:on

If off, turn it on:

sudo iw dev wlan0 set power_save on

7.2 Ethernet NIC

ethtool eth0 | grep Wake-on

Example of output:

Wake-on: g

• g = wake on MagicPacket
• If unneeded, disable:

sudo ethtool -s eth0 wol d

8. Battery & Sensors

Check battery reporting:

cat /sys/class/power_supply/BAT0/status
cat /sys/class/power_supply/BAT0/capacity

• status = Charging/Discharging
• capacity = % charge

Check thermal zones:

for t in /sys/class/thermal/thermal_zone*/temp; do
  echo $t: $(($(cat $t)/1000))°C
done

Ensure temps drop after suspend. If not → device not powered down.

9. Logging & Debugging

Enable kernel PM debug:

sudo dmesg -w | grep -i "PM:"

Suspend again and watch logs.

For systemd-specific events:

journalctl -u systemd-logind

Enable deep debug if stuck:

echo 8 > /proc/sys/kernel/printk

10. Automated Validation Script

A one-liner test script:

#!/bin/bash
for i in {1..3}; do
  echo "=== Cycle $i ==="
  rtcwake -m mem -s 10
  journalctl --since "5 minutes ago" | grep -i "PM:"
done

• Uses rtcwake to suspend & auto-wake.
• Captures log entries for each cycle.

11. Pass/Fail Criteria

✅ Suspend enters S3 (deep)
✅ Resume works repeatedly
✅ No random wake-ups
✅ Devices autosuspend (auto)
✅ GPU and NIC show runtime PM
✅ Battery drain <1–2% per hour in suspend

❌ Stuck GPU runtime active
❌ Fans spinning during suspend
❌ Resume fails after >1 cycle
❌ USB wake triggers unexpectedly

Conclusion

This checklist provides a structured way to validate suspend/resume reliability. By testing repeatedly, inspecting logs, and confirming runtime PM states, you ensure Linux uses true low-power modes instead of draining battery silently.

If a device misbehaves, isolate it, disable wake, or override ACPI. By the end, you’ll know exactly whether your laptop is really sleeping — or just pretending.