Before changing anything: save work and keep a recovery route available. Suspend problems can have multiple causes. These commands investigate, rather than prescribe a hardware-specific fix.
1. Identify the symptom
- Immediate wake: suspend begins but the PC wakes seconds later. A device wake event may be responsible.
- Black screen: fans or keyboard wake but no picture returns. Graphics, firmware and device drivers may be involved.
- Sleep refused: an inhibitor, service or kernel problem may be blocking the transition.
2. Collect evidence first
Check available sleep modes and inspect current-boot kernel and systemd logs:
cat /sys/power/mem_sleep
systemctl status suspend.target
journalctl -b -k --no-pager | tail -n 150
journalctl -b -u systemd-suspend.service --no-pagerThe active sleep mode appears in square brackets. Following a restart, the previous boot's journal may be available via journalctl -b -1, provided persistent logging is configured.
3. Investigate wake-capable devices
Many ACPI systems expose possible wake sources with:
cat /proc/acpi/wakeupEntries marked *enabled can include USB controllers, network interfaces and PCIe bridges. The list is a starting point, not proof that a device caused an unwanted wake. Record the state before experimenting: writing a device label into this interface toggles it, so blindly repeating a command can undo the change.
4. Check graphics-driver integration
If the system wakes but the display remains black, look for driver errors and failures around the precise suspend time. On NVIDIA-equipped systems:
nvidia-smi
modinfo nvidia | head
systemctl status nvidia-suspend.service
systemctl status nvidia-resume.service
journalctl -b -u nvidia-suspend.service \
-u nvidia-resume.service --no-pagerA service being invoked does not necessarily mean it caused a failure. Correlate timestamps and error messages. Avoid mixing driver versions or installing unrelated CUDA packages as a first response.
5. Work through one change at a time
- Reproduce and accurately describe the symptom.
- Save logs from the relevant boot.
- Record motherboard firmware, kernel and driver versions.
- Test one reversible configuration change, then retest.
- Keep notes on what actually improved or worsened the result.
Safety: firmware changes, kernel parameters and privileged commands may cause further problems. Back up important data and establish a rollback route before applying them.
Need a hand?
Get in touch with Techesque. Remove usernames, addresses, tokens and other private details before sharing logs.