Corroborating comment #4: the same missing backport also causes an
intermittent **s2idle resume hang** here, not only the poweroff
deadlock. jsx reported the same on a ThinkPad P14s Gen 7 AMD on
7.0.0-31; this adds a third platform, with a measured failure rate, a
reproducer and a mitigation that works.
## Hardware and kernel
```
Framework Laptop 13 (AMD Ryzen AI 300 Series), BIOS 04.02
AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1ah model 24)
linux-image-7.0.0-31-generic 7.0.0-31.31~24.04.1 (linux-generic-hwe-24.04)
Ubuntu 24.04 LTS base (Linux Mint 22.3)
/sys/power/mem_sleep = [s2idle] only — no S3 on this platform
```
ISM symbols confirmed present in the running 7.0.0-31 kernel, same check
as comment #0:
```
$ grep -oE "amdgpu_dm_ism[a-z_]*" /proc/kallsyms | sort -u
amdgpu_dm_ism_commit
amdgpu_dm_ism_commit_event
amdgpu_dm_ism_disable
amdgpu_dm_ism_enable
amdgpu_dm_ism_event
amdgpu_dm_ism_fini
amdgpu_dm_ism_init
```
## Symptom
Resume from s2idle intermittently never completes. The machine wedges
silently — no response to lid, keyboard or a short power press; only a
long power press recovers it. Left alone it runs the battery flat. No
panic, nothing in `/sys/fs/pstore` or `/var/crash`.
The journal ends mid-suspend, with no resume and no shutdown sequence:
```
kernel: PM: suspend entry (s2idle)
<log ends — no "PM: suspend exit">
```
There is no on-disk evidence from the failing cycle: journald is frozen
because the disk is already suspended.
## Reproducer
`amd-s2idle` from amd-debug-tools, **undocked and on battery** — the
hang has never been observed here while docked or on AC:
```
sudo amd-s2idle test --count 30 --duration 20 --wait 10
```
Do not pass `--logind`; it requires python-dbus and aborts with an
unrelated `UnboundLocalError`.
## Failure rate
```
stock cmdline 18 cycles 2 hangs ~11%
```
## Mitigation that works here
Booting with `no_console_suspend` has so far prevented it:
```
no_console_suspend 100 cycles 0 hangs
stock 18 cycles 2 hangs
```
The 100 clean cycles span three runs and both console owners — 70 from a
VT, 30 from the running X session (`tty7` active, zero VT switches in
that boot) — so it is not an artifact of testing from a text console.
This is an observation, not proof. Bugzilla 221694 comment 4 notes the
deadlock needs an ISM worker in flight at suspend time and can hide
behind long runs of good cycles (7.1.3 there wedged only on cycle 28 of
30), so cycles are not independent trials and a p-value on 0/100 would
overstate it. Offered as a mitigation for anyone stuck on an affected
kernel, and because it is at least consistent with the root cause:
`no_console_suspend` keeps the console and framebuffer alive across
suspend, altering the display suspend sequence.
Worth noting this mitigation does **not** appear in bugzilla 221694,
where `no_console_suspend` is mentioned only as an offered capture
technique.
## Upstream verification of the fix
Bugzilla 221694 tracked the same deadlock as an s2idle resume hang on
the same SoC (Ryzen AI 9 HX 370 / Radeon 890M) and is RESOLVED. Comment
4 there gives a per-kernel matrix:
```
6.18.x clean 30/30 predates ISM (754003486c3c)
7.0.13 clean 30/30 predates ISM
7.1.1 wedged 5/30
7.1.3 wedged 28/30
7.1.6 clean 30/30 ISM present + fix present
```
The fix is stable commit 95776812e6b8 ("drm/amd/display: Fix ISM dc_lock
deadlock during suspend", upstream 3714fe242592). It is in 7.1.6 and not
in 7.1.4 or 7.1.5.
So the backport requested in this bug is verified upstream to close the
suspend-side failure as well, not only the poweroff one.
## Ruled out locally
- **mt7925e.** This machine has the MT7925 (14c3:0717) that is a known suspend
offender elsewhere, but that defect logs loudly and aborts the suspend
(`Message ... timeout`, `PM: Some devices failed to suspend`, -110) leaving the
machine up. Zero occurrences of either string in the entire journal here; WM
firmware build 20260605. Bugzilla 221694 also ruled it out by unloading the
module across suspend.
- **Thunderbolt dock.** Every observed hang was undocked, with WiFi as the
default route at suspend and no thunderbolt events.
- **Userspace sleep hooks.** The missing `PM: suspend exit` puts the hang in
kernel space, before userspace regains control.
- **Parallel device suspend.** 20 cycles with `pm_async=1` under the working
configuration: no hang. Serialising device suspend is not what helps.
- **printk volume.** `ignore_loglevel`, `pm_debug_messages` and
`pm_print_times` are not needed; `no_console_suspend` alone is sufficient.
## Supporting the backport request
Confirming 7.0.0-31 is affected, and that the impact is wider than
poweroff: on this hardware it costs an unrecoverable hang and a flat
battery on a routine lid-close suspend.
The fix also does not appear in the changelog of the current newest
upload, `linux-hwe-7.0 7.0.0-38.38~24.04.4` (2026-09-14) — searched for
`ISM`, `dc_lock`, `Idle state manager` and the fix subject — so waiting
for the next SRU will not resolve this on its own.
Please backport 3714fe242592 to linux-hwe-7.0.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166940
Title:
[regression] poweroff deadlocks in amdgpu_dm_ism_disable() — ISM
backport is missing upstream fix 3714fe2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-7.0/+bug/2166940/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
