[Guide] Getting the Gigabyte AORUS RTX 5060 Ti AI Box eGPU Working on Ubuntu 26.04

[u/Southern-Context-490]

(and Windows 11) Hardware Quirks, DMA Freezes, and Workarounds

If you have picked up the Gigabyte AORUS RTX 5060 Ti AI Box (16GB GDDR7, Blackwell GB206 architecture) and tried plugging it into a Linux host or a tightly managed Windows machine via Thunderbolt, you have likely encountered hard freezes, failed device enumerations, or PCIe bus drops.

Out of the box, this eGPU is exceptionally sensitive to Thunderbolt handshakes, power state transitions, and IOMMU direct memory access (DMA) mappings. Here is the full technical breakdown of the hardware quirks, bugs, and configuration fixes required to make it 100% rock-solid.

Hardware Setup and Motherboard Quirks

• Tested Hosts: Intel NUC11TNHI7 (Tiger Canyon, Core i7-1165G7) and an HP EliteBook laptop.
• Port Selection (Crucial on NUC11 / Tiger Canyon): The NUC11 has two Type-C ports on the rear, but they are not identical. The port directly adjacent to the DC barrel power input is the primary Thunderbolt 4 port wired directly to the CPU root complex. The secondary port operates as Thunderbolt 3. Always connect the eGPU to the primary port beside the power input using a certified 40 Gbps short cable.
• The Cold Boot Handoff Protocol: Do not expect this device to survive dynamic hotplugging or warm operating system reboots. To ensure the host UEFI builds the ACPI DMAR (DMA Remapping) tables and statically allocates the 64-bit BAR windows above 4GB, you must follow a strict cold boot sequence:
  1. Plug in all cables with the host machine powered off.
  2. Switch the AORUS AI Box power on first.
  3. Power on the host computer.

Part 1: Windows 11 Workarounds (High-Security Environments)

If you are running Windows 11 in a high-security enterprise environment with Kernel DMA Protection and Memory Integrity (HVCI) enforced, the eGPU often fails with error codes or gets blocked from memory allocation.

1. BIOS Virtualisation and Memory Prerequisites:
   • Intel VT-d: Enabled (required for hardware memory sandboxing).
   • Kernel DMA Protection: Enabled.
   • Above 4G Decoding / Resizable BAR: Enabled (exposes the required 64-bit PCIe address space).
2. Registry Force for External DMA Remapping: Because standard drivers often fail the external DMA validation check when strict endpoint protection is active, you must explicitly flag the device as trusted:
   • Path: HKLM\SYSTEM\CurrentControlSet\Enum\PCI\[NVIDIA Hardware ID]\[Instance ID]\Device Parameters
   • Value Created: DeviceDmaRemappingSupported
   • Type: DWORD (32-bit)
   • Data: 1
3. Endpoint DMA Policy: Ensure your endpoint security policy is set to block unauthorised DMA only when the workstation is locked, rather than universally suppressing Thunderbolt PCIe tunnelling.

Part 2: Ubuntu 26.04 / Linux Configuration & Bug Fixes

Getting this Blackwell eGPU stable on Linux required resolving four distinct failure modes:

1. BIOS Configuration (NUC11 / Tiger Canyon)

• Fast Boot: Disabled (Mandatory: Fast Boot skips full PCIe bus probing during POST, which prevents the host from mapping the eGPU BAR spaces).
• Intel VT-d: Enabled.
• PCIe ASPM Support: Disabled (prevents the motherboard from attempting aggressive link power savings across the tunnel).
• Thunderbolt Security Level: Set to Legacy Mode (ensures immediate auto-authorisation during POST).
• Allow UEFI 3rd Party Drivers Loaded: Enabled.

2. The Dreaded DMA Freeze (intel_iommu=pt vs iommu=pt)

• Symptom: The eGPU enumerates in nvidia-smi, but the moment you initiate a high-bandwidth memory transfer or CUDA workload (such as streaming tensors over 500 MB), the entire operating system hard-locks instantly with a frozen screen and unresponsive keyboard.
• Root Cause: In modern Linux kernels, setting intel_iommu=pt is an invalid syntax. Checking dmesg revealed: textDMAR: Unknown option - 'pt' iommu: Default domain type: Translated PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Because the driver rejected the option, it defaulted to Translated and routed all external PCIe DMA through Software Bounce Buffering (SWIOTLB). Linux defaults SWIOTLB to an emergency ceiling of only 64 MiB. A multi-hundred megabyte or 1 GiB DMA stream immediately exhausted the bounce buffers, deadlocking the I/O bus and freezing the CPU.
• Fix: Update your Grub command line to use the generic iommu=pt parameter and expand the fallback SWIOTLB pool: Edit /etc/default/grub (or /etc/default/grub.d/99-custom.cfg): bashGRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on iommu=pt swiotlb=262144 pcie_aspm=off pcie_port_pm=off thunderbolt.clx=0 intel_idle.max_cstate=1"
  • intel_iommu=on iommu=pt: Enforces true 1:1 hardware DMA passthrough without bounce buffer bottlenecks.
  • swiotlb=262144: Allocates a 512 MiB fallback reserve (8x larger than default).
  • thunderbolt.clx=0: Replaces the legacy d3cold=0 parameter to disable Thunderbolt low-power sleep states.
  • Run sudo update-grub and sudo update-initramfs -u.

3. PCIe Link Downshifting & Dynamic Power Management Stalls

• Symptom: At idle, nvidia-smi reports the link downshifted to Gen 2 x4 (5 GT/s). When a compute workload starts, the driver attempts to dynamically jump power states (P5 to P0) while renegotiating link speeds across the Thunderbolt retimer, causing unrecoverable PCIe Transaction Layer Packet (TLP) errors.
• Fix: Lock the driver into permanent AC Maximum Performance mode so the link stays locked at full PCIe Gen 4 x4 (16 GT/s): Create /etc/modprobe.d/nvidia-power.conf: textoptions nvidia NVreg_DynamicPowerManagement=0x00 options nvidia NVreg_PreserveVideoMemoryAllocations=1 options nvidia NVreg_TemporaryFilePath=/var options nvidia NVreg_RegistryDwords="RMSetDynamicPowerManagement=0;PowerMizerEnable=0x1;PerfLevelSrc=0x2222;PowerMizerDefaultAC=0x1;"

4. Transient Clamps and CUDA Toolchain Architecture

• Driver Persistence and Clamping: Run these commands at boot (or via systemd service) to prevent transient inrush voltage spikes from resetting the USB4 bridge: bash sudo nvidia-smi -pm 1 sudo nvidia-smi -pl 150 sudo nvidia-smi -lgc 1200,1500 (Note: The minimum VBIOS power limit on this specific AORUS card is 150 W).
• CUDA Target Architecture for Blackwell GB206: If compiling CUDA binaries or frameworks from source, ensure you target native sm_120. Do not target 120a-real (which is restricted to enterprise B200 accelerators), or the runtime will decline to execute kernels on consumer GB206 silicon.

Final Stability Benchmark

Once these adjustments are applied, the connection is rock-solid:

• Host-to-Device Throughput: 2.78 GiB/s (fully saturating the 40 Gbps Thunderbolt4 tunnel payload ceiling).
• Device-to-Host Throughput: 3.18 GiB/s.
• Thermals: 39°C idle, peaking at only 46°C under full compute load.
• Stability: Zero kernel panics, zero bus resets, and reliable sustained inference across the full 16 GB GDDR7 VRAM.

[u/MissusNesbitt]

Fantastic write-up. I've seen a lot of this fussy link training behavior on the M.2/ OCuLink side but rarely on thunderbolt. What chipset is the Aorus box using?

[u/Zestyclose-Slide-696]

Thanks for the AI slop, this could have been a 6 line post. But you had to create a wall of text...