A device callback aborts system suspend · Linux Fix Lab

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.

Kernel staged suspend debugging (project or distribution documentation)
Suspend and device interrupt semantics (project or distribution documentation)

Related hardware and driver context

These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.

Identify hardware locally