### System details

Gigabyte Z790 Eagle AX, NVIDIA RTX 5060 Ti 16GB, Omarchy (kernel 7.1.9-arch1-2, nvidia-open 610.57.04)

### What's wrong?

# Kernel Soft Lockup / Full System Freeze with NVIDIA RTX 5060 Ti (nvidia-open) on Boot
 
## Summary
 
On a fresh Omarchy 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 a different vendor's hardware with a different RTX 50-series card (Framework Computer, RTX 5070), suggesting this is a driver-level bug affecting Blackwell (RTX 50-series) GPUs broadly rather than something specific to this motherboard or to Omarchy's configuration.
 
## System Information
 
| Component | Detail |
|---|---|
| Distro | Omarchy |
| Kernel | `7.1.9-arch1-2` |
| GPU | NVIDIA GeForce RTX 5060 Ti (16GB) |
| Driver | `nvidia-open` 610.57.04-8 / `nvidia-utils` 610.57.04-1 |
| Motherboard | Gigabyte Z790 Eagle AX |
| Boot mode | UEFI, CSM disabled |
| Dual boot | Yes, Windows on same disk |
| GPU vBIOS | Updated via NVIDIA GPU UEFI Firmware Update Tool v2.0 (fixes the known RTX 5060/5060 Ti black-screen-on-reboot bug) — **already applied**, does not resolve this issue |
 
Module/kernel version match confirmed (ruling out a stale/mismatched package build):
```
$ uname -r
7.1.9-arch1-2
 
$ modinfo nvidia | grep vermagic
vermagic: 7.1.9-arch1-2 SMP preempt mod_unload
```
 
## Steps to Reproduce
 
1. Fresh Omarchy install with `nvidia-open` + `nvidia-utils` installed via pacman (no `nvidia-open-dkms`, no DKMS involved).
2. Standard `mkinitcpio.conf` MODULES entry: `nvidia nvidia_modeset nvidia_uvm nvidia_drm`, with `nvidia_drm modeset=1 fbdev=1` set via `/etc/modprobe.d/nvidia.conf`.
3. Boot normally (no `nomodeset`, no blacklist).
4. Boot proceeds normally through systemd targets — dozens of `[ OK ]` lines (System Initialization, Basic System, Sound Card, Bluetooth Support, etc.) — then **hard-freezes** immediately after `Reached target Bluetooth Support`, before reaching the login prompt / Hyprland session.
5. System is unresponsive: `Ctrl+Alt+F2` (VT switch) does nothing. `Caps Lock` LED still toggles, indicating the kernel itself has not fully panicked, but the console/DRM path is stuck.
### Workaround that avoids the freeze (but disables the GPU entirely)
```
nomodeset acpi=off systemd.unit=multi-user.target rd.driver.blacklist=nvidia,nvidia_modeset,nvidia_drm,nvidia_uvm
```
With this, the system boots to a working TTY. Manually running `sudo modprobe nvidia` **succeeds** (exit code 0) and `nvidia-smi` correctly detects and reports the GPU:
```
NVIDIA-SMI 610.57.04   KMD Version: 610.57.04   CUDA UMD Version: 13.3
GPU 0: NVIDIA GeForce RTX 5060 Ti   0MiB / 16311MiB   4% util   30C
```
This confirms the driver itself loads and initializes correctly in isolation — the freeze is specifically tied to modeset/KMS activation and/or subsequent GPU activity during full boot, not to basic driver loading.
 
## Kernel Log 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:
 <TASK>
 ? __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
 ...
 </TASK>
 
systemd-logind[1142]: Failed to start [email protected]: Connection timed out
```
 
Multiple CPUs are pinned at 100% system time with 0% idle, all apparently waiting on an IPI acknowledgment tied to a TLB flush triggered during a `fork()`/`clone()` (`copy_process` → `dup_mmap` → `flush_tlb_mm_range`). One CPU does not appear to be servicing the IPI, causing the others to spin indefinitely until the watchdog fires.
 
## Suspected Root Cause
 
This looks like the same class of bug reported upstream against a completely different hardware vendor and a different RTX 50-series SKU:
 
- **Framework Computer / SoftwareFirmwareIssueTracker#136** — RTX 5070 (Blackwell) dGPU, AMD platform, Fedora 43, kernel 6.17.9. Identical failure signature:
  - Same crash point: `smp_call_function_many_cond` / `on_each_cpu_cond_mask` / `flush_tlb_mm_range`
  - Multiple CPUs stuck at 100% system / 0% idle waiting on IPI ack
  - One CPU not responding to the IPI while `nvidia`, `nvidia_drm`, `nvidia_modeset`, `nvidia_uvm` (all tainted `OE`) are loaded
  - Link: https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker/issues/136
The common factor across both reports is an RTX 50-series (Blackwell) GPU running the `nvidia-open` kernel modules, on otherwise completely unrelated CPU vendors (Intel here, AMD there) and motherboards. This strongly suggests the bug lives in the NVIDIA open kernel driver / GSP firmware interaction — most likely a CPU being held with interrupts effectively unavailable to service IPIs (e.g. during a GSP RPC wait), which blocks the TLB shootdown that other CPUs are blocked on.
 
This is **not** the previously-known RTX 5060/5060 Ti black-screen-on-reboot vBIOS bug (that one is already patched via NVIDIA's UEFI Firmware Update Tool v2.0, and has been applied on this system with no change in behavior).
 
## Diagnostics Already Ruled Out
 
- ❌ Kernel/module version mismatch — `vermagic` matches `uname -r` exactly.
- ❌ Bad `nvidia-open` install — `modprobe nvidia` succeeds cleanly, `nvidia-smi` reports the GPU correctly.
- ❌ vBIOS black-screen-on-reboot bug — already patched via NVIDIA's official tool.
- ❌ Basic udev/driver blacklist misconfiguration — modules load fine when not blacklisted, up until modeset/KMS is actually engaged during a full boot.
## Mitigations Being Tested (not yet confirmed to fix it)
 
1. `options nvidia NVreg_DynamicPowerManagement=0x00` — disabling NVIDIA's dynamic power management, which has fixed a related PCI-resource-reallocation freeze on Omarchy hybrid-graphics laptops (see basecamp/omarchy#3242).
2. `pcie_aspm=off` kernel parameter, to rule out a PCIe ASPM race with GPU register access.
## Where This Is Being Reported
 
- Filing to **Omarchy** (`basecamp/omarchy` GitHub issues) since other Omarchy users have reported adjacent NVIDIA freeze/lockup issues (e.g. #3242, #3417/#3436, #5726), and the Omarchy team may want visibility even though root cause appears to be upstream driver, not Omarchy-specific.
- Also recommend cross-filing to **NVIDIA's open-gpu-kernel-modules** tracker (`NVIDIA/open-gpu-kernel-modules` GitHub issues), since the crash signature is driver/firmware-level and reproduces on entirely different hardware (Framework Computer, AMD platform).
## Questions for the Omarchy Team
 
1. Has any other Omarchy user on an RTX 50-series (5060/5060 Ti/5070/5080/5090) card hit this exact `smp_call_function_many_cond` / TLB-flush soft lockup during boot (as opposed to during runtime, like #3417/#3436)?
2. Does Omarchy pin/ship a specific `nvidia-open` version, or is there a recommended known-good version to pin to for Blackwell cards while this is unresolved upstream?
3. Is there an Omarchy-recommended set of kernel/module parameters for Blackwell GPUs (e.g. default `NVreg_DynamicPowerManagement` handling) that could be documented for new RTX 50-series users?
---
*Prepared from direct terminal diagnostics (`uname -r`, `pacman -Qi`, `modinfo`, `modprobe`, `nvidia-smi`, `journalctl -b -1`) collected on the affected system.*