That particular app, Spectacle, may be broken, but…
Screen recording in general is working fine with 580.
I use gpu-screen-recorder on Hyprland and Sway.
grim + slurp for static screenies.
And gpu screen recorder reports this issue is a Plasma issue, and Plasma has indicated they have no intention to “fix” it. It’s a breakage of DRM capture.
Going forward, on Plasma at least, Pipewire capture will have to be used. Pipewire 1.6.0 should support HDR capture now, as long as client software implements it. Well, and maybe Plasma has to implement support for it still? I think there’s an unmerged MR for it?
Interesting. I know nothing of KDE/plasma.
I was more responding to the generalization, “screen recording remains broken for NVIDIA users”, which is false.
Screencap, pipewire and Wayland protocols are an evolving space.
Hyprland recently implemented image-capture-source-v1 and image-copy-capture-v1 protos, breaking wf-recorder.
That’s why I switched to gpu-screen-recorder. Working well here on latest git. Didn’t realize it was busted on Plasma.
Thanks for the clarification guys.
It works out of the box on AMD/Intel integrated graphics.
I understand and i say this as a moderately experienced Linux user - At the end of the day, for a regular user, a basic feature like this should just work out of the box, without any third-party tools bolted on.
Title: nvidia 580.126.18 crashes with GPF in __kmalloc_noprof during module init on kernel 6.18.14+ (Fedora 43, RTX 4060 Mobile)
System:
Problem:
The nvidia driver crashes during module initialization (nv_drm_probe_devices) with a general protection fault in __kmalloc_noprof, called from nvidia’s os_alloc_mem. This happens non-deterministically — roughly 3 out of 4 boot attempts crash, and the system never reaches the login screen (GDM starts but nvidia_drm fails to set up the display).
The crash is a race condition — different garbage non-canonical addresses appear each time (0x747b6c1f23fb25a1, 0xd47ffec1311bdfa2), suggesting slab freelist pointer corruption. The same driver version (580.126.18) works reliably on kernel 6.18.12.
I suspect this is related to the slab allocator “sheaves” changes introduced in kernel 6.18 (kfree_rcu batching via kvfree_rcu_barrier()), which had a known performance regression affecting module loading. The corruption may be triggered by nvidia’s os_alloc_mem → kmalloc path racing with slab cache operations during the init_module phase.
Reproduction:
Crash pattern across 4 consecutive boots (all kernel 6.18.16):
| Boot | Crash? | Signature |
|---|---|---|
| 1 | Yes — Oops #1, #2, #3 | GPF in __kmalloc_noprof + page fault in _mapInsertBase [nvidia] |
| 2 | Yes — Failed to allocate NvKmsKapiDevice |
oops deleted by abrt |
| 3 | Yes — Oops #1, #2 | GPF in __kmalloc_noprof + page fault in _mapInsertBase [nvidia] |
| 4 | No | nvidia 580.126.18 loaded successfully |
Oops from boot 3 (representative):
NVRM: Xid (PCI:0000:64:00): 31, pid=1278, name=(udev-worker), channel 0x00000003, intr 00000000. MMU Fault: ENGINE GR0_PBDMA0 HUBCLIENT_ESC faulted @ 0x59_f8cc2000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
Oops: general protection fault, probably for non-canonical address 0xd47ffec1311bdfa2: 0000 [#1] SMP NOPTI
CPU: 15 UID: 0 PID: 1278 Comm: (udev-worker) Tainted: G OE 6.18.16-200.fc43.x86_64 #1 PREEMPT(lazy)
Hardware name: ASUSTeK COMPUTER INC. ASUS TUF Gaming A14 FA401WV_FA401WV/FA401WV, BIOS FA401WV.319 03/25/2025
RIP: 0010:__kmalloc_noprof+0x4bc/0x780
Call Trace:
<TASK>
os_alloc_mem+0x104/0x120 [nvidia]
_portMemAllocNonPagedUntracked+0x2c/0x40 [nvidia]
_portMemAllocatorAlloc+0x2b/0xe0 [nvidia]
multimapInsertItemNew_IMPL+0x40/0xa0 [nvidia]
multimapInsertItemValue_IMPL+0x20/0x80 [nvidia]
indexAdd+0x4c/0xa0 [nvidia]
_clientAllocResourceHelper+0x539/0x660 [nvidia]
serverAllocResourceUnderLock+0x33b/0xa10 [nvidia]
serverAllocResource+0x2b4/0x5c0 [nvidia]
rmapiAllocWithSecInfo+0x1f0/0x420 [nvidia]
rmapiAllocWithSecInfoTls+0x65/0x90 [nvidia]
_nv04AllocWithAccess+0x7c/0xb0 [nvidia]
nvkms_call_rm+0x4c/0x80 [nvidia_modeset]
nvRmApiAlloc+0x46/0x50 [nvidia_modeset]
nvPushAllocDevice+0x3a9/0x470 [nvidia_modeset]
nvAllocNvPushDevice+0xe2/0x150 [nvidia_modeset]
nvRmAllocDeviceEvo+0xb3a/0xbe0 [nvidia_modeset]
nvAllocDevEvo+0xca/0x390 [nvidia_modeset]
AllocDevice+0x55e/0x590 [nvidia_modeset]
nvKmsIoctl+0xf2/0x240 [nvidia_modeset]
nvkms_ioctl_from_kapi+0x6f/0xe0 [nvidia_modeset]
AllocateDevice+0x313/0x760 [nvidia_modeset]
nv_drm_dev_load+0xb0/0x45d [nvidia_drm]
nv_drm_register_drm_device.cold+0x15/0x10d [nvidia_drm]
EnumerateGpus+0x151/0x160 [nvidia_modeset]
nv_drm_probe_devices+0x5c/0x70 [nvidia_drm]
do_one_initcall+0x5b/0x300
do_init_module+0x84/0x280
init_module_from_file+0x8a/0xe0
idempotent_init_module+0x114/0x310
__x64_sys_finit_module+0x6d/0xd0
</TASK>
Second oops (same boot, nvidia worker thread):
BUG: unable to handle page fault for address: ffffcf4682aab188
Oops: Oops: 0000 [#2] SMP NOPTI
CPU: 18 UID: 0 PID: 1546 Comm: nv_queue Tainted: G D OE
RIP: 0010:_mapInsertBase+0x3c/0x310 [nvidia]
Workarounds tried:
Requested: Fix for compatibility with kernel 6.18.14+ slab allocator changes, or guidance on whether NVreg_EnableGpuFirmware=0 or other module parameters would help avoid this race.
Can you please quickly test this behavior on latest 595.45.04 driver and share update?
The latest 580.142 driver is unusable with my laptop (GTX 1060). The driver crashes as soon as kwin_wayland attempts to use it:
[ 22.634182] BUG: kernel NULL pointer dereference, address: 0000000000000028
[ 22.634190] #PF: supervisor read access in kernel mode
[ 22.634193] #PF: error_code(0x0000) - not-present page
[ 22.634195] PGD 800000011f58e067 P4D 800000011f58e067 PUD 0
[ 22.634201] Oops: Oops: 0000 [#1] SMP PTI
[ 22.634206] CPU: 5 UID: 962 PID: 909 Comm: kwin_wayland Tainted: P S OE 6.19.6-arch1-1 #1 PREEMPT(full) a70f585a3574c37bff18875a6cf7bd8652b4cbca
[ 22.634212] Tainted: [P]=PROPRIETARY_MODULE, [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 22.634214] Hardware name: Micro-Star International Co., Ltd. GT70 2OC/2OD/MS-1763, BIOS E1763IMS.11D 04/17/2015
[ 22.634217] RIP: 0010:_nv000582kms+0x4/0x10 [nvidia_modeset]
[ 22.634259] Code: 87 50 01 00 00 20 1a 51 c8 48 c7 87 38 01 00 00 70 18 51 c8 48 c7 87 40 01 00 00 40 1c 51 c8 c3 66 0f 1f 44 00 00 f3 0f 1e fa <0f> b6 47 28 c3 0f 1f 80 00 00 00 00 89 c9 48 8d 04 49 48 c1 e0 04
[ 22.634261] RSP: 0018:ffffd3174130f9a8 EFLAGS: 00010206
[ 22.634263] RAX: ffffffffc8512060 RBX: ffff8bb8df5cda00 RCX: 0000040000000000
[ 22.634265] RDX: 0000000000000000 RSI: ffff8bb8f4bc8000 RDI: 0000000000000000
[ 22.634267] RBP: ffffd3174130f9d8 R08: ffff8bb8d29601e8 R09: 0000000000000000
[ 22.634268] R10: ffff8bb8f4bc8028 R11: ffffd3174130f918 R12: 0000000000000000
[ 22.634269] R13: ffff8bb8df5cda08 R14: 0000000000000000 R15: 0000000000000000
[ 22.634271] FS: 00007ff697f9cb80(0000) GS:ffff8bbc53604000(0000) knlGS:0000000000000000
[ 22.634273] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 22.634274] CR2: 0000000000000028 CR3: 000000010025e001 CR4: 00000000001726f0
[ 22.634276] Call Trace:
[ 22.634279] <TASK>
[ 22.634281] nv_drm_framebuffer_create+0x20c/0x450 [nvidia_drm 27a5a7be672e8c5f48b0015257b43f2ed0c4d9aa]
[ 22.634293] drm_internal_framebuffer_create+0x426/0x5a0
[ 22.634297] ? __pfx_drm_mode_addfb2_ioctl+0x10/0x10
[ 22.634300] drm_mode_addfb2+0x45/0x110
[ 22.634303] ? drm_dev_enter+0x1d/0x60
[ 22.634306] drm_ioctl_kernel+0xae/0x100
[ 22.634310] drm_ioctl+0x29b/0x520
[ 22.634313] ? __pfx_drm_mode_addfb2_ioctl+0x10/0x10
[ 22.634316] __x64_sys_ioctl+0x97/0xe0
[ 22.634321] do_syscall_64+0x81/0x610
[ 22.634326] ? __x64_sys_ioctl+0xb1/0xe0
[ 22.634329] ? do_syscall_64+0x81/0x610
[ 22.634331] ? __x64_sys_ioctl+0xb1/0xe0
[ 22.634334] ? do_syscall_64+0x81/0x610
[ 22.634337] ? do_fcntl+0x421/0x8f0
[ 22.634340] ? __x64_sys_fcntl+0x91/0x110
[ 22.634343] ? do_syscall_64+0x81/0x610
[ 22.634345] ? do_syscall_64+0x206/0x610
[ 22.634348] ? __do_sys_getpid+0x1d/0x30
[ 22.634351] ? do_syscall_64+0x81/0x610
[ 22.634355] ? __task_pid_nr_ns+0x5f/0xc0
[ 22.634360] ? __do_sys_getpid+0x1d/0x30
[ 22.634362] ? do_syscall_64+0x81/0x610
[ 22.634365] ? kmem_cache_free+0x508/0x550
[ 22.634370] ? __x64_sys_close+0x3d/0x80
[ 22.634372] ? __task_pid_nr_ns+0x5f/0xc0
[ 22.634375] ? __do_sys_getpid+0x1d/0x30
[ 22.634377] ? do_syscall_64+0x81/0x610
[ 22.634379] ? do_syscall_64+0x81/0x610
[ 22.634382] ? exc_page_fault+0x7e/0x1a0
[ 22.634386] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 22.634389] RIP: 0033:0x7ff69eb2504d
[ 22.634404] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[ 22.634406] RSP: 002b:00007ffdf94286f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 22.634409] RAX: ffffffffffffffda RBX: 00007ffdf94288d4 RCX: 00007ff69eb2504d
[ 22.634410] RDX: 00007ffdf9428780 RSI: 00000000c06864b8 RDI: 0000000000000011
[ 22.634412] RBP: 00007ffdf9428740 R08: 00007ffdf9428930 R09: 000055e168876ab8
[ 22.634413] R10: 00007ff6a1ec02c3 R11: 0000000000000246 R12: 00007ffdf9428780
[ 22.634414] R13: 00000000c06864b8 R14: 0000000000000011 R15: 000055e168876a80
[ 22.634417] </TASK>
[ 22.634418] Modules linked in: uhid cmac algif_hash algif_skcipher af_alg bnep intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp nvidia_drm(POE) nvidia_uvm(POE) nvidia_modeset(POE) kvm_intel iwlmvm dm_zero snd_hda_codec_alc662 snd_hda_codec_realtek_lib snd_hda_codec_nvhdmi snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel kvm mac80211 snd_hda_codec at24 btusb snd_hda_core irqbypass btmtk ptp pps_core btrtl libarc4 rapl iTCO_wdt snd_intel_dspcfg i2c_i801 vfat snd_intel_sdw_acpi btbcm intel_cstate ntfs3 fat mei_hdcp mei_pxp iwlwifi spi_nor snd_hwdep btintel msi_wmi i2c_smbus intel_pmc_bxt intel_uncore psmouse pcspkr i2c_mux sparse_keymap mtd nvidia(POE) snd_pcm iTCO_vendor_support bluetooth snd_timer intel_oc_wdt cfg80211 alx mdio rfkill snd mei_me soundcore drm_ttm_helper mei mousedev joydev mac_hid i2c_dev ntsync ec_sys crypto_user nfnetlink dm_crypt encrypted_keys trusted asn1_encoder tee dm_mod raid0 md_mod rtsx_pci_sdmmc spi_intel_platform mmc_core spi_intel sr_mod
[ 22.634479] ghash_clmulni_intel aesni_intel cdrom rtsx_pci serio_raw lpc_ich hid_gt683r i915 i2c_algo_bit mxm_wmi drm_buddy video wmi ttm intel_gtt drm_display_helper cec
[ 22.634493] CR2: 0000000000000028
[ 22.634505] ---[ end trace 0000000000000000 ]---
[ 22.634509] RIP: 0010:_nv000582kms+0x4/0x10 [nvidia_modeset]
[ 22.634551] Code: 87 50 01 00 00 20 1a 51 c8 48 c7 87 38 01 00 00 70 18 51 c8 48 c7 87 40 01 00 00 40 1c 51 c8 c3 66 0f 1f 44 00 00 f3 0f 1e fa <0f> b6 47 28 c3 0f 1f 80 00 00 00 00 89 c9 48 8d 04 49 48 c1 e0 04
[ 22.634554] RSP: 0018:ffffd3174130f9a8 EFLAGS: 00010206
[ 22.634557] RAX: ffffffffc8512060 RBX: ffff8bb8df5cda00 RCX: 0000040000000000
[ 22.634559] RDX: 0000000000000000 RSI: ffff8bb8f4bc8000 RDI: 0000000000000000
[ 22.634561] RBP: ffffd3174130f9d8 R08: ffff8bb8d29601e8 R09: 0000000000000000
[ 22.634563] R10: ffff8bb8f4bc8028 R11: ffffd3174130f918 R12: 0000000000000000
[ 22.634565] R13: ffff8bb8df5cda08 R14: 0000000000000000 R15: 0000000000000000
[ 22.634567] FS: 00007ff697f9cb80(0000) GS:ffff8bbc53604000(0000) knlGS:0000000000000000
[ 22.634570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 22.634572] CR2: 0000000000000028 CR3: 000000010025e001 CR4: 00000000001726f0
Seeing a full system crash on 580.142 with a Quadro M2000M on a Thinkpad P50 in optimus mode. I was able to reproduce it multiple times and downgrading to prior release worked. Here is my Gentoo bug report about it: https://bugs.gentoo.org/971109 (contains more information about my system configuration).
Like @joecool6666 several people have had the same/similar crashes on arch or arch based Linux. See thread here;
and a paste of my own log from the crash;
Crash happens when connecting monitor to HDMI, or if booted with one connected, as soon as the mouse cursor is moved to the HDMI connector monitor (eg at the login splash screen)
Specs;
OS: EndeavourOS x86_64
Host: Inspiron 15 7000 Gaming
Kernel: Linux 6.19.6-arch1-1
Uptime: 18 mins
Packages: 1588 (pacman)
Display (GSM5AB8): 1920x1080 in 22", 60 Hz [External]
Display (S24B240): 1920x1080 in 24", 60 Hz [External]
Display (LG FULL HD): 1920x1080 in 22", 60 Hz [External] *
DE: KDE Plasma 6.6.2
WM: KWin (Wayland)
CPU: Intel(R) Core™ i5-7300HQ (4) @ 3.50 GHz
GPU 1: NVIDIA GeForce GTX 1050 Mobile [Discrete]
GPU 2: Intel HD Graphics 630 @ 1.00 GHz [Integrated]
Memory: 4.26 GiB / 15.45 GiB (28%)
Swap: 0 B / 3.86 GiB (0%)
Disk (/): 28.25 GiB / 257.53 GiB (11%) - btrfs
Disk (/mnt/D): 425.30 GiB / 1.82 TiB (23%) - btrfs
We appear to still be waiting for someone to close the loop with regard to #5497358.
This bug is fixed by Game developer, Closing this. Please feel free to ping back if you face any issue.
Hi @BlueGoliath
Are you still seeing Xid 56 or HDMI FRL link training failed issue with 595 beta released driver.
If yes please share nvidia bug report from repro state.
I can add an update to my crash. Adding KWIN_FORCE_SW_CURSOR=1
in /etc/environment fixes the crash in driver 580-142 for me. AUR comments show at least one other person also had success with this. Hopefully this helps narrow things down.
I am able to confirm this workaround stops the crash on my end.
I fixed the issue by applying this patch to the 580.142 kernel driver:
diff --git a/nvidia-drm/nvidia-drm-fb.c b/nvidia-drm/nvidia-drm-fb.c
index 05506435..d6f38ee8 100644
--- a/nvidia-drm/nvidia-drm-fb.c
+++ b/nvidia-drm/nvidia-drm-fb.c
@@ -141,7 +141,6 @@ static int nv_drm_framebuffer_init(struct drm_device *dev,
struct NvKmsKapiCreateSurfaceParams params = { };
struct nv_drm_gem_object *nv_gem;
struct drm_framebuffer *fb = &nv_fb->base;
- bool non_scanout_mem_backed = false;
uint32_t i;
int ret;
@@ -163,10 +162,6 @@ static int nv_drm_framebuffer_init(struct drm_device *dev,
params.planes[i].memory = nv_gem->pMemory;
params.planes[i].offset = fb->offsets[i];
params.planes[i].pitch = fb->pitches[i];
-
- if (!nvKms->isVidmem(nv_gem->pMemory) && nv_dev->hasVideoMemory) {
- non_scanout_mem_backed = true;
- }
}
}
params.height = fb->height;
@@ -233,15 +228,10 @@ static int nv_drm_framebuffer_init(struct drm_device *dev,
/* Create NvKmsKapiSurface */
- if (non_scanout_mem_backed) {
- /* Do not register drm_framebuffer against nvkms */
- nv_fb->pSurface = NULL;
- } else {
- nv_fb->pSurface = nvKms->createSurface(nv_dev->pDevice, ¶ms);
- if (nv_fb->pSurface == NULL) {
- NV_DRM_DEV_DEBUG_DRIVER(nv_dev, "Failed to create NvKmsKapiSurface");
- goto fail;
- }
+ nv_fb->pSurface = nvKms->createSurface(nv_dev->pDevice, ¶ms);
+ if (nv_fb->pSurface == NULL) {
+ NV_DRM_DEV_DEBUG_DRIVER(nv_dev, "Failed to create NvKmsKapiSurface");
+ goto fail;
}
return 0;
This issues (5570122) still persists with 580.126.09. Any updates?
Sorry I can’t as I no longer have the laptop.
On my local setup this issue is not reproducible though I don’t have Samsung BX2231 displays as its pretty old model, Upon resume my windows are landing to expected displays. Can you please help with one more isolation where you can uninstall Nvidia driver and see observe the behavior with default driver nouveau. I will wait for your results.
I am not able to reproduce this on latest 590 driver. I used ubuntu 24.04.4 with kernel 6.14.0-37-generic. Please reply here if you face any difficulty, closing this loop now.
Using GNOME 49 and linux kernel 6.19.9 with nouveau only, it works as should - after wake up all windows stays on screens where they were before suspend.
I also tried with 580.142 driver and with GNOME Shell 49.5 after wake up from the suspend GNOME Shell crashes the session that results in login screen to new clean session.
Then tried with 580.126.18 that did not crash in the past and now does then looks like GNOME fault.