Looks like the Vulkan ICD wake up bug is still present with 555 :(
Hoping this gets fixed by 560, otherwise it will start interfering with stuff like GTK’s Vulkan renderer. This is pretty awful for hybrid graphics laptops…
Same issue here. Debian 12 user, RTX 4090. After upgrade to 555, no errors in nvidia-smi, but deviceQuery gives
./deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
cudaGetDeviceCount returned 999
-> unknown error
Result = FAIL
Other cuda programs like torch also report “unknown error”.
Don’t know if I did something wrong as I’ve never attemped to run the beta drivers before, but after updating to 555, Wayland doesn’t seem to work at all anymore (previously on 550 it was running pretty well, was able to use KDE 6 and Niri with just occasional glitches). KDE 6 goes to a black screen with a giant pixelated cursor (cursor does move, though). And Niri just goes completely black with no cursor. Strangely, KDE 6 under X11 seems to work fine. Super snappy, G-SYNC works, and was able to run the couple of games that I tested just fine (was getting maybe even a few fps more). And I don’t see any messages in dmesg or any of the logs I checked indicating any issues.
I tried adding NVreg_EnableGpuFirmware=0 to the boot options and that didn’t help. Also added drm.modeset=1 and fbdev=1 and that didn’t help (yes, 550 was working fine without them). Then added all 3 and that didn’t help.
Running Garuda Linux (based on Arch), Linux 6.9.1-zen1 kernel, with a Ryzen 5600x and RTX 3060Ti FE. I guess I’ll try booting from the vanilla kernel and see if that helps.
Well, that’s both good and bad to know, since that was the reason I was wanting to try 555. I really don’t get why they don’t fix this.
Edit: Figured it out. Vanilla kernel didn’t work. But creating a file in /etc/modprobe.d with the contents options nvidia_drm modeset=1 fbdev=1 and then running dracut-rebuild (to rebuild the initramfs) got it working again.
Edit 2: Spoke too soon. Niri still isn’t working. Only KDE was. Installed sway and hyprland to test and those are working, so seems Niri specific.
I’m running Fedora 40, with the negativo17 packaged 555.42.02 driver on an RTX 2060, along with KDE 6.0.4 (where Fedora have backported the explicit sync sypport for kwin), and Firefox has become rather crash-ey for me. Running it from a terminal and waiting for the crash suggests it’s also related to explicit sync:
$ firefox
[GFX1]: Device reset due to WR context
[GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Unflushed glGetGraphicsResetStatus: 0x92bb
[GFX1-]: Failed to make render context current during destroying.
[GFX1]: Ignoring call to const GLubyte *mozilla::gl::GLContext::fGetString(GLenum) with failed mImplicitMakeCurrent.
[GFX1]: Ignoring call to void mozilla::gl::GLContext::fDeleteVertexArrays(GLsizei, const GLuint *) with failed mImplicitMakeCurrent.
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@70: error 4: explicit sync is used, but no acquire point is set
ExceptionHandler::GenerateDump cloned child 32028
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
There was also one message in dmesg that wasn’t added at exactly the same time, but might be relevant:
[ 1678.533708] [drm:nv_drm_semsurf_fence_wait_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Attempt to wait on invalid sync FD: 167
I got that as well on arch. Plasma’s panel and desktop widgets froze for me as well. Looked like FF was detecting explicit sync as well from the logs I saw. I reverted the kwin chnage for the moment.
Using CachyOS (Arch derivative), I never get to the sddm login screen after updating to the 555 driver. After the boot process starts, I get a black screen, no cursor, and the screen shuts off soon as if it’s receiving no signal. When I revert to 550, everything works perfectly. My nvidia.conf is:
I have installed the new nvidia drivers 555.42.02, when i use it without NVreg_EnableGpuFirmware=0, waking up after suspend my first screen which is connected with display port to an RTX 3080 loses the signal and stays blank, my second screen which is connected via hdmi → dvi adapter cable works normal. I use wayland with plasma6 6.0.5 under gentoo.
And without NVreg_EnableGpuFirmware=0 my pc is a bit laggy. For example when surfing on facebook, showing the reactions is laggy.
With NVreg_EnableGpuFirmware=0 everything is working as normal.
I’m on GTX 1060 with 555.42.02 driver, kernel 6.9.1
I also have nvidia_drm.modeset=1 kernel parameter
There’s no video output from the DVI-D port on my GPU at all, Wayland, Xorg and even TTY, no image. I tried to revert to 550.78 driver, and it works, so it’s not a problem with my monitor or GPU.
To prevent Firefox from crashing with this new driver I have to disable native Wayland for now by running it with MOZ_ENABLE_WAYLAND=0 firefox. (Fedora 40, Plasma 6)
Plasmashell and or kwin keep stalling however. For some reason I can unstall it by unhiding Yakuake, but it’s still too annoying to be usable. Back to X11 for now…
Somehow for me on openSUSE Tumbleweed Wayland session not working at all and no clue where to dig for problems log. Any advices? Kernel 6.9.1, latest KDE.
With 555.42 driver, Dota 2/CS2 sometimes segfault on start. In dmesg, I can see this error when this happens: [ 275.885823] VKRenderThread[11547]: segfault at 108 ip 00007f6c2b356efe sp 00007f6c001fe460 error 4 in libnvidia-glcore.so.555.42.02[7f6c2a600000+1e
I cannot say about Dota 2, but I’ve played CS2 at least 10 times with driver 555 and have never seen segfault, however on my laptop which I installed fedora I did see segfaults caused by mangohud.
Which is your distro and how did you install the beta driver ?
Just to get it out of the way, my system is running:
Operating System: EndeavourOS
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.9.1-x64v3-xanmod1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31,3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2
NixOS, but this problem not distro related. Some folks report this issue in dota 2 linux github with other distros than mine.
This problem is a weird one. I can launch dota 2/CS2, close the game, launch again, close, and it starts/closing correctly/no segfault. But on 3rd-4rd launch, dota/cs segfault and error in dmesg occur. After that, usually next time dota 2/cs2 launch again without segfault.
Sometimes even first game launch can segfault.
We are using the precompiled drivers from the rhel9 repository on AlmaLinux 9.4 using the :latest stream of the nvidia-driver module, as recommended in the AlmaLinux Wiki (A03 R9 ❯ NVIDIA: Installation on 9.x | AlmaLinux Wiki)
There is no precompiled kmod-nvidia-555…rpm in this repository. Therefore we are unable to setup a new system with this driver or update previously setup systems, currently running the 550 version.
dnf module install nvidia-driver:latest
Last metadata expiration check: 0:49:09 ago on Thu 23 May 2024 03:46:00 PM CEST.
Error:
Problem 1: package nvidia-kmod-common-3:555.42.02-1.el9.noarch requires nvidia-kmod = 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
Problem 2: package cuda-drivers-555.42.02-1.x86_64 requires nvidia-kmod >= 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
Problem 3: package nvidia-driver-3:555.42.02-1.el9.x86_64 requires nvidia-kmod-common = 3:555.42.02, but none of the providers can be installed
package nvidia-kmod-common-3:555.42.02-1.el9.noarch requires nvidia-kmod = 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
Problem 4: package nvidia-driver-3:555.42.02-1.el9.x86_64 requires nvidia-kmod-common = 3:555.42.02, but none of the providers can be installed
package nvidia-modprobe-3:555.42.02-2.el9.x86_64 requires nvidia-driver(x86-64) = 3:555.42.02, but none of the providers can be installed
package nvidia-kmod-common-3:555.42.02-1.el9.noarch requires nvidia-kmod = 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
Problem 5: package nvidia-driver-3:555.42.02-1.el9.x86_64 requires nvidia-kmod-common = 3:555.42.02, but none of the providers can be installed
package nvidia-settings-3:555.42.02-1.el9.x86_64 requires nvidia-driver(x86-64) = 3:555.42.02, but none of the providers can be installed
package nvidia-kmod-common-3:555.42.02-1.el9.noarch requires nvidia-kmod = 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
Problem 6: package nvidia-driver-3:555.42.02-1.el9.x86_64 requires nvidia-kmod-common = 3:555.42.02, but none of the providers can be installed
package nvidia-xconfig-3:555.42.02-2.el9.x86_64 requires nvidia-driver(x86-64) = 3:555.42.02, but none of the providers can be installed
package nvidia-kmod-common-3:555.42.02-1.el9.noarch requires nvidia-kmod = 3:555.42.02, but none of the providers can be installed
conflicting requests
package kmod-nvidia-latest-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
package kmod-nvidia-open-dkms-3:555.42.02-1.el9.x86_64 is filtered out by modular filtering
(try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)
4070 Super / 555.42.02
OpenSUSE TW
Kernel 6.9.1
Plasma 6.0.5
Single Monitor via DP using HDR
No major issues, a few quirks related to VRR/LFC.
LFC brightness flickering during VRR was still observed in Plasma 6.04 but 6.0.5 seems to have improved the situation somewhat. I have also observed that after an application has triggered LFC it is possible that the next application that uses VRR will present a blank screen when fullscreen. When alt-tabbed and that same window is in the background, the frame renders correctly behind whatever else is now at the front. I get the sense that these LFC/VRR-related issues are more of a compositor / kernel issue at the moment but just wanted to list it here.
Other than the above, this driver is providing a very smooth experience and the improvements related to out of order / incomplete frames (the longstanding rendering flickering issue) is transformational. Vulkan render/dispatch timing and consistency, anecdotally, appears tighter now than in the recent past but it’s hard to say if it’s the driver or all of the other changes working better in concert.
Working pretty well overall. I’m running KDE on Arch with the kwin explicit sync patch already applied. I also set NVreg_EnableGpuFirmware=0 in the kernel parameters.
Appreciate all the hard work. Excited to see all of the recent progress.