https://bugs.kde.org/show_bug.cgi?id=522891
Bug ID: 522891
Summary: kwin_wayland enters infinite wl_display.sync busy-loop
and never presents on nvidia-open DRM backend
(permanent black screen)
Classification: Plasma
Product: kwin
Version First 6.7.2
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-drm
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
On a system with an NVIDIA RTX 4060 (AD107) using the nvidia-open kernel
module, starting a Plasma Wayland session results in a permanently black
screen. kwin_wayland does not crash and does not log a fatal error in most
cases -- instead its main thread enters what appears to be an infinite
wl_display.sync request/reply busy-loop, confirmed via strace, pegging one CPU
core at ~85-90% indefinitely with no forward progress. The session never
presents a frame and must be killed/restarted externally.
STEPS TO REPRODUCE
1. From SDDM, select "Plasma (Wayland)" and log in.
2. Session starts (kwin_wayland launches, DRM backend selected automatically).
3. Screen stays black indefinitely. No crash occurs.
OBSERVED RESULT
Permanent black screen, kwin_wayland process alive but pegging ~85-90% CPU on
one core, no frame ever presented.
EXPECTED RESULT
Wayland session starts normally (same output works fine under the X11
plasmax11.desktop session at the same resolution/refresh rate with the same
forced EDID).
ENVIRONMENT
- Plasma: 6.7.2 (plasmashell 6.7.2, kwin 6.7.2)
- GPU: NVIDIA GeForce RTX 4060 (AD107) [10de:2882]
- Driver: nvidia-open-dkms 610.43.03 (NVIDIA Open Kernel Module,
nvidia_drm.modeset=1)
- Kernels tested (bug reproduces on both):
- linux-xanmod 7.1.3-x64v3-xanmod1
- linux (stock Arch) 7.1.3.arch1-1
- Display manager: SDDM, plasma.desktop (Wayland) session
- Output: single monitor over HDMI, native mode 2560x1600, EDID advertises both
60Hz (268.45MHz pixel clock) and 100Hz (447.44MHz pixel clock) DTDs
- Distro: Arch Linux
WHAT WE RULED OUT BEFORE FINDING THE ACTUAL BUG
- Refresh rate / bandwidth: reproduces identically at both 2560x1600@60Hz and
2560x1600@100Hz.
- EDID content: this system uses drm.edid_firmware= to force a copy of the
monitor's own EDID (for resilience when physically disconnected). Confirmed
byte-for-byte identical to the live DDC-read EDID when booted without the
kernel override -- ruled out EDID corruption/mismatch.
- Atomic vs legacy modesetting: setting KWIN_DRM_NO_AMS=1 does not fix it -- it
changes the failure signature (see below) but the session still never presents.
- Kernel/xanmod-specific patches: reproduces identically on stock Arch linux
7.1.3.arch1-1, not just the xanmod kernel.
- x11vnc interference: stopping an unrelated x11vnc.service running on this
system made no difference.
OBSERVED FAILURE SIGNATURES (vary by run, same underlying issue)
In most attempts, kwin logs (with default logging):
kwin_wayland: No backend specified, automatically choosing drm
kwin_wayland: Failed to find a working output layer configuration! Enabled
layers:
kwin_wayland: src KWin::RectF(0,0 2560x1600) -> dst KWin::Rect(0,0 2560x1600)
kwin_wayland: Applying output configuration failed!
(repeats every ~10-15s)
With KWIN_DRM_NO_AMS=1 set, this specific message disappears, and instead:
kwin_wayland: drmModeAddFB2WithModifiers is supported on GPU "/dev/dri/card1"
...
kwin_wayland: Could not create udmabuf: Invalid argument
(repeated 8+ times in quick succession before the session was externally
killed)
In the run where we captured the strace evidence below, kwin logged nothing
further after normal startup (no output-configuration-failed message at all) --
it simply never made progress.
LIVE PROCESS EVIDENCE (the actual bug)
While the screen was black, kwin_wayland's main thread was confirmed alive and
NOT blocked/hung in the kernel-wait sense -- it was actively running:
$ ps -o pid,stat,pcpu,etimes -p <kwin_wayland pid>
PID STAT %CPU ELAPSED
9348 Rl 87.7 127
(%CPU, as reported by ps, climbed steadily from ~50% to ~88% over the first 60
seconds and kept climbing -- consistent with a tight loop pegging a single
core, not idle/blocked behavior)
/proc/<pid>/stat showed stime (kernel time) roughly double utime (user time),
suggesting the loop is dominated by syscall overhead rather than userspace
computation.
strace -p <pid> (as root) shows the main thread repeating this exact sequence
continuously, roughly every 20 microseconds (~40-50k iterations/sec):
recvmsg(140, ...) = 12 # wl_display.sync request: obj=1, opcode=0,
size=12, arg=<new_id>
recvmsg(140, ...) = -1 EAGAIN
recvmsg(144, ...) = 12 # same message on a second fd
recvmsg(144, ...) = -1 EAGAIN
sendmsg(140, ...) = 24 # reply sent
sendmsg(144, ...) = 24 # reply sent
ppoll([13 fds], 13, {tv_sec=568, ...}, NULL, 8) = 1 ([{fd=57, revents=POLLIN}],
...) # returns essentially instantly
epoll_wait(57, ...) = 2 # returns essentially instantly
# loop repeats indefinitely
The ppoll call is passed a long timeout (~568s) but returns immediately every
time because fd 57 is already readable -- i.e. something is continuously
re-arming readiness on that fd rather than the loop properly waiting/backing
off. This looks like a synchronous roundtrip (wl_display_roundtrip()-style
busy-wait) being used to poll for some condition -- plausibly
output-configuration success, or the DRM commit result -- that never resolves,
so the wait loops forever instead of timing out or surfacing an error.
IMPACT
Session is unusable (permanent black screen) and must be killed from outside
(e.g. systemctl restart sddm) -- there is no way to recover or switch back to
X11 from within the hung session, and no crash/log signal indicates what's
wrong without external process-level inspection.
ADDITIONAL NOTES
- This same monitor/output works correctly under the X11 (plasmax11.desktop)
session at the same resolution/refresh rate with the same forced EDID.
- Happy to provide a full strace -f -tt capture, journalctl output, or test
further kernel/driver combinations if useful.
--
You are receiving this mail because:
You are watching all bug changes.
