NVIDIA Open GPU Kernel Modules Version
610.57.04
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.
Operating System and Version
Arch Linux (Omarchy)
Kernel Release
7.1.9-arch1-2
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
Hardware: GPU
GPU 0: NVIDIA GeForce RTX 5060 Ti (UUID: GPU-0e5092e2-1400-cc31-f1dc-087cfcd7d225)
Describe the bug
On a fresh Omarchy (Arch-based) installation with an NVIDIA GeForce RTX 5060 Ti (16GB), the system reliably freezes during boot as soon as the nvidia, nvidia_drm, nvidia_modeset, and nvidia_uvm kernel modules are loaded with KMS (modeset) active. The system is only usable when booting with nomodeset and the nvidia modules blacklisted — i.e. with no GPU acceleration at all.
journalctl from the frozen boot shows a kernel soft lockup with multiple CPUs stuck waiting on an inter-processor interrupt (IPI) during a TLB shootdown (flush_tlb_mm_range → on_each_cpu_cond_mask). This matches an actively open, unresolved upstream report on completely different hardware (Framework Computer, RTX 5070, AMD platform): FrameworkComputer/SoftwareFirmwareIssueTracker#136 — same crash point (smp_call_function_many_cond / on_each_cpu_cond_mask / flush_tlb_mm_range), same pattern of multiple CPUs at 100% system / 0% idle waiting on IPI ack while nvidia_drm/nvidia_modeset/nvidia/nvidia_uvm are loaded (tainted OE).
This suggests a bug in the NVIDIA open kernel driver / GSP firmware interaction — likely a CPU being held with interrupts effectively unavailable to service IPIs (e.g. during a GSP RPC wait), blocking the TLB shootdown other CPUs are waiting on. Reproduces across unrelated CPU vendors (Intel here, AMD in the Framework report) and motherboards, on an RTX 50-series (Blackwell) GPU.
Kernel log excerpt at time of freeze (journalctl -b -1):
watchdog: BUG: soft lockup - CPU#13 stuck for 205s! [systemd:1]
CPU#13 Utilization every 4000ms during lockup:
#1: 100% system, 0% softirq, 0% hardirq, 0% idle
#2: 100% system, 0% softirq, 0% hardirq, 0% idle
#3: 100% system, 0% softirq, 0% hardirq, 0% idle
#4: 100% system, 0% softirq, 0% hardirq, 0% idle
#5: 100% system, 0% softirq, 1% hardirq, 0% idle
Call Trace:
? __pfx_flush_tlb_func+0x10/0x10
on_each_cpu_cond_mask+0x24/0x40
flush_tlb_mm_range+0x1cb/0x5c0
? __khugepaged_enter+0xec/0x140
dup_mmap+0x58a/0x8d0
? pcpu_alloc_noprof+0x5a5/0x9b0
copy_process+0x1b3f/0x2ae0
kernel_clone+0xe9/0x520
__do_sys_clone+0x8d/0xc0
do_syscall_64+0xaa/0x660
systemd-logind[1142]: Failed to start autovt@tty2.service: Connection timed out
Diagnostics already ruled out:
- Kernel/module version mismatch: modinfo nvidia vermagic (7.1.9-arch1-2) matches uname -r exactly.
- Bad nvidia-open install: modprobe nvidia succeeds cleanly (exit 0), nvidia-smi correctly reports the GPU (RTX 5060 Ti, 16GB, 30C) when loaded manually without modeset.
- The previously-known RTX 5060/5060 Ti black-screen-on-reboot vBIOS bug: already patched via NVIDIA's official GPU UEFI Firmware Update Tool v2.0, no change in behavior.
Mitigations currently being tested (not yet confirmed): NVreg_DynamicPowerManagement=0x00, pcie_aspm=off.
To Reproduce
- Motherboard: Gigabyte Z790 Eagle AX, UEFI mode, CSM disabled
- Install nvidia-open + nvidia-utils via pacman (no nvidia-open-dkms, no DKMS involved)
- mkinitcpio.conf MODULES: nvidia nvidia_modeset nvidia_uvm nvidia_drm
- /etc/modprobe.d/nvidia.conf: options nvidia_drm modeset=1 fbdev=1
- Boot normally (no nomodeset, no blacklist)
- Boot proceeds normally through systemd targets (dozens of [ OK ] lines) then hard-freezes immediately after "Reached target Bluetooth Support", before reaching the login prompt / Hyprland session
- System is unresponsive: Ctrl+Alt+F2 (VT switch) does nothing; Caps Lock LED still toggles, indicating the kernel has not fully panicked but the console/DRM path is stuck
- Workaround that avoids the freeze but disables the GPU entirely: boot with "nomodeset acpi=off systemd.unit=multi-user.target rd.driver.blacklist=nvidia,nvidia_modeset,nvidia_drm,nvidia_uvm"
Bug Incidence
Always
nvidia-bug-report.log.gz
nvidia-bug-report.log.gz
More Info
Expected: GPU acceleration works normally under Hyprland/Wayland after boot.
Actual: Full unrecoverable freeze immediately after modeset/KMS is engaged during boot, before reaching login. Only resolvable via hard power-off.
NVIDIA Open GPU Kernel Modules Version
610.57.04
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.
Operating System and Version
Arch Linux (Omarchy)
Kernel Release
7.1.9-arch1-2
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
Hardware: GPU
GPU 0: NVIDIA GeForce RTX 5060 Ti (UUID: GPU-0e5092e2-1400-cc31-f1dc-087cfcd7d225)
Describe the bug
On a fresh Omarchy (Arch-based) installation with an NVIDIA GeForce RTX 5060 Ti (16GB), the system reliably freezes during boot as soon as the nvidia, nvidia_drm, nvidia_modeset, and nvidia_uvm kernel modules are loaded with KMS (modeset) active. The system is only usable when booting with nomodeset and the nvidia modules blacklisted — i.e. with no GPU acceleration at all.
journalctl from the frozen boot shows a kernel soft lockup with multiple CPUs stuck waiting on an inter-processor interrupt (IPI) during a TLB shootdown (flush_tlb_mm_range → on_each_cpu_cond_mask). This matches an actively open, unresolved upstream report on completely different hardware (Framework Computer, RTX 5070, AMD platform): FrameworkComputer/SoftwareFirmwareIssueTracker#136 — same crash point (smp_call_function_many_cond / on_each_cpu_cond_mask / flush_tlb_mm_range), same pattern of multiple CPUs at 100% system / 0% idle waiting on IPI ack while nvidia_drm/nvidia_modeset/nvidia/nvidia_uvm are loaded (tainted OE).
This suggests a bug in the NVIDIA open kernel driver / GSP firmware interaction — likely a CPU being held with interrupts effectively unavailable to service IPIs (e.g. during a GSP RPC wait), blocking the TLB shootdown other CPUs are waiting on. Reproduces across unrelated CPU vendors (Intel here, AMD in the Framework report) and motherboards, on an RTX 50-series (Blackwell) GPU.
Kernel log excerpt at time of freeze (journalctl -b -1):
watchdog: BUG: soft lockup - CPU#13 stuck for 205s! [systemd:1]
CPU#13 Utilization every 4000ms during lockup:
#1: 100% system, 0% softirq, 0% hardirq, 0% idle
#2: 100% system, 0% softirq, 0% hardirq, 0% idle
#3: 100% system, 0% softirq, 0% hardirq, 0% idle
#4: 100% system, 0% softirq, 0% hardirq, 0% idle
#5: 100% system, 0% softirq, 1% hardirq, 0% idle
Call Trace:
? __pfx_flush_tlb_func+0x10/0x10
on_each_cpu_cond_mask+0x24/0x40
flush_tlb_mm_range+0x1cb/0x5c0
? __khugepaged_enter+0xec/0x140
dup_mmap+0x58a/0x8d0
? pcpu_alloc_noprof+0x5a5/0x9b0
copy_process+0x1b3f/0x2ae0
kernel_clone+0xe9/0x520
__do_sys_clone+0x8d/0xc0
do_syscall_64+0xaa/0x660
systemd-logind[1142]: Failed to start autovt@tty2.service: Connection timed out
Diagnostics already ruled out:
Mitigations currently being tested (not yet confirmed): NVreg_DynamicPowerManagement=0x00, pcie_aspm=off.
To Reproduce
Bug Incidence
Always
nvidia-bug-report.log.gz
nvidia-bug-report.log.gz
More Info
Expected: GPU acceleration works normally under Hyprland/Wayland after boot.
Actual: Full unrecoverable freeze immediately after modeset/KMS is engaged during boot, before reaching login. Only resolvable via hard power-off.