Dear Maintainer, Summary ------- After the laptop suspends and is later woken while sitting at the GDM lock screen, GDM's own compositor process (the one rendering the lock/greeter UI, distinct from the already-running user session) intermittently crashes during the resume sequence. Xwayland loses its connection and, since it is marked mandatory for that session, Mutter terminates the whole context. GDM respawns the greeter, but there is a window where the stale lock screen frame remains visible while the user's real session has already resumed underneath it -- producing audible/network activity (background app notification sound, Wi-Fi reconnect) while the screen still shows the lock prompt and does not visibly respond to the just-entered correct password until the new greeter instance catches up. This is a UI/compositor desync, not a security bypass: the session was correctly gated by PAM/logind throughout; only the on-screen redraw of the dying/respawning GDM greeter failed to keep up. What led up to the situation ----------------------------- Screen was locked (idle timeout), laptop suspended shortly after, then was woken. Password was entered at the lock screen immediately upon resume. What exactly did you do ------------------------ Typed the correct unlock password and pressed Enter right as the display came back from suspend. What was the outcome --------------------- The lock screen prompt remained on screen and did not visibly react, while the system was clearly already active underneath (notification sound from a background browser tab, Wi-Fi reconnecting). It resolved itself after a few seconds without further input. What outcome did you expect instead ------------------------------------- The lock screen should dismiss promptly and consistently once the password is accepted, with no visible gap between the session unlocking and the screen reflecting that. Timeline of one captured occurrence (2026-09-06, local time) --------------------------------------------------------------- Suspend triggered while system was locked: Sep 06 11:22:31 k NetworkManager[953]: <info> device (wlp1s0): state change: activated -> deactivating (reason 'sleeping', ...) Resume begins; kernel reinitializes the GPU: [Sun Sep 6 11:23:06 2026] Spectre V2 : Enabling Speculation Barrier for firmware calls [Sun Sep 6 11:23:10 2026] amdgpu 0000:03:00.0: amdgpu: MODE2 reset [Sun Sep 6 11:23:10 2026] [drm] Loading DMUB firmware via PSP: version=0x0101002B Wi-Fi driver reinitializes and NetworkManager reassociates (NetworkManager also reappeared under a new PID, 936 vs. the pre-suspend 953 -- noted here in case it's a separate but related resume-time disruption): [Sun Sep 6 11:23:13 2026] iwlwifi 0000:01:00.0: loaded firmware version 77.2753b721.0 cc-a0-77.ucode op_mode iwlmvm [Sun Sep 6 11:23:13 2026] iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0 Sep 06 11:23:13 k NetworkManager[936]: <info> device (wlp1s0): driver supports Access Point (AP) mode Sep 06 11:23:18 k NetworkManager[936]: <info> device (wlp1s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "zz9" Sep 06 11:23:20 k NetworkManager[936]: <info> dhcp6 (wlp1s0): state changed new lease GDM's own lock-screen compositor (gnome-shell, PID 1659, running as the gdm user -- note the /var/lib/gdm3/.config/mutter/sessions/ path) fails to restore its saved session state, then loses Xwayland 8 seconds later and terminates: Sep 06 11:23:21 k gnome-shell[1659]: Failed to parse saved session file: Failed to open file "/var/lib/gdm3/.config/mutter/sessions/10aa9ef2b4d8b3c1541788673..." Sep 06 11:23:29 k gnome-shell[1659]: Connection to xwayland lost Sep 06 11:23:29 k gnome-shell[1659]: Xwayland terminated, exiting since it was mandatory Sep 06 11:23:29 k gnome-shell[1659]: (../src/core/meta-context.c:597):meta_context_terminate: runtime check failed: (g_main_loop_is_running (priv->main_loop)) The unlock password was typed at approximately this point; it was accepted at the logind/PAM level (hence audible/network activity from the real session) while the visual lock prompt, rendered by the crashing/ respawning greeter compositor, lagged behind. Steps to reproduce (best effort -- timing-dependent, not 100% reliable) --------------------------------------------------------------------------- 1. On a GNOME 48 Wayland session on an AMD Renoir (Ryzen 4000-series integrated Vega) laptop, lock the screen (or let idle timeout lock it). 2. Let the system suspend (idle or lid-close). 3. Wake the system and, as soon as the display comes back, immediately type the correct password and press Enter. 4. Occasionally (not every time), the lock prompt remains on screen for a few seconds while the session is audibly/network-visibly already active underneath. It resolves itself after a few seconds without further input. Relevant related upstream/downstream reports ----------------------------------------------- - Ubuntu mutter bug tracking the same three-line signature (Connection to xwayland lost / Xwayland terminated, exiting since it was mandatory / meta_context_terminate: runtime check failed), tagged [amdgpu], occurring around screen lock/blank: https://bugs.launchpad.net/bugs/2034619 - Ubuntu xwayland bug tracking the same signature more generally, noting a partial fix landed in Xwayland >= 23.2.4 (this system is on 24.1.6, so this appears to be a distinct/still-open recurrence rather than the already-patched case): https://bugs.launchpad.net/bugs/2054873 What would help most ----------------------- - Confirming whether other AMD Renoir/Vega-integrated laptop users on trixie see the same MODE2-reset-adjacent Xwayland crash on resume. - coredumpctl output if a core is available for the crashed gnome-shell (gdm) instance. - Whether MUTTER_DEBUG_KMS_THREAD_TYPE=user (mentioned as a workaround for a related real-time-thread SIGKILL issue in the Ubuntu thread above) changes reproducibility.