NVIDIA / NVIDIA/open-gpu-kernel-modules

595.71.05: VA-space exhaustion in reuse-mapping DB wedges a channel; RC recovery never completes; process becomes unkillable

Open
#1,270 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
17.4k
Forks
1.9k
PR merge metrics
No merged PRs in 30d

Description

nvidia-bug-report.log.gz

System

  • GPU: NVIDIA GeForce RTX 5060 Ti (GB206, PCI 10de:2d04 rev a1)
  • Driver: 595.71.05, open kernel modules, CUDA 13.2
  • Kernel: 7.0.0-28-generic, Ubuntu 26.04 LTS, Wayland (GNOME) desktop on the same GPU
  • Workload: gnome-remote-desktop 50.0 (RDP server) encoding AVC420 via its CUDA/NVENC
    hardware path, streaming continuously to one client

Summary

After ~27 hours of continuous RDP streaming, the driver's reuse-mapping DB fails VA
allocation (mapping_reuse.c:273, NV_ERR_NO_MEMORY) while device VRAM is nearly
empty (1.5 GiB / 16 GiB). The channel that hit the failure wedges, RC recovery never
completes (krcWatchdog_IMPL: RC watchdog: GPU is probably locked! repeating every
~8 s, 150+ occurrences and counting), and the owning process can no longer be killed:
SIGKILL is delivered but a thread never returns from the driver ioctl, so the device
stays open, which in turn makes nvidia-smi --gpu-reset / module reload impossible.
Only a full reboot recovers. Display output on other channels keeps working the whole
time.

Two independent defects from one incident:

  1. A VA/mapping leak (or unbounded reuse-mapping DB growth) under long-running
    map/unmap-heavy CUDA interop — VRAM stays low while VA space for mappings runs out.
  2. RC recovery livelock: the watchdog detects the locked channel every 8 s but never
    recovers it, and the stuck ioctl makes the process unkillable, so there is no
    userspace path back to a working GPU.

Timeline (kernel + service logs)

  • Jul 31 06:27:08 — gnome-remote-desktop starts; [HWAccel.CUDA] Initialization of CUDA was successful; streaming works for ~27 h.
  • Aug 01 09:11:25 — kernel: repeated
    NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping. (22 total) and
    NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from pReuseMappingDb->pMapCb(...) @ mapping_reuse.c:273
  • Aug 01 09:11:36 — kernel: first
    NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked! Notify Timeout Seconds: 7 — repeats every ~8 s from then on (154 at the time of writing).
  • Aug 01 09:11:47 — gnome-remote-desktop: [HWAccel.CUDA] Failed to map resources: the launch timed out and was terminated; from here every new RDP connection fails
    with Failed to create stream: the launch timed out and was terminated
    Layout manager: Failed to prepare surface contexts → session closed with
    ERRINFO_CLOSE_STACK_ON_DRIVER_FAILURE.
  • Aug 01 09:19 — systemctl --user restart gnome-remote-desktop hangs in
    deactivating; explicit SIGKILL delivered, process (PID 4003622) never exits;
    no D-state threads reported, but the task never leaves the driver.
  • GPU state throughout: display fine, nvidia-smi responsive, P1, 0% util,
    1566 MiB / 16311 MiB used; no Xid events logged at any point.

Expected behavior

  • The mapping DB should not exhaust VA space under a steady map/unmap workload
    (or should fail gracefully long before wedging a channel).
  • RC recovery should tear down the faulted channel so the process can exit and the
    device can be reset without rebooting.

Reproduction

Long-running gnome-remote-desktop RDP session with the CUDA/NVENC path on Blackwell +
open modules; failure appeared after ~27 h of continuous streaming. Not yet re-run to
confirm the period.

Attachments

  • nvidia-bug-report.log.gz captured while the GPU was in the wedged state will be
    attached in a follow-up comment (one shell working-directory path redacted from a
    sudo journal line; nothing else modified).
  • Full journal excerpts available on request.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with mapping_reuse.c:273 and the attached nvidia-bug-report.log.gz; trace the VA allocation failure alongside the repeated krcWatchdog_IMPL messages. Compare the long-running gnome-remote-desktop CUDA/NVENC reproduction and determine whether both reported failures are addressed, including recovery without reboot.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux, ubuntu
Domain
operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.