(@jons)

Active Member

Joined: 6 days ago

Introduction

UPDATE:

Correction: the enclosure listed in the original title/post was incorrect.

This setup is using a Razer Core X V2 enclosure, not the EXP GDC TH3P4G3. During the planning phase I compared multiple eGPU solutions and the wrong enclosure name accidentally remained in my notes.

All test results and logs below are from:
- Minisforum MS-01
- Razer Core X V2 eGPU enclosure
- RTX 5060 Ti 16GB
- Ubuntu 26.04

Hardware update:
After opening the Razer Core X V2 enclosure I found a loose SMD capacitor/component inside the enclosure, apparently detached from the PCB.

Because of this discovery I have stopped further testing. The enclosure will be returned/replaced under warranty before continuing troubleshooting.

This hardware fault may explain the intermittent detection problems and the NVIDIA Xid 79 "GPU has fallen off the bus" errors under load.

Hi everyone,

I'm trying to get an eGPU working on a Minisforum MS-01, but the PCIe link never trains above 2.5GT/s x4.

I'm hoping someone with similar hardware can help determine whether this is a firmware issue, an enclosure issue, or something specific to the MS-01.

System

• Minisforum MS-01
• Intel Core i5-12600H
• BIOS 1.27 (Build date: 2025-04-03)
• Intel JHL9480 Barlow Ridge (Thunderbolt 5 / USB4 v2)
• Ubuntu Server 26.04 LTS
• Kernel 7.0.0-27-generic
• TH3P4G3 eGPU dock
• NVIDIA GeForce RTX 5060 Ti 16 GB
• NVIDIA Driver 595.71.05
• Tested with the original Thunderbolt 4 cable supplied with the TH3P4G3
• Also tested with a certified Thunderbolt 5 cable
• Same behaviour with both cables

Problem

The GPU is detected correctly and functions normally. CUDA works and the NVIDIA driver loads without errors.

However, the PCIe link always negotiates at 2.5GT/s x4 (Gen1) instead of the expected PCIe speed.

During GPU-intensive workloads (AI/CUDA), the system eventually becomes unstable and hard locks up, requiring a reboot. I suspect this may be related to the PCIe link issue, but I have not yet confirmed whether both symptoms share the same root cause.

Current status

The GPU is detected correctly.

The NVIDIA driver loads correctly.

CUDA works.

The external monitor works.

nvidia-smi works correctly.

The only problem is the PCIe link speed.

Observed PCIe link

The GPU always negotiates:

LnkCap: Speed 32GT/s, Width x8

LnkSta: Speed 2.5GT/s (downgraded), Width x4 (downgraded)

The GPU supports PCIe Gen5 x8, but the negotiated link always remains PCIe Gen1 x4.

Things already tested

• BIOS updated to version 1.27
• BIOS reset to defaults
• Thunderbolt enabled
• Different Thunderbolt/USB4 ports
• Cold boots
• Warm reboots
• Power cycling the enclosure
• GPU reseated
• Power cables checked
• Latest NVIDIA driver
• Ubuntu 26.04 fully updated
• Original Thunderbolt 4 cable supplied with the TH3P4G3
• Certified Thunderbolt 5 cable
• Same behaviour with both cables

Questions

1. Has anyone successfully used a TH3P4G3 with a Minisforum MS-01?
2. Has anyone seen the MS-01 negotiate only PCIe Gen1 (2.5GT/s) with an eGPU?
3. Could this be caused by BIOS 1.27?
4. Could this indicate a Thunderbolt controller firmware issue?
5. Are there Linux kernel parameters or BIOS settings that can force PCIe retraining?

Any ideas would be greatly appreciated.

Thanks!

Additional information

If any additional logs or specific commands would help diagnose this, I'd be happy to provide them.

This topic was modified 4 days ago

(@nando4)

Illustrious Member Admin

Joined: 10 years ago

Introduction

Hi everyone,

I'm trying to get an eGPU working on a Minisforum MS-01, but the PCIe link never trains above 2.5GT/s x4.

I'm hoping someone with similar hardware can help determine whether this is a firmware issue, an enclosure issue, or something specific to the MS-01.

LnkCap: Speed 32GT/s, Width x8

LnkSta: Speed 2.5GT/s (downgraded), Width x4 (downgraded)

@jons, welcome aboard.

The reporting of 2.5GT/s x4 may simply be the PCIe link in low power standby mode and/or just misreporting due to the numerous Thunderbolt controllers and bridges between the system and GPU.

A better way to check if performance is as expected for your hardware combo is to use CUDA-Z to measure H2D memory writes and see it matches the expected 32Gbps-TB4 eGPU port acronym in the perf table.

64Gbps PCIe 4.0 x4 over 80Gbps Intel Thunderbolt 5 / USB4v2 ETA starting 2024   •   eGPU Bandwidth Reference   •    eGPU Setup 1.35
 
2018 15" HP ZBook Studio G5 (Q P1000) [8th,6C,E] + RX 6700 XT @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 22H2 // compares M.2 NVMe vs TB3 & RX 6700 XT vs RTX 3070 eGPU, 2.06kg triple-M.2 NVMe slot budget Workstation [info]
 
2018 14" HP EliteBook 840 G5 [8th,4C,U] + RX 6700 XT @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 22H2 // compares M.2 NVMe vs TB3 & RX 6700 XT vs RTX 3070 eGPU, 1.48kg dual-M.2 slot budget UltraBook [info]

 
2015 15" Dell Precision 7510 (Q M1000M) [6th,4C,H] + GTX 1080 Ti @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 1803 // compares M.2 NVMe vs TB3 eGPU performance inc unoptimized H-CPU BIOS [build link]  

(@jons)

Active Member

Joined: 6 days ago

@nando4, 

Thanks for the suggestion.

That’s a good point. I understand that lspci may not always report the effective PCIe link correctly because of the multiple Thunderbolt/PCIe bridges involved.

One additional symptom is that during sustained CUDA/AI workloads the system eventually hard locks up and requires a reboot, so I’m trying to determine whether the reported PCIe link and the system instability are related or two separate issues.

Since this system runs Ubuntu 26.04, would a Linux CUDA bandwidth benchmark (for example the CUDA Samples bandwidthTest) be an acceptable alternative to CUDA-Z? If so, I’ll run it and post the Host-to-Device (H2D) bandwidth results.

(@jons)

Active Member

Joined: 6 days ago

@nando4, 

Thanks again for the suggetion. I ran the CUDA bandwithTest on Ubuntu 26.04.

Results:

Host to Device Bandwidth:
Pinned memory, 32,000,000 bytes: 2.9 GB/s

Device to Host Bandwidth:
Pinned memory, 32,000,000 bytes: 4.0 GB/s

Device to Device Bandwidth:
Pinned memory, 32,000,000 bytes: 389.0 GB/s

Result = PASS

So the lspci-reported 2.5GT/s x4 link may indeed not reflect the effective transfer bandwidth directly. 😉 

However, the remaining issue is that under sustained AI/CUDA workloads the system eventually hard locks and requires a reboot. So the bandwidth may be acceptable, but the stability issue remains.

Thanks again nfor pointing toward the test.

(@jons)

Active Member

Joined: 6 days ago

Update: I was able to reproduce the failure during a sustained CUDA nbody loop.

The system first remained partially responsive, but the NVIDIA GPU disappeared from nvidia-smi while still being visible in lspci. A clean reboot then failed and the machine eventually required a hard power reset.

Relevant kernel messages:

NVRM: Xid (PCI:0000:05:00): 79, pid=1781854, name=nbody, GPU has fallen off the bus.
NVRM: GPU 0000:05:00.0: GPU has fallen off the bus.
NVRM: Xid (PCI:0000:05:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)
NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.

After the failure:

• nvidia-smi reported: No devices were found
• lspci still showed the RTX 5060 Ti at 05:00.0
• boltctl still showed the Razer Core X V2 authorized at 40 Gb/s RX/TX

So the issue is now reproducible as: RTX 5060 Ti eGPU falls off the bus under sustained CUDA compute load.

(@nando4)

Illustrious Member Admin

Joined: 10 years ago

Update: I was able to reproduce the failure during a sustained CUDA nbody loop.

The system first remained partially responsive, but the NVIDIA GPU disappeared from nvidia-smi while still being visible in lspci. A clean reboot then failed and the machine eventually required a hard power reset.

..

• boltctl still showed the Razer Core X V2 authorized at 40 Gb/s RX/TX

So the issue is now reproducible as: RTX 5060 Ti eGPU falls off the bus under sustained CUDA compute load.

@jons, just to clear up confusion, in your last message you refer to a Razer Core X V2 TB5 enclosure, yet in your opening post you refer to a EXP GDC TH3P4G3 TB3 enclosure.

May I ask which it is?

This is because:

1. under Linux OS, we have numerous TB5 enclosure builds requiring additional steps to stabilizing that may solve your issue

2. if not a TB5 enclosure, then this symptom can also be due to some hardware fault in the eGPU chain.

Can isolate if it's a OS issue by booting Win10/Win11 and performing a Furmark test to see if the eGPU hardware chain is stable under full load conditions.

64Gbps PCIe 4.0 x4 over 80Gbps Intel Thunderbolt 5 / USB4v2 ETA starting 2024   •   eGPU Bandwidth Reference   •    eGPU Setup 1.35
 
2018 15" HP ZBook Studio G5 (Q P1000) [8th,6C,E] + RX 6700 XT @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 22H2 // compares M.2 NVMe vs TB3 & RX 6700 XT vs RTX 3070 eGPU, 2.06kg triple-M.2 NVMe slot budget Workstation [info]
 
2018 14" HP EliteBook 840 G5 [8th,4C,U] + RX 6700 XT @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 22H2 // compares M.2 NVMe vs TB3 & RX 6700 XT vs RTX 3070 eGPU, 1.48kg dual-M.2 slot budget UltraBook [info]

 
2015 15" Dell Precision 7510 (Q M1000M) [6th,4C,H] + GTX 1080 Ti @ 32Gbps-M.2x4 (ADT-Link R43SG) + Win10 1803 // compares M.2 NVMe vs TB3 eGPU performance inc unoptimized H-CPU BIOS [build link]  

(@jons)

Active Member

Joined: 6 days ago

Small update and clarification.

First of all: thanks for pointing out the confusion about the enclosure model. You were right.

The EXP GDC TH3P4G3 reference in my earlier post was my mistake. During the initial planning phase I compared several eGPU options, including TH3P4G3-type solutions, and that name accidentally remained in my notes.

All tests and logs posted here were actually performed with a Razer Core X V2 enclosure, as detected by Linux/boltctl.

Sorry for the confusion.

I also have an important hardware update.

After opening the Razer Core X V2 enclosure for inspection, I discovered a loose SMD capacitor/component inside the enclosure. It appears to have detached from the eGPU PCB.

This could explain the unstable behavior I observed:
- the same eGPU setup was not reliably detected on two Windows laptops
- the MS-01 with Ubuntu could detect the GPU
- NVIDIA drivers loaded successfully
- CUDA workloads initially worked
- under sustained CUDA load the GPU failed with:
- Xid 79: GPU has fallen off the bus
- followed by Xid 154 / Node Reboot Required
- after failure, a normal reboot could hang and only a full power cycle restored the GPU

Considering this hardware finding, I will stop further testing for now to avoid risking damage to the GPU.

I will return/RMA the Razer Core X V2 enclosure under warranty and continue troubleshooting with a replacement unit.

Once I receive the replacement enclosure I will update this thread with new Windows and Linux test results.

Thank you for helping narrow this down.

(@jons)

Active Member

Joined: 6 days ago

@morgwai, 

Thanks for your reply. One important correction from my side: I mixed up the enclosure information.

My actual setup is:

• Minisforum MS-01 (USB4/TB4)
• Razer Core X V2 Thunderbolt 5 eGPU enclosure
• RTX 5060 Ti 16GB
• Ubuntu 26.04

So your TB5 comments may indeed be relevant.

However, I found a hardware issue: a capacitor had physically detached from the Razer Core X V2 PCB.

This could explain the random behavior (Windows detection issues, Linux working initially, then NVIDIA Xid 79 “GPU fallen off the bus”).

I have returned the enclosure under warranty. I’ll retest everything with the replacement unit first before continuing software troubleshooting.

Thanks for the help!