GTR9 Pro: second RTL8127 10GbE port (PCIe 00:03.2) disappears after every reboot or soft power-off; only unplugging AC power restores it (BIOS GTRPRPI1001C)
SUMMARY
One of the two RTL8127 10GbE ports on my GTR9 Pro stops working after any warm reset. The controller behind PCIe root port 00:03.2 is missing after an OS reboot, after a soft power-off and power-on, and even after just entering BIOS setup and choosing Save & Exit. The root port itself disappears from the PCI bus as well. Only removing AC power and plugging it back in restores it. The other RTL8127 (root port 00:02.1) is never affected. I first noticed it after waking from sleep as well.
The tests below show it is not caused by the OS or driver, and not by the PCIe reference clock. The firmware analysis below suggests that this controller never receives a PCIe fundamental reset (PERST#) on warm resets.
SYSTEM
- Beelink GTR9 Pro (AMD Strix Halo)
- BIOS GTRPRPI1001C (release note says based on GTRPR05)
- Two Realtek RTL8127 10GbE controllers, rev 05, subsystem 10ec:0123:
LAN A: root port 00:02.1 (lanes 4-7, x4 port), device c1:00.0 - NOT affected
LAN B: root port 00:03.2 (lanes 8-9, x2 port), device c6:00.0 - the one that disappears
- Both controllers link at PCIe 4.0 ×1 (16 GT/s) when working
- Both ports have Ethernet cables connected
- OS: Linux (Fedora-based), in-kernel r8169 driver. The problem also happens without the OS (test 4).
STEPS TO REPRODUCE
- Unplug AC power, wait a few seconds, plug it back in, power on. Both NICs are present.
- Reboot. A soft power-off followed by the power button, or entering BIOS setup and choosing Save & Exit, does the same.
- LAN B (00:03.2 / c6:00.0) is gone, and root port 00:03.2 is not listed either. LAN A works.
- Nothing except step 1 brings LAN B back.
TESTS AND RESULTS
- Cold boot after removing AC power: both NICs present.
- Linux reboot (no sleep beforehand): LAN B missing.
- Linux power-off, then power button: LAN B missing.
- Cold boot, enter BIOS setup, Save & Exit, so Linux never ran before the reset: LAN B missing. The OS and driver are not involved.
- PCIe secondary bus (hot) reset of each NIC from Linux (sysfs reset_method = bus):
- LAN A (00:02.1): link retrains at 16 GT/s x1, driver rebinds, port works.
- LAN B (00:03.2): link never comes back. The root port stays in link training (LnkSta: Train+, DLActive-). Kernel log:
pcieport 0000:00:03.2: broken device, retraining non-functional downstream link at 2.5GT/s
pcieport 0000:00:03.2: retraining failed
pcieport 0000:00:03.2: Data Link Layer Link Active not set in 100 msec
- Test 5 repeated on LAN B after forcing every GPP reference clock always-on (FCH MISC GPP_CLK_CNTRL at 0xFED80E00, 0×11d3f755 -> 0×11d3ffff), then another link retrain and bus reset: still Train+ / DLActive-. The reference clock and CLKREQ# gating are not the cause.
In lspci -vvv both controllers and both root ports are configured identically: Gen4 ×1, ASPM disabled, L1 substates disabled, Clock PM enabled on the endpoint. The only differences are the root-port width (x4 vs x2), the lanes, and the reference clock (clock 0 / CLKREQ0# for LAN A, clock 5 / CLKREQ5# for LAN B).
So two identical controllers behave differently: LAN A recovers from a link reset, LAN B does not recover from any reset short of losing power. That points at something specific to LAN B’s position on the board, most likely its PERST# (or ISOLATE#/power) not being toggled on warm resets.
FIRMWARE ANALYSIS (GTRPRPI1001C image)
PCIe topology table (AMD CPM table $A26 in AmdCpmOemInitPeim):
- 00:03.2 = lanes 8-9 (x2), CLKREQ5, GpioGroupId (reset ID) 0×13
- 00:02.1 = lanes 4-7 (x4), CLKREQ0, GpioGroupId also 0×13 (duplicate)
In the AMD reference-design settings (AMD PBS menu), 00:03.2 is the reference board’s “PCIe x4 DT slot”.
The only per-port PCIe reset-release code I found (AmdNbioPei, run during PCIe/DXIO init) maps each port’s reset ID to a bit in an embedded-controller register: EC RAM offset 0xA3, through I/O ports 0×662/0×666, read 0×80 / write 0×81. The mapping is 0×16->bit3, 0×1E->bit5, 0×19->bit4, 0×13->bit2, 0×1F->bit1. On this board no EC responds at 0×662/0×666 (an EC read from Linux times out), and the ACPI EC0 device returns _STA = 0. So this reset-release step does nothing. Afterwards the BIOS only drives GPIO26/GPIO27 (PCIE_RST0_L/PCIE_RST1_L) high.
The CPM “GPIO device power” ($A13) and “GPIO device reset” ($A15) tables are empty, so no GPIO is pulsed as a PERST# for any PCIe device.
ACPI: the reference-design SSDTs for this port (OEM table ID “GP10”, D3cold variant) and for 00:02.1 (“LOM”) reference _SB.PCI0.LPC0.EC0.GPO3 / GPO5 / GPOF. The DSDT’s EC is _SB.PCI0.SBRG.EC0, and its _STA returns 0, so those power/reset methods cannot work. With “PCIe x4 Slot D3 Cold” disabled (the default), the minimal GP10 SSDT is loaded, so this is not the cause. It does show that the reset path was carried over from the AMD reference board without being adapted.
Net effect: apart from PCIE_RST0_L/PCIE_RST1_L, nothing in this BIOS resets or power-cycles LAN B on a warm boot. If LAN B’s PERST# is wired to anything other than those pins, or to something that does not toggle on platform reset, it never receives a fundamental reset after the first power-up. That fits all of the results above.
OTHER FIRMWARE ISSUES NOTICED (not the cause of this problem)
- “Save Restore DXIO” logic (AmdCpmOemInitPeim / AmdCpmOemInitDxe, NVRAM variable AMD_SAVE_PCIE_CONFIG): the PEI side computes its checksum over a descriptor count left over from an unrelated loop (0 or 10), while the DXE side uses the real count (6). The saved configuration can never match. It’s harmless today, but broken.
- Both NIC ports share reset ID 0×13 in the PCIe topology table (item 1 above).
REQUEST
- Please check the schematic: what drives PERST# (and ISOLATE#, if used) on the LAN B RTL8127 (PCIe lanes 8-9, root port 00:03.2)? Does that signal assert on every warm reset and on S5 -> S0?
- If it is a GPIO or another signal the BIOS controls, please have the BIOS pulse it low before PCIe link training on every boot (for example through the CPM GPIO device reset table), or fix it in hardware.
- Please confirm the x2 (lanes 8-9) port configuration matches how the x1 controller is actually wired.
- Please provide a BIOS update, or advise if a hardware revision is needed.
WORKAROUND
Only removing AC power restores LAN B. The BIOS has no ErP / Deep S5 option to cut standby power in soft-off, so a smart plug is the only practical workaround.
Full lspci -vvv output for both NICs and their root ports, and kernel logs, are available on request.
