---Reproduced again today, this time the stall lasted 73 minutes straight (previous captures were 6-7 minutes), with MUTTER_DEBUG=kms,render,backend and drm.debug=0x1e both active the whole time.
The external monitor's CRTC (145) took its last page-flip at 19:45:59.551585 (sequence 893724) — callback received cleanly, no error of any kind. From that point until 20:59:18, CRTC 145 received zero primary-plane commits, zero page-flip requests, and zero damage-clip updates. The only line still appearing for that CRTC during the stall is "KMS: Realizing HW cursor for cursor sprite for CRTC 145" (945 times) — mutter keeps moving the hardware cursor sprite but never resubmits a frame. Meanwhile CRTC 88 (internal panel) kept flipping continuously the entire time (page-flip sequence climbed from 893819 to 1160219), so the gnome-shell process and its KMS thread were never blocked — this is isolated to the frame-scheduling of one output's stage-view. Recovered with Ctrl+Alt+F2 then Ctrl+Alt+F3. That VT cycle forces mutter to fully close and reopen both DRM device files and recreate its KMS thread, then re-read CRTC state straight from the kernel: KMS: Read CRTC 145 state: active: 1, mode: 3840x2160, changed: no "changed: no" is the interesting part — the kernel/hardware side considered CRTC 145 correctly active with the right mode the entire time. So this isn't a lost commit or a kernel-side fault; it's mutter's own repaint/frame-clock scheduling for that stage-view that stopped submitting new frames, and only a full backend teardown+reinit clears it. Attached log.zip with two files: - mutter-freeze-2026-08-17-excerpt.txt: a compact, curated excerpt with the last healthy commits before the stall, a heartbeat sample of CRTC 88 proving liveness throughout, and the full recovery sequence. - journal-2026-08-17.txt.gz: the complete unfiltered journalctl for this window (19:44-21:00, ~76 min, 3.1MB gzipped) in case the raw data is useful. Re: "Alt+F2 > lg > Flags > DISABLE_DIRECT_SCANOUT" — since that toggle only lives for the current session (resets on logout/crash) and I want this running unattended for several days, I'll use the equivalent persistent env var instead: MUTTER_DEBUG_PAINT=disable-direct-scanout (same underlying flag, META_DEBUG_PAINT_DISABLE_DIRECT_SCANOUT in src/core/util.c) set in /etc/environment, alongside the current MUTTER_DEBUG=kms,render,backend logging. Will report back whether it prevents the stall from recurring — if it does, that points pretty squarely at the direct-scanout path as the trigger. ** Attachment added: "log.zip" https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2162087/+attachment/5992876/+files/log.zip -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2162087 Title: External monitor freezes completely (incl. cursor) on Meteor Lake iGPU, audio continues To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2162087/+subscriptions -- desktop-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
