610 release feedback & discussion

Can confirm and here is a log for monster hunter wilds with Directors Heap for the devs

nvidia-bug-report.log.gz (1.2 MB)

Using 610.43.02-1ubuntu1 on Ubuntu 24.04 LTS installed via the cuda ppa.
Metal Eden crashes at the beginning of the “The Parasite” level:

[11995.570551] NVRM: GPU at PCI:0000:01:00: GPU-3acf5c71-99a1-b081-aca0-d79b2e9238e8
[11995.570555] NVRM: Xid (PCI:0000:01:00): 31, pid=68240, name=GameThread, channel 0x0000003f, intr 00000000. MMU Fault: ENGINE GRAPHICS HUBCLIENT_FE faulted @ 0x1_41e00000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_WRITE

Downgrading to 595 helped.

Grounded 2 no longer works without Descriptors heap but also fails to go in game even with it set

nvidia-bug-report.log.gz (1.2 MB)

Hello @aplattner,

I think Linux users have already been experiencing issues from driver version 580 through 610. I also upgraded to the latest driver(610), but it failed to start after a reboot. I had to reimage the OS and revert back to version 580. There have been multiple reports of issues related to the GSP firmware on Blackwell GPUs during heavy LLM inference workloads, but we have not seen any logs or official confirmation from NVIDIA regarding the root cause. Please investigate this issue and take appropriate action.

Thanks!!!

Im sorry to tell you but youre not going to see or hear much of anything, Nvidia simply doesnt operate in a way that they actively communicate with their users regardless of the operating system you use.

If you have several billion to invest in Nvidia hardware you might get what youre looking for but otherwise we’re all in the same boat. Youll need to report best you can, cross your fingers, and hope something happens.

MH Wilds crashes for me at the menu with NVRM: Xid (PCI:0000:01:00): 109, pid=14979, name=MonsterHunterWi, channel 0x0000000e, errorString CTX SWITCH TIMEOUT, Info 0x108012

I have this error since the 595 driver. Doesn’t happen on 590. Tried with and without descriptor heap.

are you using any mods like optiscalar? Im only using reframework for some armor mods and it works fine for me without heap

I’m only using reframework with disable postprocessing effects mod alongside some armor mods as well. It crashes as soon as your character leaves the tent during the menu intro. I don’t have the issue on 580 or 590. Note that I run the game with /WineDetectionEnabled:False to be able to enable raytracing.

I also have an Xid 109 error on The Witcher 3 crashing after a few seconds of gameplay since 595.

I’m happy to report that bug 5649065 (exploding meshes in native OpenGL Linux programs) which appeared in v580 (back in August 2025 !) has apparently been fixed in (or is not affecting, depending on how NVIDIA manages driver branches) v610.43.02.

I tried for the past two days to trigger it, on two different computers/GPUs (RTX 3070 and RTX 5070 Ti) during hour(s) long sessions in Second Life, and so far, so good !

Let’s hope that this bug will not get reintroduced in future versions…

One thing I yet don’t like with v610 is the fact that VDPAU is not working properly any more when two screens are connected (I suppose it’s because Xinerama support under X11 got dropped in v610): I had to switch VLC video output to Xvideo/XCB to be able to still use it when two screens are connected to the card…

@echoa, I am an enterprise NVIDIA customer as well, working with A100 and H100 GPUs. The problem is that issues affecting the consumer segment, such as those related to the SM12x arch GPUs, do not appear to be treated with the same priority as issues in the data center segment. I believe there is a clear issue with the recent driver releases. I have even reported it by email (linux-bugs@nvidia.com). The issue can be reproduced on different GPUs, including the RTX 5090 and RTX Pro 6000 Blackwell. Some users have also reported similar behavior on the NVIDIA DGX Spark. A common symptom is that, after a crash, the system often requires a complete power cycle to recover. The logs also disappear after the reboot, making troubleshooting difficult. Interestingly, I have not been able to reproduce the issue with GPU burn tool, even under full load and high temperatures. However, I have been able to trigger it during LLM inference with certain models. The behavior is highly non-deterministic, which makes it very difficult to isolate and debug. I like the way this guy reported it: RTX PRO 6000 Blackwell — Xid 79 + Xid 154 GSP crash under vLLM load · Issue #46 · dbirks/home-k8s · GitHub

Trouble installing the new kernel again.
But let’s start from scratch.

Debian 13.5 Trixie, NVidia 5070Ti, driver 610.43.02 (*run file from nvidia.com).
Kernel: 6.12.90+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.90-1 (2026-05-22) x86_64 GNU/Linux.
Everything works as it should.

Today (2026-05-28) there is a new kernel for installation (security):
linux-image-amd64/stable-security 6.12.90-2 amd64
Which installs the following packages:
linux-headers-6.12.90+deb13.1-amd64 linux-headers-6.12.90+deb13.1-common linux-image-6.12.90+deb13.1-amd64 linux-kbuild-6.12.90+deb13.1

Unfortunately, the installation was unsuccessful.
Fragments of what the ‘apt-get dist-upgrade’ command output:

I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.90+deb13-amd64I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.90+deb13-amd64And: /vmlinuz is now a symlink to boot/vmlinuz-6.12.90+deb13.1-amd64And: /initrd.img is now a symlink to boot/initrd.img-6.12.90+deb13.1-amd64/etc/kernel/postinst.d/dkms:Sign command: /usr/lib/linux-kbuild-6.12.90+deb13/scripts/sign-fileSigning key: /var/lib/dkms/mok.keyPublic certificate (MOK): /var/lib/dkms/mok.pub

Autoinstall of module nvidia/610.43.02 for kernel 6.12.90+deb13.1-amd64 (x86_64)Building module(s)…(bad exit status: 2)Failed command:‘make’ -j20 NV_EXCLUDE_BUILD_MODULES=‘’ KERNEL_UNAME=6.12.90+deb13.1-amd64 modules

Error! Bad return status for module build on kernel: 6.12.90+deb13.1-amd64 (x86_64)Consult /var/lib/dkms/nvidia/610.43.02/build/make.log for more information.

The file ‘/var/lib/dkms/nvidia/610.43.02/build/make.log’ contains the following:

/bin/sh: 1: /var/lib/dkms/nvidia/610.43.02/build/pahole.sh: Permission denied

This is strange because this file exists and can be viewed even as a regular user.

root@home:/tmp/11# ls -al /var/lib/dkms/nvidia/610.43.02/build/pahole.sh
-rw-r–r-- 1 root root 1911 05-27 07:04 /var/lib/dkms/nvidia/610.43.02/build/pahole.sh

After installing the 595.58.03 driver (from the *run file), the new kernel 6.12.90+deb13.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.90-2 (2026-05-27) x86_64 GNU/Linux installed correctly.
Everything works as it should.

Postscript:
Yes, I know there is an Nvidia Data Center Driver. I’ve already tested this with the local deb file.
But the update hasn’t been made yet on Datacenter Driver Downloads | NVIDIA Developer and the previous driver version is available:

nvidia-driver-local-repo-debian13-595.71.05_1.0-1_amd64.deb
As of 2026-05-28.

Obviously. NV even has recently announced that they will not even be mentioning consumer segment in their financial reports anymore (ie, it will be merged into “others”) as these are insignificant pennies for them.
Even in DC segment if you buy 50-100 H100 / H200 cards, you should not expect NV’s support to for example reply to your emails: I don’t know what exact threshold for such honor is, but @echoa’s estimate of billions of USD may be quite accurate. This a chronic problem a few of my business partners are dealing with.

Blackwell is called a disaster for a reason. It’s not even clear if the problem is on hardware, GSP firmware or driver level. Whether for DC/compute or desktop/display purposes, I advise everyone just to stay away from Blackwell. RTX PRO 6000 is particularly failure prone as you experienced yourself and as many others on this forum reported.

This however sounds like a system misconfiguration not related to Nvidia: how could Nvidia driver remove logs from your disk?

That has been a known issue with NV modules on Linux for over 2 decades. On Windows to get a signature from M$, your driver needs to meet certain criteria and pass some tests. On Linux it’s a wild west and as due to the current market specifics, everyone will keep buying NV’s stuff anyway, they just doesn’t give a flying F and ship whatever they feel like: there’s zero incentive to for them improve as the worst that can happen is a middle finger from Linus and some whining on this forum (like mine now ;-] ).

It’s available in the “network” repo though:
https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-drivers_610.43.02-1_amd64.deb
https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/nvidia-open_610.43.02-1_amd64.deb
…and compiles fine:

$ /sbin/dkms status nvidia
nvidia/610.43.02, 6.12.90+deb13.1-amd64, x86_64: installed
nvidia/610.43.02, 7.0.10+tbfive1-amd64, x86_64: installed
nvidia/610.43.02, 7.0.7+deb13-amd64, x86_64: installed

At this point it’s probably safe to say that dot-run installer does not support Debian anymore.

Still waiting for AMD to put out something with comparable RT and compute capability. Even with the Linux penalties, I have software that performs better than it would on a 9070 XT if I decided not to disable RT entirely.

Or perhaps I should just buy a 9070 XT, sell this 5070 Ti for more than I paid for it, and be done with it.

At least the understaffed AMD FOSS engineers can be supplemented by capable users who can also look at the code. Can’t say the same for Nvidia.

Amusingly, the 9070 XT is available now for less than I paid for this card months ago before the prices went up, and now this card can probably sell used for more than $1000.

For pure compute, pre-Blackwell Nvidia card are ok-ish. Among consumer models, whether to go for AMD or NV depends on your exact budget range and whether you need more computing power or more VRAM (in this last case you may even consider Intel B70 being the cheapest 32GB option, but also the slowest).
But if you ever consider displaying anything on it, then it definitely should be non-NV IMHO.

Already have a 5070 Ti, I could probably sell it. Could get a 9070 XT shipped in under 24 hours, for less than I paid for this 5070 Ti.

Displaying, gaming, and running video chats are primary concerns, secondary is compute.

Apart from the fact that on Linux you should not be doing this on NV, I know quite little on the subject, so maybe wait for a few more opinions from more experienced users.
techpowerup shows 9070xt and 5070ti right next to each other in “Relative Performance” table.

With a 4080 super raytracing still causes the witcher 3 to freeze after a few seconds to a few minutes. Downgrading to 580xx drivers fixed the issue. Why are regressions for core features still present after so many releases?

just add execution permission to pahole.sh , it’s a known bug.

if you do LLMs or Generative AI AMD is flat out worse, if you do encoding AMD is worse, and if you do Blender or any graphics work AMD is worse minus their substantially better handled color pipeline (this is true for windows and linux). so for color critical work AMD always wins.

If all you need is gaming, raster graphics, and decoding/encoding video chats AMD will be the better linux experience (Windows not so much) but Im not confident RDNA4 is in a good spot right now as ive heard some not nice things. It seems that currently RDNA3 is the golden child if you want a stable linux experience. My previous laptop (it died so had to replace it) had an RX7700s (aka RX7600XT ish) and it was an overall joy to use on Linux minus ROCM being kinda crap to deal with.