Dennis HilkLinux Fix LabDE

Kernel & System Stability

A device callback aborts system suspend

Suspend can fail before entering a sleep state when a device callback rejects it; use the first PM error to separate rejection from wakeup.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • The suspend request returns to the running session immediately.
  • PM messages name a failing device or asynchronous suspend error.

Relevant environment

Linux system suspend through the kernel PM framework; this entry covers device suspend rejection rather than a compositor-only black screen.

Recognizable messages (synthetic examples)
usb 1-2: PM: failed to suspend async: error -16

Find the earlier driver-specific error and device address; the aggregate failure alone does not explain whether a driver or firmware blocked transition.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A driver may be unable to quiesce its device or requires missing integration.
  • A platform or device firmware regression may reject transition; a successfully entered state followed by wake is a different path.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read transition stages and callbacks, with administrator journal access when needed.

journalctl -b -k --no-pager --grep='PM:|suspend|dpm_run_callback'

Interpret the result: Identify the first device error before PM reports the aggregate failure. suspend entry followed by an error is not proof that hardware reached sleep.

Check 2

Read supported suspend-to-memory variants; brackets mark the current selection. This does not initiate sleep.

cat /sys/power/mem_sleep

Interpret the result: Only modes listed by this kernel/platform are available. The current mode can guide comparison, but changing it will not automatically repair a failing device callback.

Evidence-guided next steps

Isolate the optional failing device

If the first PM error identifies an optional USB peripheral or its workload, safely stop the workload and disconnect that peripheral before a controlled suspend test. Do not unload essential drivers merely to follow the last error line.

Precautions: Save work, unmount removable storage normally and test on local access. A remote-only sleep test can leave recovery unavailable.

Recovery / rollback: Reconnect the peripheral and restore its workload when ready; keep it disconnected if it reproducibly blocks suspend until a supported fix exists.

Did this solution help you?

Share this solution#

Correct the identified driver’s PM integration

If the failing driver documents required sleep hooks or a matching bug fix, align its distribution integration or compare the supported fixed kernel. Advanced staged pm_test work belongs in a planned local diagnostic session with the kernel guide.

Precautions: Do not leave pm_test active accidentally or disable all wakeup sources. A staged test can still hang and should not run with unsaved work.

Recovery / rollback: Restore the previous driver package/boot entry and any recorded sleep settings; return pm_test to none if a guided test changed it.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.