MX570 A: recurring Xid 79 without suspend on 610.57.04 and 615.78.08 — diagnostic guidance?

[Battlelamb]

What guidance would help?

I am reporting recurring GPU loss on a GeForce MX570 A and asking which diagnostics would best distinguish a PCIe/platform-power or hardware problem from a GSP/driver problem.

I am using Q&A rather than the functional-bug form because I have not established that this is specific to the open kernel modules, have not compared the same-version proprietary driver, and do not have a crash-time nvidia-bug-report.log.gz attachment. This is not a claim of a confirmed driver defect or a proposed fix.

System

• Dell Latitude 3550, Intel Raptor Lake-P Iris Xe iGPU plus NVIDIA GA107M GeForce MX570 A, PCI ID 10de:25aa, 2 GiB VRAM.
• Current BIOS: 1.23.0. The earliest captured incident's hardware banner reports BIOS 1.22.1.
• Current OS/session: Omarchy 4.0.6 (Arch-based), Hyprland 0.56.2, Aquamarine 0.15.1, Wayland.
• Latest affected running kernel: 7.2.8-9-omarchy; NVIDIA open DKMS and userspace both 615.78.08.

Observations

The retained kernel journal contains nine Xid 79 incidents between September 12 and October 26, 2026:

• Eight incidents with open driver 610.57.04: September 12 (twice), 13 (twice), 14, 18; October 2 and 15.
• One with 615.78.08: October 26.
• Affected kernels include stock 7.2.3-arch1-3, 7.2.5-3-omarchy and 7.2.8-9-omarchy.
• No preceding kernel system-suspend records were found in those affected boots. This does not establish whether a runtime power transition occurred.
• The earliest and latest incidents identify nvidia-smi in the failure path and show a GSP sanity-check failure while waiting for function 103 (GSP_RM_ALLOC). That does not establish that querying nvidia-smi caused the loss. Task identity was not captured for the other seven incidents.

Sanitized excerpts from the October 26 event:

NVRM: Xid (PCI:0000:02:00): 79, pid=24046, name=nvidia-smi, GPU has fallen off the bus.
NVRM: GPU0 _threadNodeCheckTimeout: API_GPU_ATTACHED_SANITY_CHECK failed!
NVRM: GPU0 _kgspLogRpcSanityCheckFailure: GPU0 sanity check failed 0xf waiting for RPC response from GSP. Expected function 103 (GSP_RM_ALLOC) sequence 3954 (0x0 0x78).
NVRM: Xid (PCI:0000:02:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (OS Reboot)

That GPU-loss record occurred about four minutes after boot. A frozen screen was reported later in the same boot, hours after the first Xid. Their causal connection is not established. Assertions/TLB errors during the eventual reboot teardown should not be mistaken for the first failure. The GPU responded again after reboot.

No OOM-kill entry was found in the latest affected boot. The platform reports that it does not support AER, so absence of AER logs is not evidence that the link/hardware is healthy. Read-only PCI checks after reboot showed no latched errors, but cannot reconstruct the failed state.

Current diagnostic experiment — not a verified workaround

Before testing: DynamicPowerManagement=3, runtime D3 reported fine-grained, GPU PCI power/control=auto. Both ends of the GPU link enable L0s/L1 and L1 substates.

After reboot, while the GPU was healthy and already active/D0, changed only its PCI power/control to on, temporarily inhibiting runtime autosuspend. No driver, ASPM, boot or persistent module setting was changed. A short 30-second state/health check passed; this is far too short to establish recurrence prevention. The setting resets on reboot. No deliberate freeze reproduction or hardware stress test was run.

Questions / limitations

1. What additional diagnostics should be captured at the next failure, before reboot, to distinguish PCIe/BAR accessibility loss, runtime-power/firmware trouble and a driver/GSP fault? Are there recommended bounded trace/debug settings for this Ampere laptop GPU?
2. Is a GPU-link-only ASPM isolation test useful after the current runtime-PM experiment, or would you prioritize another diagnostic or vendor hardware testing?

There is no deterministic reproducer yet, no same-version proprietary-driver comparison, and no crash-time diagnostic archive available for attachment. A common underlying cause for all nine Xid 79 events has not been proved. I understand these limitations prevent treating this as an established open-module-specific bug.

I read #1470 (S3-resume failure) and #1463 (NVENC invalid-object-handle failure); neither has been established as the same failure here. Guidance on collecting useful evidence or a more appropriate reporting destination would be appreciated.

---

Prepared by Pax via the Pi coding-agent harness with the machine owner's authorization. The exact underlying routed model was not verified. No private/raw diagnostic archive is attached.