Public bug reported:
[Impact]
On Ubuntu 24.04, gnome-shell can be killed with SIGKILL about 0.7
seconds after a Wayland session starts. The password is accepted, then
GDM returns to the login screen. No core dump is written, and the
journal does not name the sender of the signal.
Mutter makes its KMS thread real-time through rtkit and sets
RLIMIT_RTTIME, soft and hard, to rtkit's RTTimeUSecMax (200 ms here).
Mutter 46.2 inhibits real-time scheduling around hotplug state reads and
mode sets, but not during the initial probe in
meta_kms_impl_device_init_mode_setting(). If the driver holds the CPU
past the limit during that probe, the kernel kills the process.
Upstream fixed this in "kms: Inhibit real time scheduling until initial
mode set". From the commit message:
We're already inhibiting real time scheduling when reading new KMS state
after hot plugs, as well as when during mode sets, due to the kernel not
being able to reliably handle these within the 250 ms limit. However, we
didn't do this during initial probing, which meant that occasionally
we'd run into these kind of issues during startup.
Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3628
Merge request: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3960
main: d2be0b6950104dce8a17574bf43837eb57660b3e
gnome-46: abd2c95864d756ea0a790f748bada2bae7a58c2a (first released in 46.5)
Noble carries 46.2 plus its own patch series, and 46.2-1ubuntu0.24.04.18
does not include this commit. Please backport it to noble.
On this system, 6 of 8 Wayland starts from 2026-08-26 to 2026-11-03 were
killed this way, including 5 in a row on 2026-11-03.
[Test Plan]
This needs a system whose initial probe takes longer than the limit. An
NVIDIA GPU with a monitor that logs "Failed to initialize G-SYNC" is one
such case.
1. With the current package, log in to "Ubuntu on Wayland" several times.
Failed attempts return to the login screen and log:
[email protected]: Main process exited, code=killed,
status=9/KILL
2. Install the package from -proposed and reboot. Make sure
MUTTER_DEBUG_KMS_THREAD_TYPE is not set.
3. Log in to "Ubuntu on Wayland" 10 times. Every login should reach the
desktop, with no line like the one above.
4. In the journal, rtkit-daemon's RT grant for gnome-shell's KMS thread should
come after the "Added device" lines.
5. After startup, the KMS thread should be real-time. The class in this output
should be RR:
ps -L -o tid,cls,rtprio,comm -p "$(pgrep -u "$USER" -x gnome-shell)" | grep
-i kms
6. Regression checks: unplug and replug a monitor, suspend and resume, switch
VT and back, and change the display configuration in Settings. Repeat on a
single-GPU system without the slow probe.
[Where problems could occur]
The patch changes when the KMS thread becomes real-time. It adds an
inhibit that must be released after the first mode set on every device
found at startup.
- If the inhibit is never released, the KMS thread stays non-real-time for the
whole session. Mutter's deadline timer depends on real-time scheduling, so
cursor and frame timing could get worse.
- If it is released too early, the current kill remains possible.
- Systems with several GPUs go through this code once per device, and devices
with no CRTCs have their own branch, so hybrid graphics is worth testing.
In a dry run, the gnome-46 commit applies to the 46.2-1ubuntu0.24.04.18
source with all 68 Ubuntu patches applied, with line offsets and fuzz on
two hunks. I have not built or run it.
[Other Info]
System:
- Ubuntu 24.04.5
- mutter 46.2-1ubuntu0.24.04.18 (also seen on .16)
- kernel 6.8.0-147-generic (also seen on -138 and -139)
- NVIDIA 580.178.04 (also seen on 580.173.02), RTX 2060 SUPER as boot VGA, plus
an AMD integrated GPU (1002:13c0)
- rtkit 0.13-5build1
- ASUS ROG PG27AQN over DisplayPort, through a KVM switch
Journal from a failed start (hostname removed):
10:06:59.501982 gnome-shell[5258]: Running GNOME Shell (using mutter 46.2) as a
Wayland display server
10:06:59.527692 gnome-shell[5258]: Made thread 'KMS thread' realtime scheduled
10:06:59.613497 gnome-shell[5258]: Device '/dev/dri/card2' prefers shadow buffer
10:07:00.236888 kernel: nvidia-modeset: WARNING: GPU:0: Asustek Computer Inc
ROG PG27AQN (DP-2): Failed to initialize G-SYNC
10:07:00.281950 systemd[2447]: [email protected]: Main process
exited, code=killed, status=9/KILL
10:07:00.298552 systemd[2447]: [email protected]: Failed with
result 'signal'.
10:07:00.995348 gdm3[3301]: Gdm: GdmDisplay: Session never registered, failing
Journal from a start that survived the same probe (2 of the 8 did):
16:50:27.208048 gnome-shell[5263]: Made thread 'KMS thread' realtime scheduled
16:50:27.285215 gnome-shell[5263]: Device '/dev/dri/card2' prefers shadow buffer
16:50:28.041710 kernel: nvidia-modeset: WARNING: GPU:0: Asustek Computer Inc
ROG PG27AQN (DP-2): Failed to initialize G-SYNC
16:50:28.067887 gnome-shell[5263]: Added device '/dev/dri/card2' (nvidia-drm)
using atomic mode setting.
The slow probe on this system:
The slow call is NVIDIA's G-SYNC handshake with the monitor. When it
fails, vrrWaitOnEnableStatus() in the driver's DisplayPort library busy-
waits for up to 40 x 15 ms = 600 ms
(src/common/displayport/src/dp_vrr.cpp in open-gpu-kernel-modules). The
startup probe took 30 ms on 2026-08-08, before these warnings first
appeared on 2026-08-24, and 596-756 ms on every start since. The kernel
also logged:
workqueue: nv_drm_handle_hotplug_event [nvidia_drm] hogged CPU for
>10000us 4 times, consider switching to WQ_UNBOUND
The failing handshake is a separate problem, and I have not found its
cause. It makes the probe slow, and the missing Mutter commit turns that
into a login failure.
Evidence for RLIMIT_RTTIME:
I have not captured the kernel's RT watchdog message, which needs
kernel.print_fatal_signals=1 and a failed login. I can do that if it
helps. These point to the limit:
- In all 6 killed starts, the kill was reported 41-57 ms after the G-SYNC
warning.
- systemd reports the result as 'signal', not 'oom-kill'.
- At hotplug, rtkit logs the KMS thread dropping to high priority before the
same slow call and returning to RT after it. At the failed start, it logs only
the RT grant.
- The first login with MUTTER_DEBUG_KMS_THREAD_TYPE=user succeeded after 5
straight failures. That variable removes the real-time thread.
Workaround:
Add a systemd user drop-in at
~/.config/systemd/user/[email protected]/kms-thread-
user.conf, then run systemctl --user daemon-reload:
[Service]
Environment=MUTTER_DEBUG_KMS_THREAD_TYPE=user
The X11 login screen's gnome-shell runs normally on this system, because
Mutter has no KMS thread in X11 mode. Selecting "Ubuntu on Xorg" should
also avoid the kill, though I have not tried it.
Related upstream change:
gnome-46 also has 740d9fb9db "kms: Default to high priority KMS thread
scheduling".
** Affects: mutter (Ubuntu)
Importance: Undecided
Status: New
** Tags: noble nvidia wayland-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172856
Title:
gnome-shell killed by SIGKILL at Wayland login: KMS thread hits
RLIMIT_RTTIME during initial probe (fix in mutter 46.5)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2172856/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
