RTX 5090 (Blackwell): nvidia-drm "Failed to get memory pages for NvKmsKapiMemory" accrues over uptime → KWin/X11 GPU context reset & freeze (no Xid), open 595.71.05

NVIDIA Open GPU Kernel Modules Version

RTX 5090 (Blackwell): nvidia-drm "Failed to get memory pages for NvKmsKapiMemory" accrues over uptime → KWin/X11 GPU context reset & freeze (no Xid), open 595.71.05

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

Ubuntu 24.04.4 LTS

Kernel Release

6.17.0-35-generic (x86_64)

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 5090 (PCI 10de:2b85)

Describe the bug

nvidia-drm: "Failed to get memory pages for NvKmsKapiMemory" leading to GPU context reset / desktop freeze (RTX 5090, open kernel modules)

Summary

On an RTX 5090 using the open kernel modules, nvidia-drm repeatedly logs:

[drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x<addr>

These accrue over time and eventually culminate in a full GPU context-loss event that freezes the desktop: every OpenGL client loses its context (GL_GUILTY_CONTEXT_RESET_KHR) and the KWin (X11) compositor stops repainting until manually replaced. No Xid error is ever logged for these events.

Upgrading within the same driver branch (595.58.03 → 595.71.05) did not resolve it.

The error

Logged by the open nvidia_drm module from __nv_drm_nvkms_gem_obj_init:

kernel: [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2

Verbatim sample with wall-clock timestamps (dmesg -T), current boot — note all faults cluster at session/compositor startup and each address is logged twice:

[Fri May 29 13:01:31 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2
[Fri May 29 13:01:31 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2
[Fri May 29 13:01:35 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000009af5430f
[Fri May 29 13:01:35 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000009af5430f

Also seen alongside it:

kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us N times, consider switching to WQ_UNBOUND

To Reproduce

Reproduction

1. RTX 5090 with open kernel modules, KDE Plasma X11 session driving displays via the NVIDIA provider on a hybrid Intel+NVIDIA system.
2. Use the desktop normally for an extended period (hours to a couple of days).
3. Observe Failed to get memory pages for NvKmsKapiMemory accumulating in dmesg/journal.
4. Eventually a GPU context-loss event freezes the compositor; GL clients report GL_GUILTY_CONTEXT_RESET_KHR.

Bug Incidence

Sometimes

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

nvidia-drm: "Failed to get memory pages for NvKmsKapiMemory" leading to GPU context reset / desktop freeze (RTX 5090, open kernel modules)

Summary

On an RTX 5090 using the open kernel modules, nvidia-drm repeatedly logs:

[drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x<addr>

These accrue over time and eventually culminate in a full GPU context-loss event that freezes the desktop: every OpenGL client loses its context (GL_GUILTY_CONTEXT_RESET_KHR) and the KWin (X11) compositor stops repainting until manually replaced. No Xid error is ever logged for these events.

Upgrading within the same driver branch (595.58.03 → 595.71.05) did not resolve it.

System

GPU	NVIDIA GeForce RTX 5090 (PCI 10de:2b85, subsystem 10de:2057), VBIOS 98.02.2E.00.03
Driver	595.71.05 (open kernel module; also reproduced on 595.58.03)
Kernel module flavour	nvidia-driver-595-open / nvidia-kernel-source-595-open (open GPU kernel modules)
Kernel	6.17.0-35-generic (Ubuntu HWE)
Distro	Ubuntu 24.04.4 LTS
Desktop	KDE Plasma 5.27.12 / KWin 5.27.11, X11 session
Graphics topology	Hybrid: Intel Arrow Lake iGPU (i915/modesetting) + RTX 5090 via PRIME; NVIDIA is the X Source Output provider (NVIDIA-0) driving the displays
PCIe link	Gen1 x16 (current; see note below)

The error

Logged by the open nvidia_drm module from __nv_drm_nvkms_gem_obj_init:

kernel: [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2

Verbatim sample with wall-clock timestamps (dmesg -T), current boot — note all faults cluster at session/compositor startup and each address is logged twice:

[Fri May 29 13:01:31 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2
[Fri May 29 13:01:31 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000000878c6a2
[Fri May 29 13:01:35 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000009af5430f
[Fri May 29 13:01:35 2026] [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x000000009af5430f

Also seen alongside it:

kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us N times, consider switching to WQ_UNBOUND

Frequency / correlation with session length

Counts of NvKmsKapiMemory faults per boot (journalctl -k -b <N> | grep -c NvKmsKapiMemory):

Boot	Session length	Faults
current (fresh)	~1 min so far	4
previous	~2.3 days	50 — ended in the freeze below
earlier	~13 h	14

The faults appear from session startup onward and continue to accrue during normal desktop use. The longest-running session accumulated the most and is the one that hard-froze.

The cascade (what the user sees)

During the long session, after the faults had been recurring for hours, a GPU context-loss event hit and the whole desktop froze. Representative log excerpts from that window:

plasmashell[pycharm]: UI was frozen for 42295ms
firefox: [GFX1-]: Detect DeviceReset DeviceResetReason::RESET
chromium/electron: SharedContextState context lost via ARB/EXT_robustness.
                   Reset status = GL_GUILTY_CONTEXT_RESET_KHR
chromium/electron: Exiting GPU process because some drivers can't recover from errors
gpu_process_host: GPU process exited unexpectedly: exit_code=8704   (looped, restarting)

KWin (X11) stopped repainting and did not recover on its own. Workaround: kwin_x11 --replace re-establishes a GL context and unfreezes the desktop without ending the session; all GL clients (browsers, Electron apps) that hit the guilty-context reset had to be restarted individually.

What is NOT happening

• No Xid errors are logged at any point (journalctl -k | grep -i Xid is empty), so this does not present as a classic GPU exception/fault — it's specifically a KMS GEM-object memory-page acquisition failure in the display path.
• No PCIe errors. AER and device-status counters are all clean (lspci -vvv): DevSta: CorrErr- NonFatalErr- FatalErr-, UESta: all clear, CESta: all clear. No pcieport/AER messages in dmesg. So this is not a bus/link-error event.
• GPU is otherwise idle/cool when it happens (e.g. 0% util, ~36 °C) — not a thermal or load event.

PCIe / memory-mapping state (root diagnostics)

• PCIe link: LnkCap: Speed 32GT/s, Width x16 (Gen5), trained successfully (EqualizationComplete+ EqualizationPhase1+). Currently LnkSta: Speed 2.5GT/s (downgraded), Width x16 — i.e. Gen1 at idle (P8 power state); expected ASPM downclock, should ramp under load.
• Resizable BAR working: BAR 1 [mem ... 64bit pref] is the full 32 GB VRAM aperture and is assigned successfully.
• SR-IOV VF BAR assignment failures at boot:

  pci 0000:02:00.0: VF BAR 2 [mem size 0x10000000 64bit pref]: can't assign; no space
  pci 0000:02:00.0: VF BAR 2 [mem size 0x10000000 64bit pref]: failed to assign
  pci 0000:02:00.0: VF BAR 4 [mem size 0x02000000 64bit pref]: can't assign; no space
  pci 0000:02:00.0: VF BAR 4 [mem size 0x02000000 64bit pref]: failed to assign
  

  The VFs themselves are unused on this consumer card, but flagging this as an MMIO address-space-pressure signal in case it's related to the later NvKmsKapiMemory page-acquisition failures (cf. BAR/VA-space issues in #1134, #1140).

Reproduction

1. RTX 5090 with open kernel modules, KDE Plasma X11 session driving displays via the NVIDIA provider on a hybrid Intel+NVIDIA system.
2. Use the desktop normally for an extended period (hours to a couple of days).
3. Observe Failed to get memory pages for NvKmsKapiMemory accumulating in dmesg/journal.
4. Eventually a GPU context-loss event freezes the compositor; GL clients report GL_GUILTY_CONTEXT_RESET_KHR.

Notes / questions for maintainers

• Is __nv_drm_nvkms_gem_obj_init failing to pin/get pages a known issue on the open modules for Blackwell (RTX 5090)?
• Could the SR-IOV VF BAR assignment failures ("can't assign; no space", see above) indicate MMIO address-space pressure that contributes to the NvKmsKapiMemory page-acquisition failures, or are they unrelated/benign on this card?
• Anything in the hybrid-PRIME display-offload configuration (Intel iGPU + NVIDIA Source Output provider) that could aggravate this?

Related reports / how this differs

I searched the open-gpu-kernel-modules tracker and the NVIDIA Linux forum before filing. There is no exact duplicate (RTX 5090 / X11 / steady-state NvKmsKapiMemory page-acquisition accrual ending in compositor context-loss, with no Xid), but several adjacent reports form a cluster:

• open-gpu-kernel-modules #1137 — freeze on the same open driver 595.71.05. Different trigger (suspend/resume, Wayland+GNOME), but same driver/module and freeze outcome.
• open-gpu-kernel-modules #1140 — RTX 4090 GPU lock after ~7 days uptime. Same "fault accrues over long uptime → eventual lock" shape (different mechanism: VA-space exhaustion).
• open-gpu-kernel-modules #1010 — RTX 5070 Ti PCIe link falls back to Gen1 on Linux. Corroborates the Gen1 x16 observation above on Blackwell.
• open-gpu-kernel-modules #1163 — hybrid-graphics modeset/DRM-master contention (NVIDIA+AMD; this report is NVIDIA+Intel).
• Forum t/176712 — the original "Failed to get memory pages for NvKmsKapiMemory" thread; same error string but old hardware (GTX 1660, 2021), showing the fault path predates Blackwell.
• Forum t/361991 — recent (590 branch, Wayland) crashes that NVIDIA staff traced to Xid 79 ("GPU has fallen off the bus") and attributed to power/thermal/BIOS/seating.

Important distinction from the Xid-79 class (t/361991): this system logs no Xid of any kind, the GPU is idle and cool (~36 °C, 0% util) when the faults occur, power/thermals are nominal, and it reproduces across a fresh driver+kernel install. So the "check PSU / BIOS / reseat the card" hardware path does not apply here — the failure is isolated to the nvidia-drm KMS GEM-object page-acquisition path.

(Full nvidia-bug-report.log.gz attached — see posting instructions.)

Start with the nvidia-drm path at __nv_drm_nvkms_gem_obj_init and reproduce it on the listed RTX 5090, Ubuntu, and X11 setup while collecting dmesg and the attached nvidia-bug-report.log.gz. Compare the recurring page-acquisition failures with the later context loss; done means identifying a reproducible root cause and a validated fix or clear maintainer diagnosis.