Not exactly. I mentioned there that the vram usage was the same if I launch it as Hyprland and this shows the profile isn’t really helping things. I also tried adding the profile stuff manually with no change.
https://developer.download.nvidia.com/compute/cuda/repos/fedora41/x86_64/
.run file for those that need: https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/releases/download/cuda/NVIDIA-Linux-x86_64-570.86.10.run
Thanks! Does work. Kernel 6.13 also running well. Wonder why didn’t NVidia publish it publicly yet? hmm… But works awesome!
I wont be patching the rpmfusion driver until fedora provides a signed non-debug 6.13 release kernel.
Makes sense for kernel 6.13. But can we expect a 570 release for kernel 6.12 as well? If 570 improves some key points such as suspend/resume, I’d rather delay the upgrade to kernel 6.13 on my system and have a fully functional setup on 6.12.
570 was released and finally fixed my issue: Using two NVIDIA GPUs monitor ok in the first gpu, one is always black on second gpu. ( Although shows the mouse cursor ok) - #15 by gilvbp
570
Changelog:
* Fixed a bug that caused the nvidia-settings control panel to crash
when querying VRR attributes on some monitors.
* Updated the nvidia-settings control panel to use NVML rather than
NV-CONTROL to control GPU clocks and fan speed. This allows related
functionality to work when using Wayland, where the NV-CONTROL X
extension is not available. Note that as a result, some operations
which were previously available to unprivileged users, due to the
privileges of the X server, may now require elevated privileges.
* Added support for VRR on systems with multiple displays.
* Added an application profile to improve performance on Indiana Jones
and the Great Circle.
* Added an application profile to resolve a corruption issue on
Assassin's Creed Valhalla and Assassin's Creed Mirage.
* Implemented support for the VK_KHR_incremental_present extension.
* Fixed a bug that could cause some Vulkan applications to crash when
responding to window resize events.
* Updated GPU overclocking control to be available by default in
nvidia-settings, for GPU boards that support
programmable clock control. Previously, this was only available
when bit 3 was set in the "Coolbits" X config option.
* Disabled a power saving feature on Ada and above generation GPUs
for surfaces allocated with the DRM Dumb-Buffers API, for example,
when using a DRM fbdev. The power saving feature could cause black
screens for DRM Dumb-Buffers which use front buffer rendering instead
of KMS flips.
* Fixed a bug that could cause some multi-threaded OpenGL applications,
for example Civilization 6, to crash when running on Xwayland.
* Added support for querying Dynamic Boost status via the 'power' file
in /proc/driver/nvidia/gpus/*.
* Enabled 32 bit compatibility support for the NVIDIA GBM backend.
* Added a new kernel module parameter, 'conceal_vrr_caps', to the
nvidia-modeset kernel module. This parameter may be used to enable
usage of features on some displays such as ULMB (Ultra Low Motion
Blur) which are incompatible with VRR. See the "Direct Rendering
Manager Kernel Modesetting" (DRM KMS) chapter of the README for
further information.
* Fixed a bug that could cause games to crash when the
"PROTON_ENABLE_NGX_UPDATER" environment variable was set to a value of "1".
* Added /usr/share/nvidia/files.d/sandboxutils-filelist.json
which lists all the driver files used by container runtime
environments such as nvidia-container-toolkit and enroot.
* Added support for the systemd suspend-then-hibernate method of system
sleep. This feature requires systemd version 248 or newer.
* Enabled the nvidia-drm fbdev=1 option by default. When supported by the
kernel and the nvidia-drm modeset=1 option is enabled, nvidia-drm will
replace the system's framebuffer console with one driven by DRM.
This feature can be disabled by setting fbdev=0.
* Implemented a feature that allows low latency display interrupts to
be serviced even when the system is under heavy contention. This
is especially useful for reducing stutter when using virtual reality.
This feature is experimental and disabled by default.
This feature can be enabled by loading nvidia.ko with the
`NVreg_RegistryDwords=RMIntrLockingMode=1` kernel module parameter.
I can see a couple of suspend-related entries there, but I was expecting something more assertive related to this problem, which is 100% reproducible on my system (I just need to set the timeout and let the computer go idle):
jan 24 15:31:47 fedoracosta systemd[1]: nvidia-suspend.service: Deactivated successfully.
jan 24 15:31:47 fedoracosta systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend actions.
jan 24 15:31:47 fedoracosta audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=succ>
jan 24 15:31:47 fedoracosta audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=succe>
jan 24 15:31:47 fedoracosta systemd[1]: Starting systemd-suspend.service - System Suspend...
jan 24 15:31:47 fedoracosta systemd-sleep[104554]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
jan 24 15:31:47 fedoracosta systemd-sleep[104554]: This is not recommended, and might result in unexpected behavior, particularly
jan 24 15:31:47 fedoracosta systemd-sleep[104554]: in suspend-then-hibernate operations or setups with encrypted home directories.
jan 24 15:31:47 fedoracosta systemd-sleep[104554]: Performing sleep operation 'suspend'...
jan 24 15:31:47 fedoracosta kernel: PM: suspend entry (deep)
jan 24 15:31:47 fedoracosta kernel: Filesystems sync: 0.120 seconds
jan 24 15:32:07 fedoracosta kernel: Freezing user space processes
jan 24 15:32:07 fedoracosta kernel: Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
jan 24 15:32:07 fedoracosta kernel: task:gnome-shell state:R running task stack:0 pid:2364 tgid:2364 ppid:2228 flags:0x0000400e
jan 24 15:32:07 fedoracosta kernel: Call Trace:
jan 24 15:32:07 fedoracosta kernel: <TASK>
jan 24 15:32:07 fedoracosta kernel: ? _nv028071rm+0x10/0x10 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? jiffies_to_timespec64+0x24/0x40
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? os_get_current_tick+0x3b/0xa0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? _nv011444rm+0x119/0x280 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv014824rm+0x65/0x170 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv054282rm+0x80/0x170 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv036924rm+0x8a/0xd0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv037124rm+0x10a/0x360 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv031519rm+0xed/0x1f0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv031519rm+0xbd/0x1f0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv031487rm+0x6f0/0x1240 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv024076rm+0x13a0/0x1e70 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv012989rm+0x161/0x290 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv035915rm+0x1f5/0x450 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv035915rm+0x19f/0x450 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv039493rm+0xb67/0xf00 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv051341rm+0x28d/0x3a0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv049422rm+0xfd/0x160 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv049420rm+0x5c/0x90 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv049420rm+0x32/0x90 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv013245rm+0x67/0xa0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? _nv013245rm+0x28/0xa0 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? rm_kernel_rmapi_op+0x92/0x273 [nvidia]
jan 24 15:32:07 fedoracosta kernel: ? nvkms_call_rm+0x4d/0x80 [nvidia_modeset]
jan 24 15:32:07 fedoracosta kernel: ? _nv002866kms+0x4c/0x60 [nvidia_modeset]
jan 24 15:32:07 fedoracosta kernel: ? _nv000543kms+0xb4/0x110 [nvidia_modeset]
jan 24 15:32:07 fedoracosta kernel: ? _nv000543kms+0x8e/0x110 [nvidia_modeset]
jan 24 15:32:07 fedoracosta kernel: ? __nv_drm_gem_nvkms_map+0x66/0xd0 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? __nv_drm_gem_nvkms_mmap+0x16/0x40 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? nv_drm_mmap+0xdd/0x160 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? __mmap_region+0x748/0xb10
jan 24 15:32:07 fedoracosta kernel: ? mmap_region+0x78/0xa0
jan 24 15:32:07 fedoracosta kernel: ? do_mmap+0x499/0x690
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? vm_mmap_pgoff+0xec/0x1c0
jan 24 15:32:07 fedoracosta kernel: ? switch_fpu_return+0x4e/0xd0
jan 24 15:32:07 fedoracosta kernel: ? ksys_mmap_pgoff+0x14b/0x220
jan 24 15:32:07 fedoracosta kernel: ? do_syscall_64+0x82/0x160
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? drm_vma_offset_add+0x33/0x70
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? __nv_drm_gem_map_nvkms_memory_offset+0x1d/0x70 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? nv_drm_gem_map_offset_ioctl+0x4c/0xd0 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? __check_object_size+0x58/0x230
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? drm_ioctl+0x2b7/0x540
jan 24 15:32:07 fedoracosta kernel: ? __pfx_nv_drm_gem_map_offset_ioctl+0x10/0x10 [nvidia_drm]
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? syscall_exit_to_user_mode+0x10/0x210
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? do_syscall_64+0x8e/0x160
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? do_syscall_64+0x8e/0x160
jan 24 15:32:07 fedoracosta kernel: ? srso_return_thunk+0x5/0x5f
jan 24 15:32:07 fedoracosta kernel: ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
jan 24 15:32:07 fedoracosta kernel: </TASK>
jan 24 15:32:07 fedoracosta kernel: OOM killer enabled.
Just to make it clear: the log snippet above is from 565.77, I’ll test it again with 570 on my system as soon as RPMs become available at RPMFusion testing repo. Fingers crossed…
Still no information on the site or github
Recently I notice that an empty desktop (after turning on) can take up ~ 1 GiB according to nvtop, anyone noticed that?
upd:It seems that this does not happen in 570
Thank you!
With the .run file I could install 570.86.10 and openSUSE TW with Kernel 6.13 working again without problems.
Wonder maybe I misuderstood something. How to make gpu run performance profile on Wayland? Or I understood wrongly, that it can be set now in Wayland somehow?
The 565 drivers wreck my Linux system when using OpenMandriva ROME 25.01 with Wayland. I get black screens and the few times when I am able to log in the entire system is lagging and making my Ryzen 9 5950X CPU to spike on every core.
I am also unable to use the .run-files for installing other Nvidia drivers like 550 or the latest 570. It says that I am missing the “gcc” package containing the “cc” development tool.
Edit:
I installed the other packages missing, but it looks like I need “libc” to proceed". I don’t seem to find any repositories with this library using “libc --version” on OpenMandriva.
libc is glibc, and it’s asking for headers so it’d likely be glibc-devel or devel-glibc or the like. I’d assume it’ll also pull in/ask for/require kernel headers/glibc/some other randomness.
Thanks! I installed glibc-devel after finding it in the repos. The issue is now that OpenMandriva comes with the Nouveau drivers which I need to disable, but the process seems very complicated from the looks of it. At least all the libraries I was missing are installed so that’s something I guess. :D
all that and hoping the fix the power issue in the FInals, i have been facing that bug since atleast 555
470.86.10 run file can be downloaded from here
It was a Cuda leak. The official driver is still coming.,
Leak or not, it’s working fine. My issues are gone (suspend and others).
Can someone check power consumption in hardware accelerated video playback on 570 please? Remove "P2 forced" state from drivers
Hi @MichelN86 , about the suspend issues you were experiencing, were they similar to the one I mentioned earlier? Can I keep my hopes high?

