RTX 5060 Ti GSP RPC failure / Xid 79 over Thunderbolt eGPU enclosure

Gaming and Visualization Technologies General Topics & Other SDKs Drivers - Linux, Windows, MacOS
1

Bug Report: RTX 5060 Ti (Blackwell) — GSP firmware failure over Thunderbolt eGPU enclosure

Summary

RTX 5060 Ti 16GB, connected via a Thunderbolt 3/4 eGPU dock (external PSU, PCIe x16 slot) to a Linux-based host (NAS running a Linux 6.12 kernel, NVIDIA driver 570.181, CUDA 12.8). Under sustained CUDA workload (LLM inference via llama.cpp/Ollama), the GPU intermittently disconnects from the system with kernel-level Xid errors, and separately the GSP (GPU System Processor) RPC channel fails outright, leaving the device permanently unusable until a full host reboot. nvidia-smi --gpu-reset resolves the milder case but not the GSP failure case.

System configuration

  • GPU: NVIDIA GeForce RTX 5060 Ti, 16GB VRAM (GB206, Blackwell)
  • Driver: NVIDIA UNIX Open Kernel Module 570.181
  • CUDA: 12.8
  • Connection: Thunderbolt 3/4 eGPU enclosure with dedicated ATX power supply (separate PCIe power cable to the GPU)
  • Host: Linux 6.12 kernel (custom NAS OS build), containerized workload via Docker with the NVIDIA Container Toolkit (nvidia runtime)
  • Workload: LLM inference (llama.cpp backend via Ollama), sustained GPU compute load

Observed failure modes

Failure mode 1 — Xid 79 (bus disconnect), recoverable

NVRM: Xid (PCI:0000:2e:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:2e:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)

or, on a later occurrence:

NVRM: Xid (PCI:0000:04:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:04:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)

When the recovery action is “GPU Reset Required” (0x1), sudo nvidia-smi --gpu-reset successfully recovers the device without a host reboot. When it is “Node Reboot Required” (0x2), only a full host reboot restores functionality.

Also observed at the same time as the bus drop:

pcieport: pciehp: Slot(1): Link Down
pcieport: not ready 1023ms after resume; giving up
pci: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at [upstream bridge]
  (capable of 504.112 Gb/s with 32.0 GT/s PCIe x16 link)

i.e. the link renegotiates far below the GPU’s rated PCIe x16 speed after a drop/reconnect event.

Failure mode 2 — GSP RPC failure, requires full reboot

Occurred separately, with the GPU still visible via lspci but completely unresponsive to nvidia-smi (“No devices found”) and nvidia-smi --gpu-reset also failing:

NVRM: nvAssertFailedNoLog: Assertion failed: status == NV_OK @ rs_client.c:843
NVRM: nvAssertFailedNoLog: Assertion failed: status == NV_OK @ rs_server.c:259
NVRM: nvAssertFailedNoLog: Assertion failed: status == NV_OK @ rs_server.c:1375
NVRM: _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 10!
NVRM: rpcRmApiFree_GSP: GspRmFree failed: hClient=0x...; hObject=0x...; paramsStatus=0x00000000; status=0x0000000f
NVRM: _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 76!
NVRM: _deviceTeardown: Disable of Cuda limit activation failed

lspci | grep -i nvidia still shows the device present at the PCI level in this state; only nvidia-smi and the driver’s RPC channel to GSP are broken. Only a full OS reboot restores the GPU.

Steps to reproduce

  1. Boot host, verify nvidia-smi shows the RTX 5060 Ti correctly (idle, 0MiB used).
  2. Start a containerized CUDA workload (llama.cpp/Ollama) that loads a model fully offloaded to GPU (~4–13GB VRAM depending on model) and runs sustained inference.
  3. After a variable amount of time/load (observed both within minutes of first load, and after tens of minutes of use), the GPU either:
    • drops off the bus (Xid 79), or
    • the GSP RPC channel fails outright (no Xid, just RPC/assertion failures as above).
  4. In case (a) with recovery action 0x1, nvidia-smi --gpu-reset restores function. In case (a) with recovery action 0x2, or in case (b), only a full host reboot restores function.

What has already been ruled out / tried

  • Verified the PCIe power cable to the GPU is fully seated in the eGPU enclosure.
  • Reseated the Thunderbolt cable and power-cycled the enclosure — the bus-drop event (Xid 79) has recurred on at least two separate reconnect events, suggesting a link-training issue that is not fully resolved by a clean reconnect.
  • Confirmed the NVIDIA Container Toolkit and Docker nvidia runtime are correctly configured (driver and CUDA libraries are correctly exposed to the container in all cases — the failure is at the hardware/driver level, not the container integration level).
  • Have not yet tried disabling GSP firmware (NVreg_EnableGpuFirmware=0) — aware this is a community-reported (non-official) mitigation for similar RTX 40/50-series eGPU-over-Thunderbolt issues, and would prefer an official driver/firmware fix or guidance before applying an unsupported workaround long-term.

Request

This appears consistent with other publicly reported cases of RTX 50-series (Blackwell) GPUs experiencing GSP initialization/RPC failures specifically over Thunderbolt/USB4 eGPU enclosures, independent of enclosure brand. Requesting guidance on:

  1. Whether a driver or GSP firmware update addressing Thunderbolt/USB4 eGPU stability for Blackwell GPUs is planned or already available.

  2. Whether disabling GSP firmware is an officially supported/recommended workaround for this configuration, and any known side effects for CUDA compute workloads specifically (as opposed to display use).

    nvidia-bug-report.log.gz (308.8 KB)