In this article
Xid 79 establishes lost GPU accessibility; the surrounding PCIe and host evidence determines the next investigation.
What Xid 79 actually establishes
The phrase fallen off the bus describes an access failure observed by the GPU driver. It does not identify one replaceable component. The NVIDIA Xid catalog associates Xid 79 with a GPU becoming inaccessible through its PCI Express connection and describes several possible underlying causes. The useful first question is what else the host recorded around that transition.
Separate confirmed observations from explanations. GPU query unavailable is an observation; defective board is a hypothesis until the investigation supports it. A screenshot of the final error loses the host context needed to distinguish those statements.
Capture the surrounding device path
Retain the GPU’s known UUID, PCI address, host boot identity and software versions. Preserve the earlier inventory if the device can no longer answer management queries. Record which other GPUs, NICs or storage devices share the affected host or path. Do not renumber the incident simply because enumeration changes after recovery.
Collect the original kernel and platform event logs within a bounded window. The Linux AER guide explains PCIe error reporting and severity. A nearby AER message is useful evidence about the path, but the reporting component is not automatically the failed component. Absence of an AER message also does not prove that the link stayed healthy.
Record the application consequence
Note whether a worker stopped, requests timed out, management queries failed or the host itself restarted. These consequences can have different timestamps and scopes. Preserve the last successful observation and first failed observation instead of inventing a precise failure instant between them.
For example, a hypothetical report might show successful management collection, then missing samples, then Xid 79 and several failed application requests. The evidence bounds when the failure became visible. It does not show whether the collector gap preceded the physical event or merely reflected delayed reporting.
Keep recovery separate from diagnosis
Before supervised recovery, save the available evidence and identify active work and dependent devices. Apply the relevant platform and support procedure. A remote reset or a host reboot is not a universal diagnostic step that can be copied safely across every workstation, PCIe topology and occupied server.
If service returns after maintenance, document what changed and what remained unchanged. Restored accessibility is an outcome, not proof of a root cause. Replacing several components while updating the driver at the same time may restore service but weaken the ability to identify the contributing factor.
Write the handover around unanswered questions
A useful handover includes raw logs, device identity, path information, workload conditions, maintenance history and a clear list of missing evidence. State whether the event repeated under a controlled comparison. Keep any replacement recommendation tied to the applicable product investigation rather than declaring every Xid 79 a failed GPU or dismissing it as an application-only problem.