Afternoon! This post was written with help from claude code, I hope that’s okay – I wanted to be thorough in my troubleshooting before posting.
2 days ago during a Windows update I encountered my external screen receiving no signal. Further investigating showed a Code 43 on the nvidia dgpu and rolling-back the updates did nothing to resolve. I attempted clean installs of the nvidia app and the driver, both with the app and without, to no avail.
I decided to switch OS to Fedora Workstation at that time and am encountering errors still, this time on the linux side; I am hoping someone may be able to help point me in some other direction possibly? or review and see … I’m not sure if it’s a failure on the part of Dell/laptop manufacturer or something?
Below is the full report from claude code:
I am reporting a reproducible failure of the NVIDIA Open Kernel Module on a Dell G16 7620 laptop. The dGPU enters an unrecoverable state on every boot, with three distinct Xid codes triggered along the way. The same fault reproduces in Windows as Device Manager Code 43, indicating the issue is at the firmware / driver-state level rather than OS-side. nvidia-bug-report.log.gz is attached.
Hardware
- System: Dell G16 7620 (G-Series, motherboard 085T23 rev A02, product SKU 0B99)
- CPU: Intel Core i9-12900H (Alder Lake-P)
- iGPU: Intel Iris Xe (8086:46a6, i915 driver, healthy)
- dGPU: NVIDIA GeForce RTX 3070 Ti Laptop (GA104M, PCI ID 10de:24e0, GPU UUID GPU-201833e6-5a54-3208-effd-3797dcc41d2d)
- VBIOS: 94.04.7F.40.D4
- BIOS: Dell 1.40.0 dated 2026-04-01 (latest published to LVFS; fwupdmgr get-updates returns no pending firmware)
- EC firmware: 1.25
- BIOS “Enable Hybrid Graphics/Advanced Optimus” toggled both ways for testing (see Reproduction Notes below)
Software
- Fedora 44 Workstation
- Kernel: 7.0.8-200.fc44.x86_64
- Driver: NVIDIA UNIX Open Kernel Module 595.71.05 (RPM Fusion akmod-nvidia build, dated Fri Apr 24 06:42:30 UTC 2026)
- nouveau and nova_core blacklisted via cmdline; nvidia loaded from initramfs
- Session: Wayland (GNOME on Intel iGPU via PRIME)
Symptom summary
- Back HDMI port (wired directly to the dGPU) produces no signal at any time, and the kernel sees no hotplug event on card0-HDMI-A-1 when a cable is plugged in (status=disconnected / edid bytes: 0 even with
cable + powered display attached). - nvidia-smi reports [GPU requires reset] for every telemetry field within ~25 seconds of every boot.
- systemctl poweroff, systemctl reboot, and suspend all hang in the kernel’s post-systemd phase (after systemd-shutdown finishes, after journald stops, before ACPI _S5). I attribute this to the dGPU being
unable to release in device_shutdown() once wedged. - The same dGPU produces Windows Device Manager Code 43 on this laptop, confirming the fault is not OS-specific.
Diagnostic trace from a typical boot (all from journalctl -k, NVIDIA-related entries)
The earliest signal is two failed BIOS handshake calls, immediately after driver load:
NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64 595.71.05
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed
[NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler
failed to get target temp from SBIOS @ platform_request_handler_ctrl.c:2171
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed
[NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler
failed to get platform power mode from SBIOS @ platform_request_handler_ctrl.c:2114
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DP-0
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DP-0
nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes
Roughly 23 seconds later, GSP collapses:
NVRM: GPU0 _kgspIsHeartbeatTimedOut: Heartbeat timed out
NVRM: GPU0 _kgspClassifyGspTimeout: ============ GSP core unresponsive ===========
NVRM: Xid (PCI:0000:01:00): 119, pid=1761, name=nv_queue, Timeout after 12s of
waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL)
sequence 311 (0x20800a70 0x0).
NVRM: GPU0 _kgspDumpRmState: Failed to get RM state, timeout
Subsequent attempts to touch the dGPU trigger two further Xid codes recurring across every boot in the journal:
NVRM: GPU0 RmCheckForGcxSupportOnCurrentState: NVRM, Failed to get GCx pre-requisite, status=0x65
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
NVRM: GPU0 vaspaceapiConstruct_IMPL: Could not construct VA space. Status 62
NVRM: GPU0 nvCheckOkFailedNoLog: Check failed: Generic Error: Invalid state
[NV_ERR_INVALID_STATE] (0x00000040) returned from pRmApi->Control(…
NV2080_CTRL_CMD_INTERNAL_LOG_OOB_XID, …) @ gpu.c:7442
NVRM: Xid (PCI:0000:01:00): 175, pid=19306, name=nvidia-smi, Timeout after 10s of
waiting for RPC response from GPU0 GSP! Expected function 103 (GSP_RM_ALLOC)
sequence 7151 (0x0 0x78).
Notably, the driver also asserts NV_ERR_GPU_IN_FULLCHIP_RESET repeatedly post-collapse:
nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000c67e:6:0:0x00000062
NVRM: GPU0 nvAssertFailedNoLog: Assertion failed:
(status == NV_OK) || (status == NV_ERR_GPU_IN_FULLCHIP_RESET) @ rs_client.c:844
Reproduction notes
-
Reproduces 100% on every boot. Total Xid event count in the attached report: 64 events across the recent journal history; 3 distinct Xid codes (119, 154, 175).
-
BIOS “Enable Hybrid Graphics” toggled OFF (i.e., dGPU primary) reproduces the same fault, but the GSP collapse trigger shifts from driver init (~23s, triggered by nv_queue) to first display call (~51s,
triggered by gnome-shell setting up its compositor). Same failed to get target temp from SBIOS / failed to get platform power mode from SBIOS precede in both cases. -
Dell ePSA pre-boot diagnostic passes on iGPU, CPU, RAM, storage; ePSA does not run a dGPU test on this model.
-
fwupdmgr get-updates confirms no firmware updates are pending; BIOS 1.40.0 is the latest LVFS-published version.
-
LVFS / Dell are unlikely to ship a further BIOS fix — there is an open Dell community thread acknowledging a related “dGPU stuck in P0” condition on the G15 5520/5521/G16 7620 family since BIOS 1.28+, with no
resolution as of this writing.
What I have ruled out
- OS install: clean Fedora 44 install on 2026-05-14 reproduces fault from first boot.
- Driver version: open module 595.71.05 from RPM Fusion is current.
- Firmware level: BIOS 1.40.0 / EC 1.25 are the latest available.
- Cooling / thermal: ePSA thermal test passes; no thermal events in dmesg.
- Hardware path: external display via USB-C dock (Intel iGPU side) works correctly. Only the dGPU subsystem is affected.
What I am asking
I recognize that the upstream root cause appears to be a Dell SBIOS / ACPI methods bug (PlatformRequestHandler returning NV_ERR_INVALID_DATA), which is outside NVIDIA’s control. However, the GSP firmware’s response to invalid SBIOS data — repeated heartbeat timeout, RPC collapse, irrecoverable chip-reset state, inability to release the device at kernel device_shutdown() — appears to be defensively recoverable in driver code. Specifically:
- Could the open kernel module degrade gracefully when PlatformRequestHandler returns NV_ERR_INVALID_DATA, rather than allowing the GSP to time out and lock the chip into a [requires reset] state?
- Could the driver implement a safe .shutdown callback path that releases the device cleanly even when the GPU is already wedged, so that device_shutdown() doesn’t hang the entire system?
- Is there a known interaction between the open kernel module and this Dell G-Series ACPI implementation that has a documented workaround (e.g., a kernel parameter or a modprobe option to bypass GCx / SBIOS
queries on affected platforms)?
I’d be happy to test any debug or patched module builds against this hardware; the failure is 100% reproducible and immediate, so iteration cycles are short. Attached log was generated with nvidia-bug-report.sh (script version 37802095).
nvidia-bug-report.log.gz (1.6 MB)