Framework Desktop Ethernet Not Working on Cold Boot (RTL8126)

Summary

The Framework Desktop's built-in Realtek RTL8126 5 GbE Ethernet controller is completely invisible to the OS on approximately 36-50% of cold boots. The device does not appear in lspci at all. A warm reboot (restart from within the OS) reliably brings it back. The root cause is a PCIe link training failure at the GPP bridge level — a firmware-level bug¹.

Symptoms

• Ethernet controller missing from lspci on cold boot¹
• lspci shows the GPP bridge (00:02.1) but no child device underneath it
• ip link shows no enp* Ethernet interface
• dmesg shows no Realtek RTL8126 initialization messages
• A warm reboot fixes it every time — the device appears after restarting from within the OS¹
• Failure rate estimated at 36-50% of cold boots based on community tracking¹
• Reproduced on BIOS 3.02 and 3.04 (not yet tested on 3.05/3.06)¹

Affected Models

• Framework Desktop (all configurations) — AMD Ryzen AI Max 385 and Max+ 395¹

Root Cause

The Realtek RTL8126 Ethernet controller connects to the CPU via a PCIe GPP bridge (00:02.1). On cold boot, the PCIe link training sequence fails for this device — the controller never establishes a link with the bridge, so it never enumerates and does not appear in lspci¹.

A warm reboot does not fully power-cycle the PCIe bus (the EC retains some state), so the link training succeeds on the second attempt. This is a firmware/BIOS-level bug in the PCIe initialization sequence, not an OS driver issue¹.

Diagnosis

1. Check if the device appears in lspci:

   lspci | grep -i ethernet

   If nothing appears, the PCIe device did not enumerate.

2. Check for the GPP bridge without a child device:

   lspci -t -v

   Look for 00:02.1 — if the bridge exists but has no child, link training failed.

3. Verify the fix:

   sudo reboot

   After warm reboot, check lspci again — the RTL8126 should appear.

4. Check kernel logs:

   dmesg | grep -i 'r8169\|rtl8126\|eth'

   If no messages appear, the device was never visible to the kernel.

Workarounds & Fixes

Solution	Effectiveness	Notes
Warm reboot1	Always works	Restart from within the OS (sudo reboot). The device will appear after reboot. Not practical for headless/remote setups
Remove USB peripherals at boot1	Reduces failure rate	Disconnecting all USB devices before cold boot appears to reduce the failure rate, possibly by reducing PCIe bus contention during initialization
nmcli device modify for DHCP1	Workaround for link issues	If the device appears but doesn't get an IP: nmcli device connect enp<something> — may kick DHCP into retrying
Use a USB Ethernet adapter	Reliable workaround	Bypasses the built-in controller entirely. See expansion card Ethernet options

Resolution

No fix exists as of BIOS 3.06 (July 28, 2026). The issue has been reported on Framework Community and tracked since November 2025¹. It has not been explicitly addressed in any BIOS release notes (3.03 through 3.06).

Framework has not publicly acknowledged this as a Known Issue in BIOS release notes. Users should report it via the Framework Community thread and the GitHub issue tracker.

Related

• Ethernet not working on first cold boot — Framework Community (Nov 10, 2025, active through 2026)
• Framework Desktop — Known Issues

Footnotes

1. Ethernet not working on first cold boot but does after restart — Framework Community (Nov 10, 2025) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²