Hi all,
I’m having a strange issue where the built-in Ethernet on my Framework Desktop almost always appears invisible to the OS when the machine is first powered on.
And I do mean “invisible”: in linux, for example, the output of ‘lspci’ is simply missing two devices until I reboot.
00:02.1 PCI Bridge: [….] Strix Halo GPP Bridge (rev 02) […]
bf:00.0 Ethernet controller: Realtek Semiconductor co., Ltd RTL8126 5Gbe […]
As soon as I restart the computer, they suddenly appear again and the OS acts like everything is fine. Doesn’t appear to matter how I restart it, as long as I don’t power it off.
Anyway, this is all very weird, and I’m just wondering if anyone else has a similar problem or any idea what might be going on.
I’m pretty confident it’s not an OS problem, since it happens regardless of OS, and of course I’ve tested the officially supported ones.
but to make things even stranger, the ethernet hardware itself also seems to be working ok before the OS tries is booted. The UEFI network stack seems fine - I can boot into a UEFI shell with it enabled and the hardware is visible and works perfectly.
Thanks in advance for any insight (or at least commiseration) any of you can provide.
Double check that you are on the latest Realtek drivers. My ethernet connectivity drops randomly too on Windows 11 but I have upgraded since and it seems to be doing better within the last few days.
I will say simply disabling the ethernet and reenabling on Windows works for me. There was one time I had to reboot the machine in order to get connectivity back but that was with the bundled Realtek drivers from Framework which are also very outdated.
This is happening to me too, but I would say only about 50% of the time. For reference, I’m on NixOS 25.05 with Linux kernel 6.17.11. Comparing the boot logs between a good and bad run, it appears that on a bad run the ethernet PCI device is completely absent.
Good:
Dec 13 15:03:54 frame kernel: pci 0000:00:02.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
Dec 13 15:03:54 frame kernel: pci 0000:00:02.1: [1022:150b] type 01 class 0x060400 PCIe Root Port
Dec 13 15:03:54 frame kernel: pci 0000:00:02.1: PCI bridge to [bus bf]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.1: bridge window [io 0x2000-0x2fff]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.1: bridge window [mem 0xb1100000-0xb11fffff]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.1: PME# supported from D0 D3hot D3cold
Dec 13 15:03:54 frame kernel: pci 0000:00:02.3: [1022:150b] type 01 class 0x060400 PCIe Root Port
Dec 13 15:03:54 frame kernel: pci 0000:00:02.3: PCI bridge to [bus c0]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.3: bridge window [mem 0xb0600000-0xb08fffff]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.3: PME# supported from D0 D3hot D3cold
Dec 13 15:03:54 frame kernel: pci 0000:00:02.5: [1022:150b] type 01 class 0x060400 PCIe Root Port
Dec 13 15:03:54 frame kernel: pci 0000:00:02.5: PCI bridge to [bus c1]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.5: bridge window [mem 0xb1000000-0xb10fffff]
Dec 13 15:03:54 frame kernel: pci 0000:00:02.5: PME# supported from D0 D3hot D3cold
Bad (note lack of pci 0000:00:02.1):
Dec 13 14:27:15 frame kernel: pci 0000:00:02.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
Dec 13 14:27:15 frame kernel: pci 0000:00:02.3: [1022:150b] type 01 class 0x060400 PCIe Root Port
Dec 13 14:27:15 frame kernel: pci 0000:00:02.3: PCI bridge to [bus bf]
Dec 13 14:27:15 frame kernel: pci 0000:00:02.3: bridge window [mem 0xb0600000-0xb08fffff]
Dec 13 14:27:15 frame kernel: pci 0000:00:02.3: PME# supported from D0 D3hot D3cold
Dec 13 14:27:15 frame kernel: pci 0000:00:02.5: [1022:150b] type 01 class 0x060400 PCIe Root Port
Dec 13 14:27:15 frame kernel: pci 0000:00:02.5: PCI bridge to [bus c0]
Dec 13 14:27:15 frame kernel: pci 0000:00:02.5: bridge window [mem 0xb1000000-0xb10fffff]
Dec 13 14:27:15 frame kernel: pci 0000:00:02.5: PME# supported from D0 D3hot D3cold
Asking Claude for a diagnosis, it gives the following advice:
Likely Causes
This is typically a PCIe link training failure or power sequencing issue at the hardware/firmware level. The intermittent nature suggests timing-sensitive initialization.
Recommendations
-
Update BIOS/firmware - You’re on BIOS 03.04 (dated 11/19/2025). Check Framework’s support site for any newer versions that might address PCIe initialization issues.
-
Try kernel parameters - Add these to your boot command line to test:
-
pcie_aspm=off - Disables PCIe Active State Power Management
-
pci=nommconf - Forces legacy PCI config access
-
pci=realloc - Forces PCIe resource reallocation
-
Check boot patterns - Does this happen more on cold boots vs. warm reboots? That would point to power sequencing.
-
Report to Framework - This looks like a firmware-level bug where the PCIe root port at 00:02.1 (likely GPP2 in AMD terminology) intermittently fails to initialize. Framework support should know about this.
I haven’t tried any of the kernel parameters suggestions yet, but will report back later.
For reference, I tried all of the kernel parameters individually, but none of them fixed the issue. I also tried to downgrade the PCIe lane link speed from Gen 4 to Gen 3 in the bios (not sure if that effects the PCIe lane in question or not), but that did not work either.
Sorry or not seeing this earlier. My team as we have time looks for issues in Linux - Framework Community but here in Framework Desktop - Framework Community so I almost missed this. That said, as this appears to be a cross platform occurrence, posting here makes sense.
Your concern is valid. This does look like a firmware related issue. Did this occur after a Framework firmware upgrade or after a general software in OS upgrade?
Please include replies to that and this thread, open a support ticket and ask to have it escalated to me directly please.
@Matt_Hartley thanks for the response. I opened a support ticket a couple days ago titled “Potential hardware or firmware issue” that you might be able to search for (I will also reply to the support ticket and ping your name).
At a minimum, the issue was happening on both firmware 3.02 and 3.04. I will go further back through my boot logs to see if there was a specific point in time where this was happening. (I may have not noticed it if wifi was working, TBD.)
Devin’s symptoms do seem awfully similar to the ones I originally posted about. In fact, after I made changes to the USB peripherals I had plugged into the computer on boot (see below), our situation seems almost identical - the problem occurs on ~50% of cold boots.
In my case, I started with BIOS 3.02 (I think), and upgraded to 3.03 and then to 3.04 as soon as it came out. 3.03 didn’t appear to improve things but didn’t make them worse either. I’ve only had to cold boot the computer once or twice since installing 3.04, so I can’t comment on whether it had any effect.
What did seem to help was removing several devices I had plugged in at boot. I originally had both an external USB hard drive and a USB-C powered (displayport alt mode) monitor plugged in at boot. In testing, I discovered that waiting to plug one or both of these in until after boot would also make the ethernet much more likely to show up correctly.
For what it’s worth, I have the bare motherboard version of the framework desktop.
In case the problem was somehow caused by my own hardware choices, I tried swapping to a different power supply (a comically large but known good 1000 watt corsair PSU) instead of the 500w supply I’d been using previously. That didn’t appear to change things at all, so I switched back.
I also tried various kernel parameters and bios setting changes, none of which had any effect. (the problem also occurred on windows in addition to the various linux distros I ran)
I can file a support ticket also if it’d be helpful to get both of us in that system.
I’ve been able to verify that this does not seem to be a new issue for me. The first noted failure was from a boot configuration I built on 2025-10-12 with kernel 6.17.1. I’m was able to roll back the OS software to previous NixOS generations and verify the issue is still present (verified on a few different configurations of NixOS 25.05 with kernels 6.17.0, 6.17.1, 6.17.8, and 6.17.11). (I did a pretty thorough bisections which took a while to do since the issue only happens some of the time.) I did not rollback to the firmware version 3.02 since I’ve already verified it fails on both 3.02 and 3.04, but I could try that as well if there is evidence that 3.02 and an older kernel version does not fail in the same way.
As far as numbers go, looking at the totality of my boot log, I had 30 boots with successful ethernet and 17 boots without successful ethernet (this was before my bisect test which added a lot of additional boots), which equates to about a 36% failure rate.
I tried a minimal USB setup exactly once; removed USB strip, USB controller, audio interface, and mouse, leaving just the keyboard plugged in, but that had a ethernet failure on my first attempt.