I'm effected by this issue. I have the luxury of owning two GPUs. So can confirm this issue only happens on AMD GPU and never saw this when I swapped with Nvidia GPU on the same machine. I'm posting logs/analysis done by taking help from LLM.
------------------------------------- Same user-visible symptom here on a **different ASIC**: Radeon RX 7900 XT, **Navi 31** (`1002:744C`, subsys `1849:5308`, rev cc) at `0000:03:00.0`, Display Core v3.2.369 on DCN 3.2. Linux Mint 22.3 (noble base), X11/Cinnamon, two 4K60 displays on DP + HDMI, no VRR. Reproduces on both **7.0.0-28** and **7.0.0-30**. I had a capture hook in `/usr/lib/systemd/system-shutdown/` that runs sysrq-w *after* `systemd-journald` has stopped — the window where this hang happens and where nothing normally gets logged. It caught the blocked task on three separate occasions. **The shutdown is not wedged in amdgpu's teardown. It is wedged in DRM's fbdev emulation, waiting for a vblank that can no longer arrive.** ``` task:kworker/4:2 state:D stack:0 pid:432160 tgid:432160 ppid:2 Workqueue: events drm_fb_helper_damage_work Call Trace: <TASK> __schedule+0x2d0/0x660 schedule+0x27/0x90 schedule_timeout+0x85/0x110 ? __pfx_process_timeout+0x10/0x10 drm_crtc_wait_one_vblank+0x124/0x200 ? __pfx_autoremove_wake_function+0x10/0x10 drm_client_modeset_wait_for_vblank+0x61/0x80 drm_fb_helper_damage_work+0x8c/0x1a0 process_one_work+0x1af/0x430 worker_thread+0x1bf/0x350 kthread+0xfb/0x140 ret_from_fork+0x1f8/0x2b0 ret_from_fork_asm+0x1a/0x30 </TASK> ``` Kernel reported `Not tainted`, stock configuration, `7.0.0-28-generic #28~24.04.1-Ubuntu`. A second capture caught the same worker blocked one frame deeper, inside amdgpu's atomic commit rather than in the vblank helper: ``` Workqueue: events drm_fb_helper_damage_work drm_atomic_helper_wait_for_flip_done+0x4d/0xb0 amdgpu_dm_atomic_commit_tail+0xbe1/0xda0 [amdgpu] commit_tail+0xc9/0x1b0 drm_atomic_helper_commit+0x132/0x160 drm_atomic_commit+0xaf/0xf0 drm_atomic_helper_dirtyfb+0x1a1/0x290 ``` ## The sequence On this hardware the shutdown journal shows, in this order every time: ``` 18:33:22 kernel: fbcon: Taking over console 18:33:22 kernel: Console: switching to colour frame buffer device 240x67 18:33:23 kernel: amdgpu 0000:03:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data ... repeated ~9 times over 2 s ... 18:33:25 systemd-shutdown[1]: Syncing filesystems and block devices. 18:33:25 systemd-journald[310]: Received SIGTERM from PID 1 ``` Then journald exits and the machine wedges. 1. Xorg exits, `graphical.target` stops. 2. ~1 s later DMCUB (the display microcontroller) stops responding. 3. With DMCUB dead, vblank interrupts stop arriving. 4. fbcon takes over the console and queues damage work to flush console text. 5. `drm_fb_helper_damage_work` blocks forever in `drm_crtc_wait_one_vblank`. 6. The shutdown path never completes — GPU stays powered, fans ramp to full. ## This explains why `nomodeset` works for you `nomodeset` means no DRM fbdev emulation, therefore no damage worker, therefore no vblank wait. It removes the thing that blocks, not the thing that breaks. That is consistent with your 5/5 result and, I think, good evidence the two reports are the same bug on two different Navi parts. ## There is a posted upstream fix **"drm/fb-helper: Fix vblank timeout during suspend/reset"** — Chengjun Yao, from Aurabindo Pillai, amd-gfx, 2025-12-15: <http://www.mail-archive.com/amd- [email protected]/msg133913.html> `Fixes: d8c4bddcd8bc ("drm/fb-helper: Synchronize dirty worker with vblank")` It makes two changes in `drivers/gpu/drm/drm_fb_helper.c`: - `drm_fb_helper_damage_work()` returns early if `helper->info->state != FBINFO_STATE_RUNNING` - `drm_fb_helper_set_suspend_unlocked()` calls `cancel_work_sync(&fb_helper->damage_work)` before `console_lock()` The patch was written against a suspend/reset reproducer on an RX 7900 series dGPU. The shutdown path hits the same wait. It is not present in 7.0.0-30 — the symbols are unchanged and the kernel changelog doesn't mention fb-helper or vblank. ## Reproducer: session length, not luck This looked random for two weeks until I checked it against uptime. Across 20 stock-config boots on this card: | Session length before poweroff | Failed | Total | |---|---|---| | >= 3 hours | 8 | 10 | | < 3 hours | 2 | 10 | So: **boot, use the desktop for 3+ hours, then power off.** That should make this far easier to reproduce on demand than "intermittent" suggests. I have no mechanism to offer for why longer sessions matter — offering it purely as a reproducer aid. For what it's worth on the firmware angle: I saw this with two different DMUB blobs (`0x07002F00` and `0x07002A00`, i.e. either side of the linux-firmware 2.27→2.29 change) with no consistent difference in failure rate, and the backtrace is identical on both. I don't think LP #2163303 is related. ## Offer I can test a proposed-kernel or PPA build against the reproducer above and report back. If it would help, I can also reinstall the shutdown capture hook and get a fresh backtrace on 7.0.0-30 specifically — the three above are all from -28. One disclosure so it doesn't surprise anyone later: this machine currently runs an amdgpu `ppfeaturemask` overdrive setting and a small undervolt for daily use. **All data in this comment predates that** — the captures are from an untainted stock kernel and the table above counts only stock-config boots. I'll revert to stock for any verification testing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2162928 Title: [amdgpu][Navi 44] Intermittent poweroff hang on 7.0.0-27/28/29; 7.0.0-22 and nomodeset shut down reliably To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162928/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
