https://bugs.kde.org/show_bug.cgi?id=526518
--- Comment #1 from [email protected] --- Follow-up (Oct 8): three more incidents, live mid-stall forensics, and a silent variant Since reporting, I've reproduced this class of failure three more times on the same machine (kwin_wayland 6.7.5-1, Arch, HawkPoint 780M DCN 3.1.4, eDP 1920x1200@144 + VRR Automatic; Oct 1 incident on 7.2.7-arch1-1, Oct 8 incidents on 7.2.9-arch1-1). The new data both corroborates and narrows the original report. Most importantly: the signature log lines are sufficient but not necessary — two of the three new incidents had identical user-visible symptoms with zero kwin/drm/amdgpu journal output. Incident log 1. Oct 8 ~09:16 BST: full host freeze (screen corruption, then dead; required hard reset). Preceding activity: screencast screenshot + 16G QEMU window. Journal ends with Spectacle/systemmonitor activity; no OOM, GPU fault, lockup, or panic anywhere in the boot. 2. Oct 8 ~09:29–09:40: present stall (few-fps screen updates, multi-second freezes), input fully working. Trigger: screenshot during QEMU session. No journal signature. Cleared only by mode switch to 60Hz. 3. Oct 8 10:00:51–10:02:11: hard wedge (multi-second input leaps; in-session hotkey did not get through; recovered via TTY + mode reset to 60Hz/VRR-off). Trigger: native Vulkan XWayland app (NoGraphicsAPI example_skate) + 4K60 YouTube + repeated F11 fullscreen toggles (the example does real _NET_WM_STATE_FULLSCREEN toggles, i.e. KWin DRM mode switches). iGPU was saturated at 98–99% throughout (sampled every 2s). No journal signature. 4. Oct 8 ~10:44–10:5x: present stall again (few-fps updates, 9s freeze, input perfect). Trigger: screenshot during QEMU session. Full live forensics below. No journal signature. Live mid-stall forensics (incident 4, sampled while wedged) • kwin_wayland: STAT Sl, wchan - (running, not in any wait), flat ~12.6% CPU — identical to its healthy baseline. Not main-thread-blocked this time. • Xwayland: idle in do_epoll_wait. spectacle: idle in poll. • gpu_busy_percent: 3%. Load ~3.5 on a mostly-idle box. 20/30G RAM, swap untouched, zero CPU/IO pressure. • /sys/kernel/debug/dri/1/state (captured mid-stall, full text available on request): crtc-0 active at 1920x1200@144, self_refresh_active=0, connector self_refresh_aware=0 (PSR not in play); planes sane (kwin AR30 primary + 256px cursor, no overlays/direct scanout). Nothing anomalous in committed state. • dmesg: nothing amdgpu/drm-related (one unrelated clocksource: Watchdog remote CPU 10 read timed out from 09:43, single occurrence). Mid-stall elimination series (incident 4, in order, stall persisted through each until the last) 1. VRR Automatic → Never (144Hz kept): no change. VRR is not sustaining it. 2. Killed spectacle (the trigger): no change. The capture act triggers; its continued presence is not required. 3. Killed the 16G QEMU guest (210% CPU SHM present load): no change. Not load-sustained. 4. Mode switch 144 → 60Hz: cleared instantly. Third time a CRTC reprogram is the only thing that clears it (incidents 2, 3 via TTY, 4). What does NOT reproduce (exonerations) • An 87fps software SHM client (QEMU std-VGA window) + 4K60 video + screenshots + fullscreen toggles, 100+ toggle cycles across scripted runs: clean every time. A modesetting native client seems required; SHM present load alone never trips it. • Note for repro design: metronomic auto-toggles (every 3.0s, 80 cycles) stayed clean while irregular manual toggling wedged — the race window may phase-lock away from periodic triggers. Randomize toggle intervals. Updated repro recipe (best hit rate so far: ~1 wedge per 20–100 toggles) 1. 144Hz + VRR Automatic (required config; 60Hz never trips). 2. Native Vulkan/GL app with real fullscreen modesets (I used NoGraphicsAPI example_skate, XWayland/XCB, F11 toggle) + 4K60 YouTube + active input (each input event appears to add commit rolls; all wedges happened during input). 3. Toggle fullscreen repeatedly with irregular timing. Saturate the iGPU if possible (the hard wedge happened at 98–99% gpu_busy). Severity notes • Full wedges defeat in-session recovery: a Ctrl+Alt+Y global hotkey bound to a mode-reset script did not fire (dispatch starved). Recovery required TTY + kscreen-doctor mode reset. Combined with the original SDDM-restart failure, there is currently no in-session escape from the hard variant. • Two distinct flavors observed: (a) Oct 1: loud atomic-denied + input starvation; (b) Oct 8 incidents 2/4: silent, input perfect, present dying. Possibly the same root at different failure points, or neighboring bugs. Hypothesis for maintainers Net of the eliminations (not VRR state, not PSR, not load, not main-thread block, sane committed DRM state, cleared only by reprogram), my leading suspicion is DCN scanout starvation/underflow at 144Hz or a never-signaling fence in the present path that only a CRTC reprogram drops. Questions: (1) is the atomic-commit error path rate-limited anywhere (could the "silent" variant be gagged logging)? (2) which underflow/fence counters would confirm — I'll capture amdgpu_dm_underflow + full dmesg mid-stall on the next incident if you name what's useful. I have the full mid-stall /sys/kernel/debug/dri/1/state and 2s-cadence gpu/kwin/load traces around all incidents — happy to attach whatever helps. -- You are receiving this mail because: You are watching all bug changes.
