When this error comes I can’t edit my fan settings from nvidia menu or GWD. This is super strange since I can install same driver to Xubuntu 21.10 without any errors but not in Ubuntu 21.10.
Pop_OS! also have this same driver and it works without those errors.
e: My case 470.86 and 495.44 both have this error.
I upgraded to 495.46. Haven’t seen the error… YET.
nevermind, still happening in 495.46
It’s still here for me on 495.46.
Dec 22 14:48:44 matt-archlinux kernel: [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000f00] Failed to grab modeset ownership
Hi, on Ubuntu 21.10 with 495.46 and kernel 5.15.11-051511-generic, error still occurre.
I tried duplicating issue on my test system but unable to do so far.
I opened chrome browser & did some browsing followed by sequence of few suspend/resume cycles without any luck.
Config Setup - Precision T7600 + Genuine Intel(R) CPU @ 2.60GHz + kernel 5.13.0-22-generic + NVIDIA TITAN Xp + Driver 495.44 + DELL U2415
Please share nvidia bug report so that I can try to match configuration and also specify steps which can be performed to trigger such error message.
Bug report attached. Actually I think sleep state is not important here, but switching graphic context.
WAYLAND_DEBUG=1 kwin_wayland --drm &> kwin_wyaland_debug.log
I’m not sure if this is Wayland, Driver or Kernel issue, but I think something is not correct on driver / kernel level.
nvidia-bug-report.log.gz (425.1 KB)
actually I still have the modeset error 496.46. I want to retract my previous statement. It appears on boot time. It has nothing to do with sleep/unsleep.
During subsequent use one notices overall instability and graphics glitches that did not exist in 496.46. Eg.:
[ 411.072088] chrome[36382]: segfault at 362404725810 ip 00007fcde35d5569 sp 00007ffd28a897b0 error 4 in libGLX_nvidia.so.495.46[7fcde3588000+ee000]
Here is a dmesg record containing several pertinent error messages.
I have:
GTX 780Ti (by Zotac)
Gigabyte 990FXA rev3
FX8350
Ubuntu 21.10, kernel 5.13.0-22-generic
amd_iommu=on
Would quite like to assist in finding this bug, contact if necessary!
I have a nagging feeling this may be related to the “amd_iommu=on” kernel option and its accompanying hardware. Perhaps try this on an AMD cpu/chipset system?
Plus one more (and bit wired observation). When it hangs pressing RESET button on chase does not reset box - fans starts to spin like during initial boot and that’s all - (once I’ve got impression like there was something like monitor entering black mode). I need to power off and on box. I’m really very puzzled with the recent finding. Checked pressing RESET from X session and it works correctly,
Does anyone have a workable procedure for avoiding this bug until NVidia can nail down and fix? Revert to previous version of driver? I have not changed my hardware, and things ran fine on previous OS/driver versions. Now I have severe performance degradation, memory leaks, abound, and need to reboot several times per day. I used to run this hardware configuration without swap, without needing swap, and now I’m out of ram running only basic Desktop apps and no heavy graphical programs such as games. The state of things now is completely intolerable.
PS: I use driver version 470.86 as appropriate for the 780Ti
I’ve now been running with
It has been 3 days, I am yet to see a modset error… I’ll continue to monitor.
I have AMD processor (Ryzen 3 3200G, but I don’t use built in graphics). Perhaps this depends on other components.
I have Asus PRIME X470-PRO ATX motherboard
I also had nvidia.modeset=1 as a kernel parameter. This parameter is both necessary for Wayland, and for the error to occur.
The error occurs after each boot, I do not have to wait for that at all.
I have discovered that one particularly detrimental setting to performance on my machine was the EHCI handoff support being set to on in my motherboard’s bios, when it should have been off. No word on whether this fixes the problem as I changed to 450-server Ubuntu package to avoid the bug discussed in this thread.
HI All,
The warning message is expected. When a client (such as the modesetting driver) attempts to open our DRM device node while modesetting permission is already acquired by something else (like the NVIDIA X driver), it has to fail, but the kernel won’t let us return a failure after v5.9-rc1, so we print this message. It won’t impact functionality of the NVIDIA X driver that already has modesetting permission. Safe to ignore as long as long as you didn’t need the other client to actually get modesetting permission. If you want to suppress the error, you would need to find which client is attempting to open the NVIDIA DRM device node and prevent it from doing so.
Don’t know if could be related, but with same issue of modesetting with kernel 5.15.16 when at the same time are registered crashes with kwin after login with sddm.
I’m using Gentoo distribution with a personal profile based on latest stable branch and this kind of crashes happen randomly. This is happening for a long time, so maybe a concurrency bug?
Associated bug report for KDE:
https://bugs.kde.org/show_bug.cgi?id=448968
Could you share what is the likely candidate or give some tips where to report it?
Not a solution, but a workaround.
After boot, when all I get is a black screen:
init 3 # shut down Xinit 5 # restart XWorks for me on openSUSE Tumbleweed.
I have the same issue, wondered what was causing it until I ran into this accidentally … top often also shows nvidia-modeset taking 2% cpu usage endlessly