## Description

### Regression statement

`eno1` (Realtek RTL8125 2.5GbE Controller, driver r8169) works correctly and holds a stable link on kernel **7.1.12-200.fc44.x86_64**, but exhibits continuous, severe link flapping on kernel **7.1.13-200.fc44.x86_64**. Booting back into 7.1.12 immediately and completely resolves the issue with no other configuration changes.

This is a clean bisection between two adjacent Fedora kernel builds:
- **Working:** kernel-7.1.12-200.fc44.x86_64
- **Broken:** kernel-7.1.13-200.fc44.x86_64

### Hardware

- Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05), PCI ID `[10ec:8125]`, PCI address `0000:c1:00.0`
- Driver: r8169 (in-tree, no third-party akmod/kmod-r8125 installed)
- Firmware: `rtl8125b-2_0.0.2 07/13/20`
- System: GMKtec NucBox EVO-X2 (mini PC)
- `lspci -k -s c1:00.0`:
  ```
  c1:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
  	DeviceName: OnBoard LAN
  	Subsystem: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller
  	Kernel driver in use: r8169
  	Kernel modules: r8169
  ```

### Steps to reproduce

1. Boot Fedora 44 with kernel 7.1.13-200.fc44.x86_64 on a system with an RTL8125 controller (rev 05) using the in-tree r8169 driver.
2. Observe `eno1` in NetworkManager / `journalctl -k -f`.

### Expected result

Link stays up (as it does on kernel 7.1.12).

### Actual result

Constant "Link is Down" / "Link is Up" cycling, several times per minute, for as long as the interface is used. In several instances the link also **downshifts to 100Mbps** (from the correct 1Gbps/2.5Gbps) before dropping again - 43 downshift events observed in one ~8 hour session. DHCP leases get interrupted and the connection becomes effectively unusable.

Quantified over one boot on 7.1.13 (03:05-11:08, first boot after the kernel was installed and auto-rebooted into by dnf5-automatic): **291 Link Down/Up transitions** logged by the kernel.

By contrast, over the equivalent post-boot window on kernel 7.1.12: **4 transitions total**, all within the first few seconds of boot (normal autonegotiation), then fully stable.

### Log excerpt - broken (7.1.13), first 15 of 291 events

```
sep 08 03:05:24 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 03:05:27 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 03:05:27 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 03:05:31 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 10:21:56 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:21:59 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 10:28:48 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:28:54 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:28:57 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 10:28:57 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:29:01 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 10:31:09 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:31:15 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 10:31:28 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 100Mbps/Full (downshifted) - flow control off
sep 08 10:31:28 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
```

Full 338-line excerpt attached as `bugzilla-attachment-dmesg-7.1.13-broken.log`.

### Log excerpt - working (7.1.12), complete

```
sep 08 14:05:30 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 14:05:33 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
sep 08 14:05:33 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Down
sep 08 14:05:37 fedora kernel: r8169 0000:c1:00.0 eno1: Link is Up - 1Gbps/Full - flow control off
```
(then fully stable - attached as `bugzilla-attachment-dmesg-7.1.12-working.log`)

### Additional information

- No hardware changes (cable, switch, NIC) between the two boots - same physical setup.
- No third-party driver installed; this is the stock in-tree `r8169` module in both cases.
- `akmod-r8125`/`kmod-r8125` do not currently exist in RPM Fusion (checked both free and nonfree repos, F44), so the only available driver is the in-tree r8169 - this regression cannot currently be worked around by switching to the vendor r8125 driver via RPM Fusion.
- The kernel 7.1.13 build was pulled in automatically by `dnf5-automatic` overnight with an automatic reboot, so this will affect any Fedora 44 user with an RTL8125 NIC as soon as it reaches their system, without warning.
- Workaround: pin/boot `kernel-7.1.12-200.fc44.x86_64` via `grubby --set-default=/boot/vmlinuz-7.1.12-200.fc44.x86_64`.
- This may be related to upstream r8169/RTL8125 reset-timing regressions seen in other kernel series (e.g. a Sept 2024 fix for RTL8125 reset work being placed in the link-down path instead of link-up, and a similar unresolved Debian regression for RTL8111/8168 between kernel 6.12.63 and 6.12.69 - Debian bug #1127724). A bisect of the r8169-relevant commits between the 7.1.12 and 7.1.13 Fedora kernel builds would likely find the offending change quickly given how narrow and reproducible this regression is.

### Environment

- Fedora release: 44 (Forty Four)
- Kernel (broken): 7.1.13-200.fc44.x86_64
- Kernel (working): 7.1.12-200.fc44.x86_64
- Architecture: x86_64
- NetworkManager: enabled, interface eno1


Reproducible: Always