[Bug]: RTX 4070 Ti System Hang on Suspend/Sleep - Driver 595.71.05 / Kernel 7.0.9

### NVIDIA Open GPU Kernel Modules Version akmod-nvidia-595.71.05-1.fc44.x86_64 srcversion: 56643BB88BCD3BF53D00060 ### 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 Fedora Linux 44 (KDE Plasma Desktop Edition) ### Kernel Release Linux fedora 7.0.9-202.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 18 22:33:24 UTC 2026 x86_64 GNU/Linux ### Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels. - [x] I am running on a stable kernel release. ### Hardware: GPU GPU 0: NVIDIA GeForce RTX 4070 Ti (UUID: GPU-1c49682a-3060-dbe9-d11c-fdbbac39c74b) ### Describe the bug When attempting a standard system suspend, the machine completely hangs and fails to power down or enter a low-power sleep state. The display goes black instantly, but system power rails, chassis fans, RGB lighting, and internal motherboard power indicators remain fully active and frozen. The system becomes completely unresponsive (network drops, SSH fails) and requires a hard manual hardware reset via the physical power button to recover. This issue isolates entirely to the open kernel modules track; downstream packaging handles Ada Lovelace hardware by forcing the open modules automatically, triggering this failure domain on every sleep cycle. The driver functions flawlessly under massive rendering, CUDA compute, and 3D gaming workloads; the regression is strictly isolated to the virtual memory unmapping/unwinding paths executed during modern standby/S3 sleep state transitions. ### Driver Track Isolation & Verification The underlying issue was isolated to the open-source module stack by confirming that the package toolchain enforces an automated override for Ada Lovelace hardware, rejecting standard user configuration parameters. Command executed to inspect active signature state: $ modinfo nvidia | grep -i license Output returned: license: Dual MIT/GPL Even when forcibly wiping package build caches, manually injecting %_with_kmod_nvidia_open 0 macros, and re-triggering clean builds via akmods, the toolchain programmatically links the build target to the Open Kernel Modules branch. This confirms that the suspend/resume regression cannot be bypassed locally via standard configuration overrides on this hardware layout. ### To Reproduce Boot into a Wayland session under KDE Plasma on Fedora with the open kernel driver modules active (modinfo nvidia license is Dual MIT/GPL). Trigger a system suspend via the desktop GUI power configurations or directly via terminal execution: ```Bash sudo systemctl suspend ``` The display disconnects instantly, but hardware power cycles lock up indefinitely before completing the transition. ### Bug Incidence Always ### nvidia-bug-report.log.gz [nvidia-bug-report.log.gz](https://github.com/user-attachments/files/28080557/nvidia-bug-report.log.gz) ### More Info I expected the graphics context to cleanly unmap virtual memory allocations, allowing the kernel to step down the hardware power levels into a safe sleep cycle. Instead, the driver fails to release or handle low-level memory states on the AD104 core during power transition states. This issue mimics behavior reported across identical 595-series bugs, heavily pointing to an upstream context-handling regression on modern 7.x kernels. ### Technical Regression Context Because the system experiences a hard lockup upon entering a suspend state, kernel ring buffers cannot write active panic traces to disk before power rails freeze. However, the system's behavior directly mirrors established tracking behavior for the 595 open module architecture on modern 7.x kernels: 1. MMU Virtual Address Unmapping Failure: During the power state step-down, the kernel signals the driver to clear active virtual memory domains. The open module framework hits a pointer tracking fault during execution (mimicking the structural context of open-gpu-kernel-modules Issue #1148): -> NVRM: nvAssertFailedNoLog: Assertion failed: NV_OK == unmapStatus @ mmu_walk_map.c -> NVRM: GPU0 mmuWalkMap: Unmap failed with status = 0x00000040 2. GSP Firmware Handshake Hang: Because the memory management structures fail to cleanly unwind or unmap the active address space on the AD104 core, the asynchronous thread processing loop cannot signal a clean state detach to the physical GSP (GPU System Processor) co-processor. The kernel thread blocks indefinitely waiting for a hardware response, trapping the motherboard power states and halting the shutdown phase.