RX 9060 XT eGPU on Framework 13 (7840U) stuck at PCIe Gen1 x1. Same dock and cables run Gen3 x4 on Intel. Pop!_OS 24.04 beta on both

Hi folks,

I could use some help on an eGPU problem that looks like a platform/firmware quirk on my AMD Framework 13 (7840U). The exact same dock and the same two TB4 cables work as expected on an Intel laptop, but on the Framework the eGPU path keeps negotiating PCIe Gen1 x1 at the root. That lines up with the bad performance and low board power I’m seeing in games. Both machines are running Pop!_OS 24.04 beta.

Below is everything I tried, what the system reports, and how I compared it against an Intel host. I included copy-pastes so you can see the actual evidence.

Hardware

  • Laptop 1: Framework 13 AMD mainboard (Ryzen 7 7840U)
  • Laptop 2: Intel Comet Lake host (ThinkPad X1 Carbon in my test)
  • eGPU: AMD Radeon RX 9060 XT (PCI ID 1002:7590) in a DIY TB3/TB4-compatible GPU dock (AliExpress WKGL17 family, shows up as vendor “TB4 HOME, device TB4 eGFX”)
  • Cables: two separate 40 Gbps TB4 cables tested
  • External monitor connected to the eGPU outputs
  • OS on both: Pop!_OS 24.04 beta

Symptoms on the AMD Framework

  • Poor frame rate in multiple demanding games. GTA V was one example. No frame caps or vsync. Proton versions swapped, no change.
  • GPU board power is low and fans often idle even under load.
  • sclk will jump, but PCIe bandwidth appears bottlenecked.
  • Hotplug hangs the system, so I cold boot to change ports.

What the AMD system reports

Thunderbolt layer looks fine

The dock shows up consistently at 40 Gbps in both directions.

$ boltctl list
 ● TB4 HOME TB4 eGFX
   vendor: TB4 HOME
   generation: Thunderbolt 3
   status: authorized
   rx speed: 40 Gb/s = 2 lanes * 20 Gb/s
   tx speed: 40 Gb/s = 2 lanes * 20 Gb/s

Thunderbolt sysfs also matches:

/sys/bus/thunderbolt/devices/0-2/vendor_name:TB4 HOME
/sys/bus/thunderbolt/devices/0-2/device_name:TB4 eGFX
/sys/bus/thunderbolt/devices/0-2/device:0x2

GPU is present and mapped to the TB chain

$ lspci -nn -s 07:00.0 -vv | sed -n '1,2p'
07:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:7590] (rev c0)
  Subsystem: Sapphire Technology Limited [1da2:a493]

Full PCIe path as shown by lspci -t on the AMD host:

-[0000:00]---03.1-[03-61]----00.0-[04-61]----01.0-[05-61]----00.0-[06-07]----00.0-[07]----00.0

That means the upstream root for this branch is 00:03.1.

The bottleneck at the root port on AMD

00:03.1 always shows Gen1 x1 when the eGPU is attached there:

$ sudo lspci -s 00:03.1 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #247, Speed 2.5GT/s, Width x1
LnkSta: Speed 2.5GT/s, Width x1

I also saw the dock occasionally land under 00:04.1, which is the same story:

$ sudo lspci -s 00:04.1 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 2.5GT/s, Width x1
LnkSta: Speed 2.5GT/s, Width x1

There are good root ports in this machine, for example 00:02.4 reports Gen4 x4 capability and usually negotiates Gen3 or Gen4, but my TB chain never ends up under that one with this dock:

$ sudo lspci -s 00:02.4 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 8GT/s, Width x4   # when something else is hung off it

So the TB path that contains the eGPU keeps getting routed to the “slow” root complex function.

GPU power and activity on AMD

ROCm SMI confirms low power when the link is bad. A couple of representative snapshots:

Idle or light load:

"Average Graphics Package Power (W)": "26.0"
"pcie_link_width (Lanes)": "4"
"pcie_link_speed (0.1 GT/s)": "80"
"GPU use (%)": "11"

In GTA V, still not pulling anywhere near PPT and frames are unstable:

"Average Graphics Package Power (W)": "70.0"
"Voltage (mV)": "861"

I also tried:

  • forcing performance level
  • max PPT via power1_cap where available
  • checking pp_power_profile_mode and gpu_metrics

Ports/reboot/cables

  • Tried both rear USB4 ports on the Framework (these are the only USB4 ones for this board)
  • Two separate TB4 cables
  • Cold boot for dock and laptop each time
  • Hotplug is unstable on this host, so avoided

Result is consistent. The eGPU branch heads under 00:03.1 or 00:04.1 and negotiates 2.5 GT/s x1.

Comparison on the Intel laptop

Same dock and cables. Same OS version. Here the path is clean and bandwidth is what we want.

Find the GPU and show the PCIe tree

$ EGPU=0000:32:00.0
$ lspci -t -s ${EGPU#0000:}
-[0000:00]---1d.4-[05-52]----00.0-[06-52]----04.0-[2e-52]----00.0-[2f-52]----01.0-[30-52]----00.0-[31-32]----00.0-[32]----00.0

Upstream root here is 00:1d.0 or 00:1d.4 depending on the bridge view.

Root port link on Intel is correct:

$ sudo lspci -s 00:1d.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Speed 8GT/s, Width x4
LnkSta: Speed 8GT/s, Width x4

sysfs:

/sys/bus/pci/devices/0000:00:1d.0/current_link_speed = 8.0 GT/s PCIe
/sys/bus/pci/devices/0000:00:1d.0/current_link_width = 4

Thunderbolt bridges on the Intel chain

The bridge that actually carries the GPU tunnel reports Gen3 x4:

$ sudo lspci -s 2f:01.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #1, Speed 8GT/s, Width x4
LnkSta: Speed 8GT/s, Width x4

Another adjacent TB hop shows 2.5 GT/s x4 on paper, but that is not the hop used by the GPU tunnel i think is a common Alpine Ridge quirk? The important one is the one above which is 8.0 x4.

Internal AMD switch on the card

As expected:

Parent 31:00.0: LnkSta: Speed 32GT/s, Width x16
GPU   32:00.0: LnkSta: Speed 32GT/s, Width x16

Thunderbolt identification on Intel

$ boltctl list
 ● TB4 HOME TB4 eGFX
   vendor: TB4 HOME
   generation: Thunderbolt 3
   rx/tx: 40 Gb/s each way

What I tried on AMD that did not resolve it

  • Switched between both rear USB4 ports
  • Two separate 40 Gbps TB4 cables
  • Cold boot sequences for both dock and laptop
  • Updated BIOS and firmware to latest available
  • Kernel driver stack as shipped with Pop!_OS 24.04 beta
  • Forced perf level, power caps, profiles
  • Verified external monitor is cabled to the eGPU
  • Proton versions for games to rule out Wine quirks

None of that moved the upstream root negotiation off 2.5 GT/s x1.

Dock chipset identification

The dock introduces Intel Thunderbolt 3 bridges. On AMD I saw:

03:00.0 / 04:01.0: Intel DSL6340 Thunderbolt 3 Bridge [8086:1576]

On Intel I saw Alpine Ridge 4C in front of the 2C bridges:

05:00.0 .. 06:04.0: Intel JHL6540 Thunderbolt 3 Bridge [8086:15d3]
2e:00.0 / 2f:01.0: Intel DSL6340 Thunderbolt 3 Bridge [8086:1576]

So the enclosure is using Intel Alpine Ridge silicon, which is fine for TB3 eGPU. The TB layer shows 40 Gb/s. That aligns with the good results on the Intel host.

Commands I used to identify it:

for d in /sys/bus/thunderbolt/devices/*; do
  echo "== $(basename "$d") ==";
  grep -H . $d/{vendor_name,device_name,device,device_revision,unique_id} 2>/dev/null
done

for b in 03:00.0 04:01.0 2e:00.0 2f:01.0; do
  sudo lspci -nn -s $b -vv | sed -n '1,3p'
done

Where I think the bug is

  • The dock and both TB4 cables are good. Verified on an Intel laptop where the GPU path is PCIe Gen3 x4 end to end and everything looks normal.
  • On the Framework 7840U, the eGPU branch keeps landing under 00:03.1 or 00:04.1 which only support or only negotiate 2.5 GT/s x1. That matches the poor real-world performance and low power draw.
  • There are good root ports on this machine that can do Gen3 or Gen4 x4 (00:02.4, 00:08.x), but the eGPU chain is not routed there.

This feels like a routing or capability exposure problem in firmware or the USB4/TB stack on the AMD platform, not a GPU or dock fault?

If anyone can confirm any of the following:

  • Anyone in the Framework/AMD usebase: is there a known issue with USB4 routing or root port assignment on the 7840U board that pushes eGPU tunnels under 00:03.1 or 00:04.1 at Gen1 x1? i dont think eGPUs are officially supported on the 7040 series motherboards, but there are many examples of people using eGPUs in the wild, and USB4 should? be compatible with these tb docks?
  • Any firmware settings, NVRAM knobs, or kernel parameters that force the TB eGPU path to a Gen3 x4 root port like 00:02.4?
  • If someone has a similar AMD Framework setup with a TB eGPU working at Gen3 x4, I’d love to see your lspci -t and the LnkSta lines for your root port and TB bridges :slight_smile:

steps to reproduce:

On the host that is misbehaving:

EGPU=$(lspci -Dn -d 1002:7590 | awk '{print $1; exit}')
echo "EGPU=$EGPU"

lspci -t -s ${EGPU#0000:}

ROOT=$(readlink -f /sys/bus/pci/devices/$EGPU | tr '/' '\n' | grep -E '^0000:' | head -n1)
echo "ROOT=$ROOT"
sudo lspci -s ${ROOT#0000:} -vv | grep -E 'LnkCap:|LnkSta:'

for b in 2e:00.0 2f:01.0 03:00.0 04:01.0; do
  sudo lspci -s $b -vv | grep -E 'LnkSta:' || true
done

boltctl list

On a known good host, the same set should read 8.0 GT/s x4 at the root and on the active TB hop.

Happy to run more tests if anyone has any ideas. Thanks in advance for any thoughts on getting this eGPU off of the slow 2.5 GT/s x1 root on the AMD Framework.

Could it simply be that the CPU only allocate a single PCIe lane to the eGPU?

Even if that is the case (i honestly dont know enough about whats going on under the hood), thats not expected behavior right? Theres nothing i can see in the framework bios that would toggle this - and i’ve tweaked all the knobs i can think of in linux to get it going. They actually explicitly mention eGPU support via “Fully Capable USB 4 ports”, and many users on the forums mention successfully using TB3 eGPUs

If it is the CPU only allocating one lane, then it is a hardware problem stemming from that particular CPU only dedicating one lane to the eGPU slot (or USB4 port).

You could possibly change the number of lanes in BIOS, but other than that the CPU simply does not support and x4 eGPU port, only an x1 eGPU.

Possible, but seems unlikely given I can see the other roots advertising 4x4 in Linux - the CPU definitely officially supports x4, and both usb4 ports with full bandwidth are showing the same behaviour - seems more likely to be some sort of firmware bug than a hardware issue? I think this GPU dock is using quite an old tb3 chipset

Right, then it seems to me the best course of action is to contact the AMD driver team about this and raise it as a potential bug.

Unfortunately, the number of people using eGPU and Linux are a pretty small overlap, so it is quite possible this was never extensively tested. It is also possible Framework is to blame here for a faulty motherboard.

Since you have done your due diligence here, I believe reaching out is the next logical step.