Same symptom on different hardware — RX 9060 XT (RDNA4) Adding a data point from a different GPU generation, since this doesn't appear to be RX 7900 XT/RDNA3-specific.
Hardware: AMD RX 9060 XT / Navi 44 (RDNA4), PCI ID [1002:7590] Kernel: 7.1.2-070102-generic (mainline build, #202606271039 SMP PREEMPT_DYNAMIC, Sat Jun 27 2026) Symptom: Identical "dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us N times" workqueue warnings, recurring across boots. Example from one boot (kernel monotonic timestamps, wall-clock range Jul 11 19:21:52 - Jul 12 00:37:29 — note the count climbs across the boot rather than resetting): [ 370.797119] workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [ 455.037142] workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [ 4037.810198] workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND [ 5131.830194] workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND [19307.125552] workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND Ruled out via systematic testing (12+ hours real usage under all three conditions simultaneously): 1. VRR/FreeSync — confirmed disabled at both the Xorg driver level (VariableRefresh: disabled) and the KWin compositor level (vrrPolicy: Never on both outputs). Warning still fired. 2. DPM/mclk power-state switching — GPU pinned to power_dpm_force_performance_level=high for the entire session (static top pstate, no automatic transitions). Warning still fired. 3. Refresh rate/modeset switching — both monitors static at 3440x1440@60Hz for the whole boot, no modeset or hotplug events in kernel or Xorg logs. Warning still fired. Since all three of the obvious triggers were independently ruled out, this points toward the underlying mechanism rather than any of the usual suspects (adaptive sync, power states, or display timing changes). Looked into the driver code and found dm_handle_vmin_vmax_update is a workqueue handler introduced specifically to offload dc_stream_adjust_vmin_vmax() off the interrupt handler so it can wait on dc_lock instead of racing it (see the amd-gfx patch thread on "fix dmub access race condition"): https://www.mail-archive.com/[email protected]/msg126413.html So the warning itself looks like the race-condition fix's own offload mechanism hitting contention, rather than being triggered by any user-facing setting. Happy to provide full journalctl -k output or test a debug kernel build if that'd help narrow it down further. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2150776 Title: Ubuntu 26.04 GNOME Wayland: random short display/presentation freezes on AMD RX 7900 XT while apps continue running To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150776/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
