System Environment & Specifications
- Host OS: Fedora Linux 44 (KDE Plasma Desktop Edition)
- Kernel: Linux 7.2.5-200.fc44.x86_64 (Preempt Dynamic)
- Windowing System / Compositor: KWin Wayland session
- GPU Hardware: NVIDIA GeForce GTX 1650 Mobile (4GB VRAM / GM107/Turing Hybrid Architecture)
- Driver Version: 615.71.09 (RPM Fusion proprietary package using the auto-loaded open kernel modules backend)
- Compiler Backend: GCC version 16.2.1 20260819 (Red Hat 16.2.1-2)
- Vulkan API Loader: 1.4.341
- Active Configurations: Kernel Mode Setting enabled (modeset=1), Framebuffer Emulation active (fbdev=1), Driver Persistence Mode set to Off.
Problem Description
A critical driver deadlock occurs strictly during active gaming sessions (e.g., executing Vulkan or Direct3D titles like Counter-Strike 2 translated via Proton/DXVK runtime engines). The crash violently terminates the game loop at the application layer, throwing a fatal VK_ERROR_DEVICE_LOST exception.
Simultaneously, the underlying driver encounters a catastrophic corruption within its Virtual Address (VA) memory allocator. This triggers a loop of failed Translation Lookaside Buffer (TLB) flushes, leading directly to an absolute hardware bus separation event (Xid 79). Once the failure condition occurs, the GPU firmware crashes completely, leaving the card entirely invisible to the host operating system (“No devices were found”). The kernel remains trapped in an infinite loop of failed module resets, completely breaking system shutdown or restart behaviors until forced via a physical cold power cycle.
Step-by-Step Chronological Crash Sequence
Phase 1: Application Layer Breakdown (While Gaming)
During heavy graphic allocation workloads, the dynamic shader translation structures passed by Proton crash because the memory address mapping boundaries beneath them suddenly evaporate. The application instantly faults out with a lost rendering context:
Process 54365 (cs2) dumped core.
Stack Trace: librendersystemvulkan.so + 0x5e9b67 / _ZN7CThread10ThreadProcEPv
Application Result: VK_ERROR_DEVICE_LOST
Phase 2: Driver Virtual Memory Mapping Defect
The origin point of the failure begins inside the Open Kernel module memory layer (virt_mem_allocator_gm107.c). The allocation engine drops pointer records or corrupts block graphs across Wayland synchronization boundaries, causing page-walk memory allocations to instantly fail validation:
kernel: NVRM: nvAssertFailedNoLog: Assertion failed: NULL != pIter->pMap @ virt_mem_allocator_gm107.c:2026
kernel: NVRM: mmuWalkMap: Failed to map/unmap VA Range 0x13ca00000 to 0x14c9fffff. Status = 0x00000040
kernel: NVRM: dmaAllocMapping_GM107: can’t update VA space for mapping @vaddr=0x13ca00000
Phase 3: High-Frequency TLB Invalidation Deadlock
Because virtual map tracking nodes are now corrupted, the GPU’s memory management unit enters an infinite loop trying to purge stale addresses. The page-table walk tree collapses completely, causing consecutive cache flush commands to hit rigid timeout walls:
kernel: NVRM: GPU0 kgmmuInvalidateTlb_GM107: TLB invalidation failed waiting for prior invalidate (status=0x0000000f), vaspaceFlags 0x101, scope 0x2, GFID 0
kernel: NVRM: GPU0 nvAssertFailedNoLog: Assertion failed: pEntries != NULL @ gmmu_walk.c:842
kernel: NVRM: GPU0 nvAssertFailedNoLog: Assertion failed: progress == entryIndexHi - entryIndexLo + 1 @ mmu_walk.c:1240
Phase 4: Hardware Bus Separation (Xid 79)
The unresolvable memory deadlock starves the internal hardware channels. To protect the silicon states from systemic failure, the card’s firmware enforces a total chip reset and severs its physical PCIe lane connection from the kernel:
kernel: NVRM: GPU at PCI:0000:01:00: GPU-3c8f9728-f0ba-edce-2359-d9c07da08670
kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
kernel: NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
Phase 5: Infinite Driver Reset Loop
With the hardware physically gone, the core driver is unable to conclude the recovery process. Remote Procedure Calls (RPC) to the GSP/Firmware layer time out permanently, completely breaking system daemon tracking:
kernel: NVRM: GPU0 _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 76
nvidia-powerd: ERROR! Exception NvRm failed with error Unknown Error and RM Error Code 86
nvidia-powerd: ERROR! Failed to get AC Line status
At this final stage, executing nvidia-smi returns: “Unable to determine the device handle for GPU0: Unknown Error. No devices were found.”
Engineering Diagnostic Questions
- Is this specific virtual address allocator failure inside virt_mem_allocator_gm107.c a known architecture regression tracking across legacy non-RTX cards (GM107 blocks) on modern Wayland compositors using the 610/615 open module branch?
- The core crash occurs even when physical video memory allocations are not fully saturated. Is there an internal mapping allocation size node limit being reached by dynamic DXVK translation streams?
- While the workaround of setting options nvidia NVreg_PreserveVideoMemoryAllocations=1 and overriding NVreg_TemporaryFilePath=/var/lib/systemd/sleep mitigates soft context drops, will it reliably solve hard mapping deadlocks and Xid 79 hardware panics once the open module allocator structures become fragmented?
(I have run the script suite and attached my full, unedited nvidia-bug-report.log.gz archive to this thread layout for deep code review).
nvidia-bug-report.log.gz (1.1 MB)