RTX 5070: virtual address space becomes corrupted, leading to stale entries blocking allocation requests, thrashing, and poor gaming performance

[WoolieWool]

NVIDIA Open GPU Kernel Modules Version

nvidia-open-dkms 610.43.03-3

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Arch Linux

Kernel Release

7.1.4-zen1-1-zen

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

NVIDIA GeForce RTX 5070 (UUID: GPU-309087c4-4acd-bb18-ee9e-2cf7acd220f9)

Describe the bug

I had been playing a Skyrim modlist recently and had noticed very inconsistent performance. Sometimes, my framerate would be locked at 60 fps and it would be an excellent experience, but at other times framerates would drop, and they would drop regardless of the complexity of the scene, the number of actors on screen, etc. Since my second screen has a panel of widgets monitoring resource management, I noticed that, during the degraded performance states, GPU usage was pegged at 100%. Further investigation revealed that bad performance became increasingly likely, and eventually guaranteed, over the course of a session on the computer, even when the game was closed and restarted, with only a reboot able to put the issue in abeyance temporarily. Running applications like Firefox or Discord that used GPU acceleration was likely to make the issue happen, as well as doing things like browsing through Steam screenshots. Closing these programs occasionally gave some relief, but the odds were less than even.

I went back and forth with Claude a number of times with various diagnostics, ruling out things like the GPU being stuck in a low-power/low-clock state, until these lines from journalctl provided the smoking gun:

Jul 29 01:15:16 CALIF-RAYZEN kernel: NVRM: nvCheckFailedNoLog: Check failed: 0 == (pMapNode->gpuMask & gpuMask) @ gpu_vaspace.c:4547
Jul 29 01:15:16 CALIF-RAYZEN kernel: NVRM: nvCheckOkFailedNoLog: Check failed: Invalid argument to call [NV_ERR_INVALID_ARGUMENT] (0x0000001F) retu>
Jul 29 01:15:16 CALIF-RAYZEN kernel: NVRM: nvCheckFailedNoLog: Check failed: NV_OK == status @ virt_mem_allocator_gm107.c:2558
Jul 29 01:15:16 CALIF-RAYZEN kernel: NVRM: dmaAllocMapping_GM107: can't update VA space for mapping @vaddr=0x1d2c00000
Jul 29 01:21:47 CALIF-RAYZEN kernel: NVRM: GPU0 rpcRmApiAlloc_GSP: GspRmAlloc failed: hClient=0xc1d00012; hParent=0xbeef0003; hObject=0xcef8000b; h>
Jul 29 01:21:47 CALIF-RAYZEN kernel: NVRM: GPU0 kchangrpapiConstruct_IMPL: KernelChannelGroupApi alloc RPC to vGpu Host failed
Jul 29 01:21:47 CALIF-RAYZEN kernel: NVRM: GPU0 rpcRmApiAlloc_GSP: GspRmAlloc failed: hClient=0xc1d00012; hParent=0xbeef0003; hObject=0xcef8000b; h>
Jul 29 01:21:47 CALIF-RAYZEN kernel: NVRM: GPU0 kchangrpapiConstruct_IMPL: KernelChannelGroupApi alloc RPC to vGpu Host failed
Jul 29 01:21:56 CALIF-RAYZEN kernel: NVRM: GPU0 rpcRmApiAlloc_GSP: GspRmAlloc failed: hClient=0xc1d00012; hParent=0xbeef0003; hObject=0xcef8000b; h>
Jul 29 01:21:56 CALIF-RAYZEN kernel: NVRM: GPU0 kchangrpapiConstruct_IMPL: KernelChannelGroupApi alloc RPC to vGpu Host failed
Jul 29 01:21:57 CALIF-RAYZEN kernel: NVRM: GPU0 rpcRmApiAlloc_GSP: GspRmAlloc failed: hClient=0xc1d00012; hParent=0xbeef0003; hObject=0xcef8000b; h>
Jul 29 01:21:57 CALIF-RAYZEN kernel: NVRM: GPU0 kchangrpapiConstruct_IMPL: KernelChannelGroupApi alloc RPC to vGpu Host failed

I don't really have the technical knowledge to describe Claude's interpretation of this accurately, so I'll give it straight from the robot's mouth:

"That journalctl output is the payoff of this whole investigation, and it's an exact match to a real, currently-reported bug — not something specific to your setup. The precise log lines you got (nvCheckFailedNoLog: Check failed: 0 == (pMapNode->gpuMask & gpuMask) @ gpu_vaspace.c, dmaAllocMapping_GM107: can't update VA space for mapping) appear essentially verbatim in a GitHub issue about NVIDIA's GPU virtual address space bookkeeping failing, and the second batch (GspRmAlloc failed, KernelChannelGroupApi alloc RPC to vGpu Host failed) is a known signature of the GSP firmware — the onboard microcontroller that current NVIDIA Linux drivers offload resource management to — failing to service a new GPU context/channel request."

The GitHub issue is reported for hyperlock, linked below:
hyprwm/hyprlock#831
(I can confirm I have experienced this bug too, and it among other issues eventually drove me to move back to KDE from hyprland)

To Reproduce

1. Install a heavy Skyrim modlist like Gate to Sovngarde, Lorerim, etc. using Jackify or other means (another heavy game should do the trick too).
2. Playing it in a freshly booted session should give good performance.
3. Do things like browse YouTube videos on several tabs in your browser, play other games, etc.
4. Running Skyrim after this point should trigger the bug at some point, though it is very unpredictable. The longer your session lasts and the more GPU-heavy programs you open in it, the worse the problem should become, even if you close those programs later.
5. Keep doing this and eventually Skyrim will likely become unplayable, or even start freezing.

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

I have very limited space to test other games with as most of my mass storage is NTFS formatted and is only suitable for gaming under Windows. I will be installing games one at a time to my ext4 partition and testing them too as time permits.

[WoolieWool]

Further information to note: loading a saved game inside a building in Whiterun or another big city (but especially Whiterun since modlists tend to lard it with many, many mods) and then going outside is very likely to trigger the bug as the game will try to allocate a huge amount of memory all at once. Adding more mods to a modlist will make the problem worse; your game will become unplayable due to this bug long before the GPU itself runs out of headroom, as it tries to burst-load even more assets, making the bug that much more likely to hit you.