xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

korimitsu · 2026-07-11 08:43:55

After this morning's update (2026-07-11), which included xorg-server 21.1.23-1 -> 21.1.24-1, SDDM comes up as a black screen with only a movable mouse cursor on my hybrid-graphics laptop. SSH and Contol+Alt+Fxx work so I can use whell to perform manteinance operations. Downgrading only the four xorg-server packages back to 21.1.23-1 - same kernel, same nvidia driver, same config - fully restores the login screen and session, so this looks like a regression in xorg-server 21.1.24.

System:

Laptop, Intel iGPU (i915, internal eDP panel) + NVIDIA RTX Laptop GPU
Kernel: 6.18.38-2-lts
NVIDIA: nvidia-580xx-dkms + nvidia-580xx-utils 580.173.02-1 (legacy branch from AUR, NOT changed by this update, kernel module loads fine)
DM/session: SDDM, X11
X config: stock - only /etc/X11/xorg.conf.d/00-keyboard.conf; the nvidia OutputClass comes from the driver package
No early KMS: the nvidia modules are not in the initramfs, so nvidia-drm registers /dev/dri/card2 about 1 s after X starts and the dGPU reaches X via the udev GPU-hotplug path

On 21.1.24, screen 0 (Intel, modesetting/glamor, eDP-1) initializes normally. When card2 appears, X applies the nvidia OutputClass but never loads nvidia_drv; it binds modesetting+glamor to the dGPU and fails, then udev removes/re-adds the device and the same sequence fails a second time:

[    21.453] (II) config/udev: Adding drm device (/dev/dri/card2)
[    21.454] (II) Applying OutputClass "nvidia" options to /dev/dri/card2
[    21.499] (II) modeset(G0): glamor X acceleration enabled on NVIDIA GeForce RTX xxxx Laptop GPU/PCIe/SSE2
[    21.543] (WW) modeset(G0): Option "AllowEmptyInitialConfiguration" is not used
[    21.543] (EE) modeset(G0): Failed to create pixmap
[    22.197] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card2 /dev/dri/card2
[    22.197] (II) config/udev: Adding drm device (/dev/dri/card2)
             ... identical sequence ...
[    22.235] (EE) modeset(G0): Failed to create pixmap

There is no LoadModule: "nvidia" anywhere in the broken log. SDDM's own log claims the greeter started successfully, but the panel stays black with only the cursor.

The same server also segfaults on termination (during systemctl restart sddm):

[ 1881.709] (EE) Segmentation fault at address 0xd8
[ 1881.709] (EE) Caught signal 11 (Segmentation fault). Server aborting

On 21.1.23 (only xorg-server* downgraded, everything else identical) the nvidia ddx is loaded for the same GPU and everything works:

[ 1882.150] (II) LoadModule: "nvidia"
[ 1882.257] (II) NVIDIA(G0): NVIDIA GPU NVIDIA GeForce RTX xxxx Laptop GPU (ADxxx-X) at
[ 1882.396] (II) NVIDIA(G0): [DRI2]   VDPAU driver: nvidia

xrandr --listproviders shows both providers (modesetting + NVIDIA-G0) and PRIME render offload works.

Full logs: broken (21.1.24): <LINK1> working (21.1.23): <LINK2>

Workaround for anyone hitting this:

sudo pacman -U \
  https://archive.archlinux.org/packages/x/xorg-server/xorg-server-21.1.23-1-x86_64.pkg.tar.zst \
  https://archive.archlinux.org/packages/x/xorg-server-common/xorg-server-common-21.1.23-1-x86_64.pkg.tar.zst \
  https://archive.archlinux.org/packages/x/xorg-server-devel/xorg-server-devel-21.1.23-1-x86_64.pkg.tar.zst \
  https://archive.archlinux.org/packages/x/xorg-server-xvfb/xorg-server-xvfb-21.1.23-1-x86_64.pkg.tar.zst

plus IgnorePkg = xorg-server xorg-server-common xorg-server-devel xorg-server-xvfb until it's fixed. Early KMS (nvidia modules in the initramfs) should also sidestep the hotplug path entirely.

Anyone else on hybrid Intel+NVIDIA seeing this since 21.1.24?

seth · 2026-07-11 12:13:55

Please post the complete xorg log of both server versions.

korimitsu · 2026-07-11 17:14:48

These are the logs, they are redacted to remove serial numbers and other things not needed:

xorg-server 21.1.24 regression: hotplugged secondary GPU that fails to attach leaves concurrent clients starved (hybrid Intel+NVIDIA, X11)

Summary

Since xorg-server 21.1.24, on hybrid-graphics systems where the NVIDIA DRM device registers after the X server has started, the (long-standing, previously harmless) failure of the udev GPU-hotplug attach now breaks the session: the client whose startup or rendering overlaps the failure window stops receiving replies/events from the server and hangs indefinitely. On 21.1.23, the identical hotplug attach fails with the identical log signature, and the session is completely unaffected. Downgrading only the xorg-server packages (same kernel, same driver, same configuration) flips the behavior deterministically.

Environment (generic — reproduces independent of exact models)

- xorg-server 21.1.24 (regression) vs 21.1.23 (works). Arch packaging applies no patches — pristine upstream source.
- Hybrid laptop: Intel iGPU driving the internal panel (i915, screen 0 via modesetting + glamor/iris, mesa 26.x), plus an NVIDIA discrete GPU on the proprietary driver (observed with the 580 branch; the failure occurs before the NVIDIA X driver is loaded, so it should be branch-independent) with no connected outputs.
- Display manager: SDDM with the X11 greeter.
- nvidia modules are not loaded early (not in the initramfs, no modules-load.d), so nvidia-drm registers its DRM node ~1–2 s after the display manager starts X — the GPU reaches the server through the udev hotplug path. This is the default situation on Arch.

Reproducer (deterministic, ~60 seconds)

systemctl stop sddm
modprobe -r nvidia_drm nvidia_modeset nvidia_uvm nvidia
systemctl start sddm
sleep 2
modprobe nvidia_drm     # DRM device hotplugs into the running server

- 21.1.24: greeter never becomes usable — black screen with a movable cursor, or a rendered but completely frozen greeter, depending on exactly when the hotplug lands relative to greeter startup.
- 21.1.23: identical sequence, identical error in the log — greeter fully functional, login proceeds normally.

The same failure occurs on natural boots whenever nvidia-drm loses the race against the display manager (observed on 3 of 4 natural boots on the affected machine).

Log signature (identical on both versions)

At X startup only the Intel device is present and screen 0 initializes cleanly (glamor on iris, mode set, cursor visible). The NVIDIA device then arrives via udev; the server applies the nvidia OutputClass but the hotplug path binds modesetting+glamor to it, which fails; udev then removes and re-adds the device and the sequence fails identically a second time:

(II) config/udev: Adding drm device (/dev/dri/cardN)
(II) Applying OutputClass "nvidia" options to /dev/dri/cardN
(II) modeset(G0): glamor X acceleration enabled on NVIDIA <gpu>/PCIe/SSE2
(WW) modeset(G0): Option "AllowEmptyInitialConfiguration" is not used
(EE) modeset(G0): Failed to create pixmap
(II) config/udev: removing GPU device ... cardN
(II) config/udev: Adding drm device (/dev/dri/cardN)
    ... identical sequence ...
(EE) modeset(G0): Failed to create pixmap

There is no LoadModule: "nvidia" in the hotplug path on either version. To be explicit: this pixmap failure is not the regression — it is byte-for-byte the same on 21.1.23, where nothing bad follows. None of the 14 commits in xorg-server-21.1.23..xorg-server-21.1.24 touches hw/xfree86/common/ (the hotplug/driver-selection code) or present/.

What regresses: client-visible behavior on 21.1.24

Three phenotypes, all traced with gdb + debuginfod on live processes and core dumps; distinguished only by where the affected client happens to be when the failed attach occurs:

1. Rendered but frozen greeter (client already past startup): the Qt render thread is blocked in

xcb_wait_for_special_event <- dri3_wait_for_event_locked <- loader_dri3_swap_buffers_msc <- dri3_swap_buffers <- glXSwapBuffers

i.e. a PresentPixmap was accepted and the PresentCompleteNotify special event is never delivered — on the healthy Intel screen 0, through the mesa/iris path; the NVIDIA GPU appears nowhere in the stack. The main thread waits on the render thread in QSGThreadedRenderLoop::polishAndSync, so input is never processed. Under 21.1.23 with the same forced trigger, the same threads idle normally (Present completions arrive).

2. Black screen (client still in startup): the greeter blocks inside a synchronous xcb-xkb reply wait during initialization, before creating any window, and hangs indefinitely; in the observed case the reply eventually materialized as NULL after ~13 minutes and the greeter crashed on an unchecked dereference (the missing NULL check is an SDDM bug, reported to SDDM separately — the stalled/errored reply is server-side).

3. Later clients are fine: connecting to the broken display afterwards, xset q succeeds and glxinfo completes a full GLX handshake with direct rendering. The starvation affects the client that overlapped the failure window, not the server globally.

Additionally, stopping a server that has gone through the failed attach segfaults on both versions (pre-existing, not part of the regression) — at address 0x0 on 21.1.23 and, on 21.1.24:

(EE) Segmentation fault at address 0xd8
(EE) Caught signal 11 (Segmentation fault). Server aborting

(both addresses are NULL-family dereferences during teardown of the half-attached GPU screen).

Result matrix

           GPU present at X startup   GPU hotplugs after X startup
21.1.23    works                       pixmap error logged, session WORKS
21.1.24    works                       pixmap error logged, session BROKEN

Teardown of a server that went through the failed attach segfaults on both versions (0x0 on 21.1.23, 0xd8 on 21.1.24) — pre-existing, listed for completeness.

Workarounds (verified)

- Load nvidia_drm before the display manager (early KMS via initramfs, or echo nvidia_drm > /etc/modules-load.d/nvidia.conf) — the hotplug path is never exercised.
- Downgrade to 21.1.23.

Last edited by korimitsu (2026-07-11 17:15:56)

seth · 2026-07-11 18:20:06

to remove serial numbers and other things not needed:

"random numbers that scared you for no particular reason" - there's not a single "serial number" being obfuscated but some memory position, the brand number of the GPU (4080) the kernel build date…
Also the stack positions in the backtrace which under normal circumstances would be seriously stupid, but it at least looks like the stack is corrupted anyway.

There is *nothing* in that log that would be sensitive, the disk UUID in the kernel commandline is trackable (ie. you post that in various locations it connects those posts) and that's it.

- nvidia modules are not loaded early (not in the initramfs, no modules-load.d), so nvidia-drm registers its DRM node ~1–2 s after the display manager starts X — the GPU reaches the server through the udev hotplug path. This is the default situation on Arch.

More like the default brokeness of systemd. Is that what you mean by "hotplugging" (cause it ain't)
This shows up a lot since a couple of versions and has nothing to do w/ nvidia or strictly early KMS - the default remedy is to just stall the execution of SDDM
Trying to make the X11 server switch the driver of the already (badly) operated GPU won't work.
=> https://bbs.archlinux.org/viewtopic.php … 8#p2303248

Otherwise:
You're not loading the nvidia drivers anywhere in those logs, the card gets picked up by the modesetting driver.
Also the GPU isn't hotplugged? It seems there when every server started.
https://bbs.archlinux.org/viewtopic.php?id=314241 ?

lspci -knnd ::03xx # none of the numbers there is scary, don't redact *any* of this
pacman -Qs nvidia # or this
dkms status # or this

korimitsu · 2026-07-11 20:42:33

For anyone using the sleep-10 drop-in: a better way with zero fixed delay is to load the module itself in the drop-in (/etc/systemd/system/sddm.service.d/override.conf, then systemctl daemon-reload):

[Service]
ExecStartPre=-/usr/bin/modprobe nvidia_drm

modprobe returns only after the DRM device is registered, so the ordering is guaranteed rather than bet on. The "-" prefix means a failed load still lets the DM start, giving you an iGPU session instead of a hung unit.
Equivalent system-wide, which is what I run:

echo nvidia_drm | sudo tee /etc/modules-load.d/nvidia.conf

To preempt "is this a bug or a misconfiguration": the race existing is arguably a configuration/ordering gap, hence the workarounds above, which I run and recommend. What the server does when it loses the race is a different layer: failing the attach and then permanently starving a client whose requests overlapped it, behavior that flips between 21.1.23 and 21.1.24 under identical configuration and an identical forced trigger, plus a teardown segfault on both versions. Runtime DRM device addition is a supported server feature, not an illegal input. Configuration determines whether this code path runs; the server determines what happens when it does, and that's what regressed.

Report the issue upstream to gitlab since new registrations have restrictions.

Arch Linux

#1 2026-07-11 08:43:55

xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

#2 2026-07-11 12:13:55

Re: xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

#3 2026-07-11 17:14:48

Re: xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

#4 2026-07-11 18:20:06

Re: xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

#5 2026-07-11 20:42:33

Re: xorg-server 21.1.24 regression: nvidia_drv not loaded on GPU hotplug

Board footer