Comment 9 for bug 1930903

Additional helpful insights from osmoticum on the Nvidia forum:

The Xorg modesetting DDX seems to be fighting with the Nvidia DDX for DRM nodes

[ 463.657] (II) modeset(G0): using drv /dev/dri/card0

but

[ 463.658] (II) Applying OutputClass "nvidia" options to /dev/dri/card0

Nvidia appears to be adding a lot of DRM related stuff to the kernel driver (so it looks a lot like a real DRM driver to userspace now) and the modesetting DDX is getting further into its initialization.

In my case, pointing the modesetting DDX to only look at non-Nvidia devices (the kmsdev option) and ensuring all the Nvidia kernel modules are fully loaded (instead of having them load on-demand) before starting X worked around this. The latter is for some weird race condition where the Nvidia driver is only partially loaded and https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/config/udev.c#L135 fails, which causes modesetting to load regardless (it’s hardcoded in xf86platformAddDevice)

The WARN_ON itself can still be triggered by simply opening a Nvidia primary DRM node though, e.g. with https://gitlab.freedesktop.org/mesa/drm/-/blob/master/tests/drmdevice.c, when some other DRM client like X or fbcon already has master. Because of https://patchwork.freedesktop.org/patch/367748 the Nvidia kernel driver can no longer use its internal grabOwnership to report if DRM master can be taken.

https://forums.developer.nvidia.com/t/kernel-oops-on-boot-5-9-13-with-455-45-01/163751