I Said External GPUs Do Not Work Over Thunderbolt. Then One Did — The Cause Was My Own Leftover Setting

2026年8月24日

17 August 2026

On 3 August I wrote that external GPUs do not work over Thunderbolt. I had tried three cards through the same path — an RTX 5060 Ti, an RTX 3060 and an Intel Arc B580 — and none of them worked.

At that point my conclusion was that Thunderbolt was a dead end. Move the card to OCuLink and everything runs, so use OCuLink.

Then I got hold of a Radeon RX 9060 XT, connected it through the same path, and it worked. Far enough to measure inference speed and power draw.

What was different?

This is a record of what I actually ran here. The work was done on 16–17 August 2026.

The earlier article is here.

The short version: the cause was a setting I had left behind

Let me say it up front. It was not the GPU and it was not the cable. It was a boot-time setting I had added for an earlier investigation and never removed.

What makes it worse is when I added it: I was trying to get an Intel Arc B580 working over OCuLink, and that attempt never succeeded either. Leftovers from a failed investigation were blocking the next one.

How I tested: the same GPU over two kinds of connection

I connected the same graphics card to one mini PC (GMKtec EVO-X2) two different ways — once over Thunderbolt, and once over OCuLink, a separate port. The OS was Ubuntu.

Two things were stopping it. Here they are in order.

Wall one: the GPU had no address space to sit in

Here is the state right after plugging it in.

The card itself is seen properly. The VBIOS is read, and the 16GB of GDDR6 is detected correctly. Only the last step is failing.

What fails is mapping a single page of memory so the GPU can reach it. That is a tiny allocation, so this is not a capacity problem.

Five leftover options in the boot settings

Looking at the config file:

The filename says it: this was written while trying to get the B580 running. Everything I tried back then was still there.

The troublemaker is pci=nocrs. It tells the kernel to ignore the address ranges the firmware declares and assign its own. It is a last-resort option for when nothing else works, not something to leave switched on.

I removed it, leaving just pci=realloc. That was the only change.

After a reboot, the driver claimed the card without complaint.

The card that already worked also got faster

There was an unexpected side effect. The link speed of the RTX 5060 Ti on OCuLink changed.

The leftover setting was not only stopping the external GPU from working, it was also holding back the card that did work. Leaving options from an old investigation in place turns out to cost more than I expected.

Wall two: the GPU stayed asleep and never woke up

The driver claimed the card, and then things went strange.

Every status query on the GPU came back as “device busy" and returned nothing. Launching the benchmark tool produced no output after 90 seconds. Anything that touched the card simply stopped there.

Putting it beside the integrated GPU made the difference obvious.

Runtime power management had put the idle GPU to sleep. Normally you just wake it up again, but over Thunderbolt that wake-up does not go through.

Looking around, a setup guide written by someone running external GPUs on the same family of mini PC describes exactly this fix: resuming the GPU can fail when it happens often, so turn runtime power management off.

So I did, for this one device only.

Something that would not return in 90 seconds now takes 0.3 seconds. A difference that blunt leaves no room for doubt.

At this point all three GPUs were visible.

I tried NVIDIA too. That one did not work

An obvious question follows. If the cause was a boot setting, would the NVIDIA card that failed last time now work?

I moved my RTX 3060 onto the same Thunderbolt path and tried.

It got further, but it did not work.

Last time the card was not even visible. This time it links at Gen4 and the driver claims it. The boot-setting fix clearly helped NVIDIA as well.

It stops after that. I applied the same power-management fix that worked for AMD, and it did not get past.

What I could not verify: the limits of this test

What I tested was one mini PC (an EVO-X2) with these particular graphics cards. A few things I cannot tell you:

• Whether other mini PCs behave the same. Address allocation differs by model
• Why the NVIDIA card never woke up. Removing the setting did not bring it back
• I measured whether it runs, not how fast — speed is a separate article

In summary: the cause was a setting I had left behind, not the hardware

• An external GPU over Thunderbolt now works on Linux here — the same setup I wrote off last time
• The cause was a boot setting I had left behind: pci=nocrs, added during an earlier investigation
• That setting was also holding back the OCuLink card (Gen1 to Gen4 once removed)
• The second wall was runtime power management. Over Thunderbolt a sleeping GPU cannot be woken, and anything touching it hangs
• NVIDIA got further but still did not work. Same machine and settings, different result by vendor

The lesson I take from this is that leaving settings behind from an investigation that failed is dangerous. What I added to chase the B580 stopped the next investigation entirely, and slowed down a GPU that was working fine.

If you are stuck with an external GPU, suspect your own boot settings first. It is worth checking before you replace the card or the cable.

Now that it runs, the next step is measuring it. Thunderbolt is said to be narrow — how much does that actually matter?

The hardware I used for this test

The eGPU dock the card sits in (it has both OCuLink and Thunderbolt)

[kimono_product id="16563″]

The graphics card I used for these measurements

[kimono_product id="17102″]

Test environment: GMKtec EVO-X2 (Ryzen AI Max+ 395, 128GB unified memory) / Ubuntu 24.04 / kernel 7.0.0-29 / Radeon RX 9060 XT 16GB (Thunderbolt) / RTX 5060 Ti 16GB (OCuLink) / RTX 3060 12GB. Carried out 16–17 August 2026.