https://bugs.kde.org/show_bug.cgi?id=523025
--- Comment #2 from Ruslan Yanin <[email protected]> --- Oke, if russian language or ukrainian is not aloowed, i did translate via Claude) # KDE Bug Report — display-manager greeter black screen when amdgpu has no EDID (HDMI-switch on `dark-hero` / plasmalogin; cold boot with monitor off on `x570s-aero-g` / SDDM) > Prepared for submission to **bugs.kde.org**. Collected 2026-07-09 / > 2026-07-10 from two > affected machines. English below — paste directly into the bug tracker. > Кратко по-русски для пользователя: это отчёт про чёрный экран входа (greeter > не рисует, > «сигнал есть, фон чёрный») на двух машинах с одним общим корнем — amdgpu DRM > не может > построить CRTC/режим, когда EDID отсутствует. Триггер A (машина `dark-hero` / > 172.16.0.102, > plasmalogin): HDMI-коммутатор — монитор общим на 2 ПК, кабель не вынимается. > Триггер B > (машина `x570s-aero-g`, SDDM): монитор не включён вовремя после загрузки ОС. > Оба лечатся > перезапуском display-manager без ребута ОС. Заполни поля bugs.kde.org блоками > ниже. --- ## Suggested tracker fields - **Product / Component:** `plasmalogin` (Plasma Login Manager) — if not available as a product yet, file under `plasma-workspace` → `general`, and cross-reference `kscreen` / `ksmserver` / `KWin` for the display hotplug aspect. The root trigger is amdgpu DRM HPD handling + Wayland greeter, so `kscreen` / DRM layer is in scope. - **Severity:** major — machine becomes unusable for login without SSH/console access. - **Version:** 6.7.0 (KDE Neon User Edition, base Ubuntu 24.04 noble) - **Keywords:** plasmalogin, greeter, black-screen, wayland, hotplug, HDMI, KVM-switch, amdgpu, hpd, no-edid, display-manager, sddm, cold-boot, crtc - **Note on scope (two machines, two login managers):** the primary case below is `plasmalogin` on `dark-hero`. A second affected machine, `x570s-aero-g`, uses **SDDM** (not plasmalogin) and reproduces the **same** black screen from the **same** amdgpu root via a different trigger (monitor not powered at boot) — see [Trigger variant B](#trigger-variant-b--cold-boot-with-monitor-off-x570s-aero-g-sddm). Because the root reproduces across *both* KDE-supported login managers, the root is in the amdgpu DRM / EDID / HPD layer, not in one greeter. File the primary under `plasmalogin` (or `plasma-workspace` → `general`) and cross-reference `sddm` / `kscreen` / `KWin` / the kernel `amdgpu` driver. --- ## Summary On KDE Plasma 6.7.0 (KDE Neon), the **plasmalogin** (Plasma Login Manager) Wayland greeter **stops rendering and shows a permanently black screen**, making it impossible to log in graphically. The trigger is a **shared HDMI monitor switched away from this PC** via an external HDMI switch (KVM-style): the HDMI cable stays physically plugged into the GPU, so the kernel keeps the connector `status=connected`, but the monitor is displaying the *other* PC — therefore the EDID is empty (`edid: 0 bytes`). plasmalogin's greeter process stays `active` but drops to **0.0 % CPU** (it is no longer painting). A `systemctl restart plasmalogin.service` revives it immediately while the monitor is switched back. This is **not** SDDM on `dark-hero`: KDE Neon 6.7 ships `plasmalogin` as the login manager; the `sddm` binary is not installed (only the `kde-config-sddm` KCM config package is present). The user's "usual" greeter (wallpaper + user list with avatars) **is** plasmalogin. **The same root reproduces on a second machine with a different login manager.** On `x570s-aero-g` (AMD Cezanne APU + RX 6900 XT, monitor on the APU's `card2-HDMI-A-2`, **SDDM** with the Xorg greeter — `plasmalogin` is installed but not the active display manager), a cold boot with the monitor **not turned on promptly** leaves the greeter showing a black screen with "signal present". The kernel logs `amdgpu … [drm] Cannot find any crtc or sizes` for the display GPU at probe time (no EDID because the monitor was off), the SDDM greeter opens a `0×0` view, and the connector stays `enabled=disabled / dpms=Off`. `sudo systemctl restart sddm` (no OS reboot) re-probes the now-powered monitor and renders normally — see **Trigger variant B** below. Two machines, two login managers (plasmalogin + SDDM), one amdgpu/EDID root. --- ## Hardware / environment | Item | Value | |---|---| | OS | KDE neon User Edition (base Ubuntu 24.04 "noble"), `ID=neon ID_LIKE="ubuntu debian"` | | Kernel | Linux 6.17.0-35-generic x86_64 | | Plasma | plasma-workspace 6.7.0 (`4:6.7.0-0zneon+24.04+noble+release+build90`) | | Login manager | **plasmalogin 6.7.0** (`6.7.0-0zneon+24.04+noble+release+build20`) | | KDE Frameworks | KF6 ≥ 6.27.0 (per plasmalogin Depends) | | Qt | 6.11.1 (`qt6-base 6.11.1-0zneon+24.04+noble+release+build161`) | | GPU | AMD Radeon RX 6900 XT (Navi 21, gfx1030, PCI `0d:00.0`, `[1002:73bf]`) — single dGPU, no iGPU | | CPU | AMD Ryzen 9 5950X (16-core, Vermeer — no integrated graphics) | | amdgpu driver | **DKMS out-of-tree v6.16.13** (`/lib/modules/6.17.0-35-generic/updates/dkms/amdgpu.ko.zst`) | | Kernel cmdline | `BOOT_IMAGE=/vmlinuz-6.17.0-35-generic root=UUID=... ro quiet splash vt.handoff=7` | | Hostname | dark-hero | ### Display setup (the key context) A **single physical monitor** is shared between **two PCs** via an **external HDMI switch** (a hardware A/B selector with a remote — two separate HDMI cables, one per PC). The HDMI cable to this PC is **never physically unplugged**; the user switches which PC's output the monitor shows using the switch's remote control. Most of the time the monitor is displaying the *other* PC (172.16.0.103); this PC (102) is headless-by-switch most of the time and only switched to on demand. Consequence for the kernel: the RX 6900 XT's `HDMI-A-1` connector is reported **`connected`** (HPD asserted by the always-plugged cable / switch) but the **EDID is empty** because the monitor is not currently driving this input: ``` $ for c in /sys/class/drm/card1-*/status; do echo "$c: $(cat $c)"; done /sys/class/drm/card1-DP-1/status: disconnected /sys/class/drm/card1-DP-2/status: disconnected /sys/class/drm/card1-DP-3/status: disconnected /sys/class/drm/card1-HDMI-A-1/status: connected <-- cable plugged, HPD high /sys/class/drm/card1-Writeback-1/status: unknown $ for c in /sys/class/drm/card1-*/edid; do echo "$c: $(stat -c%s $c) bytes"; done /sys/class/drm/card1-HDMI-A-1/edid: 0 bytes <-- monitor switched away: no EDID ``` This **"connected with no EDID"** state appears to be the core trigger (see amdgpu IRQ analysis below). It is the normal state of any machine behind an HDMI/KVM switch that does not actively emulate a display on the inactive input. --- ## Steps to reproduce 1. Boot the PC with the monitor switched to it (greeter shows normally, login succeeds). 2. **Switch the monitor away to the other PC** via the HDMI switch (cable to this PC stays plugged in). Leave it switched away for a while (tens of minutes to hours). 3. While away, the machine is used over SSH (a long-running GPU compute job — `ggml-rpc-server` — keeps running; the user session `mge-engineer` stays logged in). 4. **Switch the monitor back** to this PC. Expected: the Plasma session / lock screen / plasmalogin greeter is shown. Actual: **black screen**. If logged out, the plasmalogin greeter is also black and **does not accept input** — cannot log in. Reproduced repeatedly; the machine has **5 boots in 2 days** (2026-07-07 → 2026-07-09) due to this and related crashes: ``` $ journalctl --list-boots -4 5697cea8… Tue 2026-07-07 22:04:34 → Wed 2026-07-08 04:19:16 -3 f2b248a4… Wed 2026-07-08 20:23:17 → Wed 2026-07-08 23:41:12 -2 704f0226… Wed 2026-07-08 23:41:33 → Thu 2026-07-09 00:15:19 -1 9fed31e3… Thu 2026-07-09 00:15:41 → Thu 2026-07-09 00:32:21 0 1fd4df19… Thu 2026-07-09 00:32:43 → current ``` --- ## Observed behavior ### A. plasmalogin greeter stalls at 0 % CPU (the black screen) After a crash/reboot cycle, `plasmalogin.service` is `active` but the greeter is not painting: ``` $ systemctl is-active plasmalogin.service active $ systemctl show plasmalogin.service -p MainPID -p ActiveEnterTimestamp MainPID=1318 ActiveEnterTimestamp=Thu 2026-07-09 00:32:45 EEST <-- booted ~14h ago $ ps -o pid,pcpu,etimes,comm -p 1318 PID %CPU ELAPSED COMMAND 1318 0.0 50406 plasmalogin <-- 0.0% CPU for ~14h: not rendering ``` Restarting the unit revives it: ``` $ sudo systemctl restart plasmalogin.service $ ps -o pid,pcpu,etimes,comm -p $(systemctl show -p MainPID --value plasmalogin.service) PID %CPU ELAPSED COMMAND 7108 3.0 0 plasmalogin <-- 3% CPU: greeter painting again ``` ### B. plasmalogin journal — the crash sequence Boot `-2` (2026-07-09 00:15, the failing boot). Note: login **succeeded** at 00:15:51, the greeter tore down normally (`helper exited with 255` is the **expected** post-login teardown), then **~16 minutes later** the helper **crashed again** ("Process crashed", exit code 1) — this second crash is the bug, and it killed the active session, leading to the reboot at 00:32:43: ``` июл 09 00:15:43 plasmalogin[1318]: Greeter session started successfully июл 09 00:15:44 plasmalogin[1318]: Message received from greeter: Connect июл 09 00:15:51 plasmalogin[1318]: Message received from greeter: Login июл 09 00:15:51 plasmalogin[1318]: Authentication for user "mge-engineer" successful июл 09 00:15:51 plasmalogin[1318]: Session started true июл 09 00:15:56 plasmalogin[1318]: Greeter stopping... июл 09 00:15:56 plasmalogin[1318]: Auth: plasmalogin-helper exited with 255 <-- normal post-login teardown июл 09 00:15:56 plasmalogin[1318]: Greeter stopped. PLASMALOGIN::Auth::HelperExitStatus(255) [16 minutes pass; monitor switched away part of the time] июл 09 00:32:18 plasmalogin[1318]: Authentication error: PLASMALOGIN::Auth::ERROR_INTERNAL "Process crashed" июл 09 00:32:18 plasmalogin[1318]: Auth: plasmalogin-helper (... --start .../startplasma-wayland --user mge-engineer) crashed (exit code 1) июл 09 00:32:18 plasmalogin[1318]: Auth: plasmalogin-helper exited with 1 июл 09 00:32:18 systemd[1]: Stopping plasmalogin.service - Plasma Login Manager... июл 09 00:32:18 systemd[1]: plasmalogin.service: Deactivated successfully. ``` ### C. amdgpu DRM IRQ workqueue hogging CPU (correlates with HPD-on-empty-EDID) `dmesg` shows the amdgpu display IRQ workqueue repeatedly hogging CPU, with the count **increasing over uptime** (4 → 5 → 7 → 11 occurrences). This is consistent with the driver continuously polling / re-validating a connector that is `connected` but has no EDID (the HDMI-switched-away state): ``` [17742.056594] workqueue: dm_irq_work_func [amdgpu] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [21786.981300] workqueue: dm_irq_work_func [amdgpu] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [31446.920970] workqueue: dm_irq_work_func [amdgpu] hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND [45357.786849] workqueue: dm_irq_work_func [amdgpu] hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND ``` amdgpu is the **DKMS out-of-tree v6.16.13** build for kernel 6.17.0-35, i.e. newer than the in-tree driver. This may or may not be in scope for KDE, but it is the kernel-side half of the problem and should be referenced — plasmalogin's greeter cannot reliably render a Wayland surface while the DRM layer is in this hotplug churn state. ### D. Secondary crash: `plasmashell --version` SIGABRT While collecting version info, `plasmashell --version` **aborted with SIGABRT** and produced a core dump — with the command line literally `plasmashell --version`. This happened inside an already-running user session (session 137), so it is likely the "second instance cannot initialize" abort, but it still indicates fragility worth noting: ``` $ plasmashell --version ( Segmentation fault / core dumped ) $ coredumpctl info -1 PID: 8483 (plasmashell) Signal: 6 (ABRT) Timestamp: Thu 2026-07-09 14:43:32 EEST Command Line: plasmashell --version Executable: /usr/bin/plasmashell Session: 137 Storage: /var/lib/systemd/coredump/core.plasmashell.1000.1fd4df191d894dffae435438e62d1380.8483.1783597412000000.zst (present) Size on Disk: 1.3M ``` A backtrace can be produced with `coredumpctl debug 8483` (gdb + plasma-workspace-dbgsym). Please request if useful; I can attach it. --- ## Trigger variant B — cold boot with monitor off (`x570s-aero-g`, SDDM) A **second machine** hits the **same** black-screen-with-signal symptom from the **same** amdgpu/EDID root, but through a different trigger and a different login manager. This is what makes the bug a *root-cause* issue in the DRM/EDID path rather than a plasmalogin-specific quirk: it reproduces on SDDM too. ### B.0 Machine (different from `dark-hero`) | Item | Value | |---|---| | Hostname | `x570s-aero-g` | | OS / Kernel | KDE neon User Edition, Linux 6.17.0-35-generic (same distro/kernel as `dark-hero`) | | Login manager | **SDDM 0.21.0** (`display-manager.service → sddm.service`); Xorg greeter, `vt2`. `plasmalogin` is installed but **not** the active display manager. | | GPUs | **two** AMD: discrete RX 6900 XT (Navi 21, `03:00.0`, `card1`) + integrated Vega APU / Cezanne (`0e:00.0`, `card2`) | | Monitor | plugged into the **Vega APU** — `/sys/class/drm/card2-HDMI-A-2` (so the *display* GPU is the weak APU, `0e:00.0`, not the 6900 XT) | ### B.1 Trigger The PC had been **up ~24 h** and was rebooted; on the new boot the **monitor was not turned on promptly** after the OS came up. The monitor reports "signal present" but shows a **black screen** — the SDDM greeter never renders. (The user's prior, blunt workaround had been a full reboot; the case below was fixed **without** an OS reboot.) ### B.2 Kernel evidence — amdgpu cannot find a CRTC at probe (verbatim, `journalctl -k -b 0`) At boot the display GPU (`0e:00.0`, the Vega APU the monitor is on) logs the tell-tale `Cannot find any crtc or sizes` — i.e. the driver probed the connector before a valid EDID was available and could not build a mode/CRTC. The 6900 XT (`03:00.0`) logs the same line (it has no monitor attached, so that one is expected); the relevant one is `0e:00.0`: ``` лип 10 03:05:54 x570s-aero-g kernel: amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes лип 10 03:05:55 x570s-aero-g kernel: amdgpu 0000:0e:00.0: [drm] Cannot find any crtc or sizes <-- display GPU лип 10 03:09:22 x570s-aero-g kernel: fbcon: amdgpudrmfb (fb0) is primary device лип 10 03:09:22 x570s-aero-g kernel: amdgpu 0000:0e:00.0: [drm] fb0: amdgpudrmfb frame buffer device ``` Kernel fbcon comes up on `0e:00.0` (a linear framebuffer exists), but the **greeter's DRM output is never enabled** — fbcon ≠ a usable modeset for the greeter. ### B.3 amdgpu IRQ workqueue hog (same signature as `dark-hero`, section C) The identical `dm_irq_work_func` CPU-hog message appears on this machine too — the same hotplug/EDID churn the `dark-hero` report attributes the stall to, on a different machine and login manager: ``` лип 10 08:43:23 x570s-aero-g kernel: workqueue: dm_irq_work_func [amdgpu] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND ``` ### B.4 SDDM greeter pre-recovery — `0×0` view, connector disabled Before the fix, the SDDM greeter (PID 1279) opened a **`0×0`** view — i.e. no mode was applied — and the display connector stayed disabled (values captured live during the session; the rotated Xorg log was overwritten by the restart, so the pre-restart log line is quoted from the live observation, not re-read from disk): - SDDM greeter (Xorg, `vt2`): `Adding view for ":0.0" QRect(0,0 0x0)` — **0×0 view**. - `/sys/class/drm/card2-HDMI-A-2`: `status=connected enabled=disabled dpms=Off`. Contrast with the post-recovery Xorg log (on disk, `/var/log/Xorg.0.log`), where the connector probes cleanly once the monitor is powered and SDDM is restarted: ``` [21499.717] (II) AMDGPU(0): glamor X acceleration enabled on AMD Radeon Graphics (radeonsi, renoir, ...) [21499.731] (II) AMDGPU(0): EDID for output HDMI-A-1 [21499.731] (II) AMDGPU(0): Output HDMI-A-1 connected [21499.731] (II) AMDGPU(0): Output HDMI-A-1 using initial mode 1920x1080 +0+0 [21499.755] (==) AMDGPU(0): DPMS enabled ``` ### B.5 Recovery without an OS reboot (verbatim, `journalctl -u sddm -b 0`) `sudo systemctl restart sddm` (run over SSH) re-probed the now-powered monitor and rendered the greeter normally. The user then logged in successfully. No new `amdgpu` errors after the restart: ``` лип 10 09:00:12 x570s-aero-g systemd[1]: Stopping sddm.service - Simple Desktop Display Manager... лип 10 09:00:12 x570s-aero-g sddm[1279]: Greeter stopping... лип 10 09:00:13 x570s-aero-g systemd[1]: Started sddm.service - Simple Desktop Display Manager. лип 10 09:00:13 x570s-aero-g sddm[39414]: Adding new display... лип 10 09:00:14 x570s-aero-g sddm[39414]: Greeter session started successfully лип 10 09:00:45 x570s-aero-g sddm[39414]: Message received from greeter: Login лип 10 09:00:45 x570s-aero-g sddm[39414]: Session started true <-- login succeeded ``` Post-restart connector state: `card2-HDMI-A-2: enabled=enabled, dpms=On`; SDDM greeter view `Adding view for "HDMI-A-1" QRect(0,0 1920x1080)`. The Xorg PID changed (old greeter `1279` → new `39414`), i.e. a clean display-server restart, not an OS reboot. ### B.6 Why this is the same bug | Aspect | Trigger A (`dark-hero`) | Trigger B (`x570s-aero-g`) | |---|---|---| | Login manager | plasmalogin (Wayland greeter) | SDDM (Xorg greeter) | | GPU topology | single dGPU (RX 6900 XT) | dGPU + APU; monitor on the APU | | Connector | `card1-HDMI-A-1` | `card2-HDMI-A-2` | | EDID-missing cause | HDMI switch — monitor on the *other* PC, cable stays plugged | monitor **off** at boot, powered on later | | Kernel signature | `dm_irq_work_func` hog (grows with uptime) | `Cannot find any crtc or sizes` at probe **+** `dm_irq_work_func` hog | | Greeter symptom | `active` but 0.0 % CPU, not painting | `0×0` view, `enabled=disabled / dpms=Off`, not painting | | User-visible result | black screen, "signal present", can't log in | black screen, "signal present", can't log in | | Recovery (no OS reboot) | `systemctl restart plasmalogin.service` | `systemctl restart sddm` | Both reduce to: **amdgpu is asked to bring up an output whose connector is `connected` but whose EDID is absent at probe time, fails to establish a CRTC/mode, and leaves the display manager with nothing to render** — and neither plasmalogin nor SDDM recovers on its own once a real EDID arrives; both need a display-manager restart. The fix belongs in the amdgpu/DRM EDID/HPD path (defer/retry the modeset when EDID appears) and/or in display-manager resilience (re-trigger the probe on HPD-with-EDID), not in one greeter. --- ## Expected behavior When the shared monitor is switched back to this PC (trigger A) **or** turned on after boot (trigger B), the display manager's greeter — whether `plasmalogin`'s Wayland greeter **or** SDDM's Xorg greeter — should resume rendering and accept input without a service restart. The driver/userspace should treat a `connected` connector with an empty/absent EDID gracefully: defer the modeset and **re-probe on the next HPD-with-EDID event**, instead of stalling the greeter at `0×0` / 0 % CPU and (in the worse case) crashing `plasmalogin-helper` mid-session. Concretely, the `Cannot find any crtc or sizes` state should self-heal once a real EDID arrives, without a `restart sddm` / `restart plasmalogin`. --- ## Workaround - Trigger A (`dark-hero` / plasmalogin): `sudo systemctl restart plasmalogin.service` (run over SSH or from a VT) revives the greeter. It does **not** disrupt unrelated daemons (e.g. the `ggml-rpc-server` GPU compute job, which is reparented to PID 1 and survives the restart). - Trigger B (`x570s-aero-g` / SDDM): `sudo systemctl restart sddm` (run over SSH) re-probes the now-powered monitor and renders the greeter normally — **no OS reboot needed**. In both cases this is only a workaround — the black screen recurs the next time the trigger fires (monitor switched away-and-back, or monitor off at boot). --- ## Additional notes - The machine is normally accessed over SSH while headless-by-switch; a long-running distributed GPU compute job (`ggml-rpc-server` serving an RPC model split to the other PC) must keep running, so the greeter stall must not be "fixed" by killing the GPU workload. - `~/.local/share/kscreen/` is empty — no display configuration has been persisted, consistent with the empty-EDID state (kscreen has nothing to save). - A harmless but noisy warning also appears at greeter start: `DBus error: "org.freedesktop.DBus.Error.UnknownProperty" - "Unknown interface org.freedesktop.systemd1.Manager or property SoftRebootsCount."` — plasmalogin queries a systemd property that this systemd version (255.4) does not expose. Not the cause (the greeter starts fine despite it), but worth a separate minor bug. --- ## Logs / data I can attach on request - Full `journalctl -u plasmalogin.service` across the last 5 boots (`dark-hero`). - `dmesg` full amdgpu/DRM excerpt. - `coredumpctl` backtrace for the `plasmashell --version` SIGABRT (PID 8483, `dark-hero`). - `modinfo amdgpu`, `lspci -nn`, `rocminfo` output. - `loginctl list-sessions`, `systemctl status plasmalogin`. - `/sys/class/drm/card1-*/status` + `edid` size (connected + 0 bytes reproduced above). - Trigger B (`x570s-aero-g`): `journalctl -k -b 0` (the `Cannot find any crtc or sizes` + `dm_irq_work_func` excerpt), `journalctl -u sddm -b 0` (the `restart sddm` recovery sequence), `/var/log/Xorg.0.log` (post-recovery: HDMI-A-1 connected, 1920x1080), and the live pre-recovery values (`card2-HDMI-A-2 enabled=disabled dpms=Off`, greeter `0×0` view) captured during the session. --- *Collected 2026-07-09 from `dark-hero` (172.16.0.102) and 2026-07-10 from `x570s-aero-g`, both via SSH. Reporter: mge-engineer.* -- You are receiving this mail because: You are watching all bug changes.
