Skip to content

Framework Desktop PCIe slot trains at Gen3 (8GT/s) despite BIOS set to Gen4 — Strix Halo GPP Bridge AGESA initialization bug #180

@pdrayton

Description

@pdrayton

Device Information

Device: Framework Desktop (AMD Ryzen AI Max 300) | BIOS: 03.04 | AGESA: StrixHaloPI-FP11 1.0.0.2

System Model or SKU

Please select one of the following

  • Framework Laptop 12 (13th Gen Intel® Core™)
  • Framework Laptop 13 (11th Gen Intel® Core™)
  • Framework Laptop 13 (12th Gen Intel® Core™)
  • Framework Laptop 13 (13th Gen Intel® Core™)
  • Framework Laptop 13 (AMD Ryzen™ 7040 Series)
  • Framework Laptop 13 (AMD Ryzen™ AI 300 Series)
  • Framework Laptop 13 (Intel® Core™ Ultra Series 1)
  • Framework Laptop 16 (AMD Ryzen™ 7040 Series)
  • Framework Laptop 16 (AMD Ryzen™ AI 300 Series)
  • Framework Desktop (AMD Ryzen™ AI 300 PRO Series)

BIOS VERSION

3.04

DIY Edition information

Storage: 2x Samsung 4TB 990 PRO PCIe 4.0 x4 M.2 Internal SSD (MZ-V9P4T0BW)

Port/Peripheral information

  1. The PCIe 4.0 x4 slot is populated with a 5cm PCIe 4.0-rated x4->x16 riser cable with a PCIe 4.0 x16 NIC in it. This NIC is the subject of the bug report - it is a "Vogzone 100GbE NIC Card for Mellanox MCX556A-EDAT, PCIe 4.0 x16 100Gb Ethernet NIC with Mellanox ConnectX-5 VPI Chipset, Dual QSFP28 EDR IB Network Card Support RDMA"
  2. Both M.2 slots have 4TB Samsung 990 PRO M.2s (the storage listed above)
  3. The A+E-key slot has the stock Framework Wi-Fi/BT card but the antennas are disconnected and WiFi/BT is not being used
  4. The internal Type-E USB headers are disconnected as no Framework expansion cards are being used
  5. The PSU is standard FWD unit but I also tested with a Silverstone FX600z to rule out insuffient power delivery

Describe the bug

On the Framework Desktop (AMD Ryzen AI Max 300 / Strix Halo), the PCIe expansion slot trains at Gen3 (8GT/s) at boot despite the BIOS slot setting being explicitly configured to Gen4. Reproduced identically on two independent Framework Desktop units.
Reading the LnkCtl2 registers immediately after boot shows AGESA has written Gen4 targets into both sides of the link (0044 on the bridge, 0004 on the card), yet the physical link has trained at Gen3. This demonstrates the PCIe PHY was initialized at Gen3 during AGESA platform bring-up and the LnkCtl2 target values were written afterward without a retrain. The BIOS Gen4 slot setting is not being honored by the PHY initialization sequence.

# lspci — link state at boot
LnkCap: Port #0, Speed 16GT/s, Width x16   ← card is Gen4 x16 capable
LnkSta: Speed 8GT/s (downgraded), Width x4  ← link trained at Gen3

# setpci — LnkCtl2 register values at boot
Bridge 00:03.2  offset 88h: 0044  ← Gen4 target (correctly written by AGESA)
Card   c3:00.0  offset 90h: 0004  ← Gen4 target (correctly written by AGESA)

Both registers contain correct Gen4 targets yet the link is at Gen3. There are no AER errors or correctable error counts — this is not a signal integrity or hardware fault.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Install a Mellanox MCX556A-EDAT card in the Framework Desktop expansion slot using any of: rigid riser; 5cm riser cable; Oculink adapter with short gen4 cable to a powered riser; MCIO PCI adapter with short 4i cable to powered riser. Yes, I tried them all. No, none of them worked. If my FWD motherboard had an open PCI slot I'd have used that, but it doesn't. However, Framework does have motherboards with open PCI slots so you can test that even if I cannot.
  2. In BIOS, confirm the PCIe slot is set to Gen4 (not Gen3)
  3. Boot the system
  4. Run the following commands:
# Check actual link speed
sudo lspci -vv -s c3:00.0 | grep -E 'LnkCap:|LnkSta:'

# Check LnkCtl2 target registers on both sides
sudo setpci -s 00:03.2 88.w   # bridge — expect 0044 for Gen4
sudo setpci -s c3:00.0 90.w   # card   — expect 0004 for Gen4

Observe that LnkCtl2 registers show Gen4 targets (0044/0004) but LnkSta reports Speed 8GT/s (downgraded) (Gen3)

I need to stress that the issue here is specifically related to these Mellanox MCX556A-EDAT cards. Other NICs e.g. the Intel E810-CQDA1 and E810-CQDA2 cards, do not have this same issue on either of my two FWD motherboards. I have tested multiples MCX556A-EDAT cards from different vendors, on both of my two FWD motherboards. No success. The Intel network cards negotiate fine at PCIe 4.0 x4. But Mellanox cards are known in industry to be demanding on their PCIe link and BIOS handshake, and it seems that either the Framework motherboard or the INSYDE BIOS does not seem to be up to the job.

Furthermore, there are reports on Reddit of folk using the MCX556A-EDAT NIC just fine on the Minisforum S1 Max, which IMO rules out the problem being something to do with Strix Halo in general. So... AFAICT the issue is on either Framework's motherboard or Framework's INSYDE BIOS.

Expected behavior

With the BIOS PCIe slot setting configured to Gen4, the Strix Halo GPP Bridge PHY should be initialized at Gen4 (16GT/s) during AGESA platform bring-up, resulting in LnkSta: Speed 16GT/s at boot.

Screenshots

N/A — full diagnostic output attached as text files from two affected units, collected via the attached collect_pcie_bug_report.sh script.

Operating System (please complete the following information):

  • OS/Distribution: Fedora Linux 43 (Server Edition)
  • Version: Fedora 43
  • Linux Kernel Version: Linux fwd1 6.18.9-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Feb 6 21:43:09 UTC 2026 x86_64
    Note: this is a firmware initialization issue observable before any OS involvement. The Gen3 link state is set by AGESA during platform bring-up and is present regardless of OS or kernel parameters.

Additional context

  • BIOS version: 03.04, released 2025-11-19
  • AMD PI / AGESA: StrixHaloPI-FP11 1.0.0.2
  • Affected units: Two independently configured Framework Desktop systems (both Ryzen AI Max 300), reproduced identically on both
  • PCIe card under test: Mellanox ConnectX-5 Ex (MCX556A-EDAT), PCIe 4.0 x16 capable — however the issue is with the platform slot initialization, not the card. I have tested the exact issue, with the exact same result, on two different MCX556A-EDAT cards, on each of the two systems.
  • BIOS slot setting: Gen4 (explicitly set; the only options available are Gen3 and Gen4)
  • OS-level retrain attempts: Confirmed non-viable. Attempting to trigger a link retrain at runtime causes the link to fall to Gen1 (2.5GT/s) and fail to recover above Gen3 without a cold reboot, consistent with the AGESA cold-boot PHY equalization being the ceiling for this platform in its current firmware state
  • No hardware fault: AER uncorrectable and correctable error counts are all zero. The Gen3 link is stable. This is purely a firmware initialization issue

pcie_bug_report_data_fwd1.txt
pcie_bug_report_data_fwd2.txt
collect_pcie_bug_report_data.sh

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions