kernel 7.0.3 + nvidia-open 595.71.05 on RTX 3090: `__nv_drm_gem_nvkms_map` requests range exceeding PCI BAR1 → Xid 31 → Xid 154 (Node Reboot Required) under Chromium GPU workload

### NVIDIA Open GPU Kernel Modules Version 595.71.05 (Arch package nvidia-open-dkms 595.71.05-2) ### 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 (rolling release) ### Kernel Release Linux host 7.0.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000 x86_64 GNU/Linux ### Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels. - [x] I am running on a stable kernel release. ### Hardware: GPU GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-) ### Describe the bug On a single-GPU RTX 3090 desktop running Linux 7.0.3 with `nvidia-open-dkms` 595.71.05, the kernel logged a `resource sanity check` warning naming `__nv_drm_gem_nvkms_map` as the caller of an mmap that "spans more than" the device's BAR1 region. The same instant, the GPU took an MMU fault on Copy Engine 2 (Xid 31) and the driver self-declared the GPU unrecoverable (Xid 154, "Node Reboot Required") with `uvm encountered global fatal error 0x60`. GSP RPC then timed out (Xid 175). The display compositor's vblank stalled, the screen froze, and neither `nvidia-smi` nor `systemctl reboot` could complete; recovery required a hardware power-cycle. The trigger workload was a Chromium-based browser (Brave) starting a new renderer process. ### To Reproduce - Wayland compositor (Hyprland) running, ~2 hours uptime since boot - Brave (Chromium-based browser) open with several tabs - Brave subprocess started a new renderer/GPU process — call stack shows Chromium worker thread deep in kperfBoostSet_IMPL → rpcRmApiControl_GSP → _kgspRpcRecvPoll, consistent with a GPU-frequency-boost RPC during renderer spin-up - No CUDA process active; no userspace had /dev/nvidia-uvm open - System RAM healthy: 7.6 GiB / 61 GiB used, no swap pressure - Single occurrence so far; not yet a deterministic reproducer - See "Smoking-gun evidence" and "Fault sequence" in More Info below ### Bug Incidence Once ### nvidia-bug-report.log.gz [nvidia-bug-report.log.gz](https://github.com/user-attachments/files/27489540/nvidia-bug-report.log.gz) ### More Info Note: I have not tested with the proprietary nvidia-dkms package, so I have left the proprietary-driver-confirmation checkbox unchecked. The kernel's own `resource sanity check` warning names `__nv_drm_gem_nvkms_map+0x99/0xf0 [nvidia_drm]` as the caller, which is specific to nvidia-open's DRM layer. I am happy to test the proprietary driver if maintainers think it would help isolate the regression.

Smoking-gun evidence

Single line, logged by the kernel core (not by NVRM) at t = 0:

The requested range starts ~3 MiB before the end of BAR1 (0xfcc0000000-0xfccfffffff) and runs ~33 MiB past it, into BAR3 (0xfcd0000000 + 32 MiB). The kernel's PCI resource validation rejects the request, and the subsequent [drm:__nv_drm_gem_nvkms_map] *ERROR* Failed to map NvKmsKapiMemory 0x00000000616506ff confirms the map failed.

Immediately preceding this, NVRM logged ~25 repetitions of:

so BAR1 VA space was being repeatedly exhausted in the seconds leading up to the bad-range request. That suggests the bad mapping is a fallback (or an arithmetic mistake) on the BAR1-VA-exhausted path rather than a random misuse of pci_resource_*.

Fault sequence

All times relative to t = 0 (the resource sanity check line above). Full redacted log in kernel-log-excerpt.txt.

Offset | Event -- | -- t+0:00:00 | resource sanity check, __nv_drm_gem_nvkms_map ... mapping multiple BARs, Failed to map NvKmsKapiMemory. t+0:00:00 | Xid 31 — MMU Fault: ENGINE CE2 HUBCLIENT_CE0 faulted @ 0x1_21000000, FAULT_PTE ACCESS_TYPE_VIRT_WRITE. t+0:00:00 | nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover. t+0:00:00 | Xid 154 — GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required). t+0:00:00 | Brave GPU subprocess receives SIGILL (trap invalid opcode ... in brave[...]). t+0:00:01 | [drm:nv_drm_atomic_apply_modeset_config] Failed to initialize semaphore for plane fence, nv_drm_atomic_commit Error code: -11. t+0:01:15 | _kgspIsHeartbeatTimedOut: diff 75117 timeout 5200. GSP heartbeat lost. t+0:01:45 | Memory Subsystem Error detected. kgmmuInvalidateTlb failed. t+0:01:45 | Xid 175 — Timeout after 75s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL). Originating thread name ThreadPoolSingl (Chromium worker). t+0:01:48 | Call trace dumped: _kgspRpcRecvPoll → _issueRpcAndWait → rpcRmApiControl_GSP → kperfBoostSet_IMPL → resControl_IMPL → ... → nvidia_unlocked_ioctl. t+0:01:48 onward | RC watchdog: GPU is probably locked! Notify Timeout Seconds: 7 repeats every 30-60 s. Hundreds of NV_ERR_RESET_REQUIRED assertions firing as the fullchip-reset path itself fails its preconditions. t+0:06:18 | Xid 16, Head 00000003 Count ..., RM has detected that 7 Seconds without a Vblank Counter Update on head:D0. Display visibly froze. t+0:12:48 | Second Xid 16 / vblank-watchdog.

Recovery