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.
I’m seeing this on 3.04. (Upgraded from 3.03, totally fresh ubuntu install, got the desktop less than a week ago)
To follow up on Devin’s investigation, I’d like to add that I’m seeing this when I turn the device on in “headless” mode – Only things physically connected to the desktop are a power cable and the ethernet cable (Known good ethernet cable).
When I connect via wifi and run ip a it shows me a valid private network address on the wifi network, but a 169.254.x.x address for my ethernet adapter. Copy/paste:
—-
alex@magrathea ~ % ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp191s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 9c:bf:0d:01:18:65 brd ff:ff:ff:ff:ff:ff
inet 169.254.6.89/16 brd 169.254.255.255 scope link noprefixroute enp191s0
valid_lft forever preferred_lft forever
inet6 fd38:1098:e4fa:a769:b381:932e:1628:451e/64 scope global temporary dynamic
valid_lft 1790sec preferred_lft 1790sec
inet6 fd38:1098:e4fa:a769:9ebf:dff:fe01:1865/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 1790sec preferred_lft 1790sec
inet6 2600:1702:5088:9e0f:4a58:4691:3163:a1a9/64 scope global temporary dynamic
valid_lft 3453sec preferred_lft 153sec
inet6 2600:1702:5088:9e0f:9ebf:dff:fe01:1865/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 3453sec preferred_lft 153sec
inet6 fe80::9ebf:dff:fe01:1865/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
3: wlp192s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f4:4e:b4:77:eb:6f brd ff:ff:ff:ff:ff:ff
altname wlxf44eb477eb6f
inet 192.168.2.51/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp192s0
valid_lft 86385sec preferred_lft 86385sec
inet6 2600:1702:5088:9e0f:6b90:6372:5a15:e3b1/64 scope global temporary dynamic
valid_lft 3453sec preferred_lft 153sec
inet6 2600:1702:5088:9e0f:450e:713a:7e71:6cde/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 3453sec preferred_lft 153sec
inet6 fd38:1098:e4fa:a769:a7ed:410e:5b9e:31ae/64 scope global temporary dynamic
valid_lft 1791sec preferred_lft 1791sec
inet6 fd38:1098:e4fa:a769:f68a:e4d4:9001:c300/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 1791sec preferred_lft 1791sec
inet6 fe80::4dcd:3ccd:e0cf:7c94/64 scope link noprefixroute
valid_lft forever preferred_lft forever
——-
That said, once the machine is on and in this state, if I run sudo nmcli device modify enp191s0 ipv4.method auto. It “kicks” the ethernet adapter (in my case enp191s0 ) and triggers it to do a proper DHCP lookup, and suddenly I’m connected.
My first attempt at solving this was assuming there was either something in ubuntu or my networking router that was getting cranky at the one machine for trying to connect to the same network twice (once for ethernet, once for wifi), so I disabled wifi and restarted, and… it didn’t have any connection at all. So it’s not that either 
This sounds like a different issue from the one that Devin and I are having.
For us, the Ethernet device appears entirely absent. There is no pci device, thus no “enp191s0” or equivalent appears if we type “ip a”, and there is nothing to reset or execute commands on. It’s just gone sometimes.
(of course, that being said, your problem still could be related somehow, and I hope you or the Framework folks eventually find a fix!)
I still haven’t resolved my own problem, but at least I can live with it - I’m mostly using the computer as a server, so on the rare occasion I have to shut it down, rebooting it a few times until I have working ethernet is a nuisance but not a disaster.