RE: [REGRESSION] r8169: System freeze on kernel 7.0 with RTL8111H (rev 16 / RTL8168H_1) during ASPM / L1 transition

>-------- Forwarded Message --------
>Subject:        Re: [REGRESSION] r8169: System freeze on kernel 7.0 with
>RTL8111H (rev 16 / RTL8168H_1) during ASPM / L1 transition
>Date:   Thu, 6 Aug 2026 21:45:28 +0200
>From:   Thomas Wilms <[email protected]>
>To:     Heiner Kallweit <[email protected]>
>
>
>
>Hallo Heiner,
>
>ich möchte ein Problem mit dem |r8169|-Treiber melden, das nach dem
>Commit |9ab94a32af704fa9c873094283ae8744a07baf25| (/r8169: enable LTR
>support/) aufgetreten ist.
>
>*System-Konfiguration:*
>
>  *
>
>    *NIC:* Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI
>Express Gigabit Ethernet Controller (rev 16)
>
>  *
>
>    *Subsystem:* Gigabyte Technology Co., Ltd Onboard Ethernet Mainboard
>B560M DS3H V2 Bios F12d
>
>*Fehlerbeschreibung:* Seit dem besagten Commit fällt die Netzwerkkarte im
>laufenden Betrieb oder kurz nach dem Booten komplett aus. Der Browser
>liefert Verbindungsfehler („Server nicht gefunden“) und das Interface reagiert
>nicht mehr.
>
>Eine Analyse via |lspci -vv| wies im Fehlerfall ein komplettes Absterben des
>PCI-Headers auf (|!!! Unknown header type 7f|), was darauf hindeutet, dass
>der NIC-Chip durch den tiefen Schlafzustand abgestürzt ist und nicht mehr auf
>den PCI-Bus antwortet.
>
>*Ursachenanalyse:* Durch ein |git bisect| konnte der Commit
>|9ab94a32af704fa9c873094283ae8744a07baf25| eindeutig als Auslöser
>identifiziert werden.
>
>Durch das Freischalten von LTR (Latency Tolerance Reporting) auf RTL8168-
>Revisionen kommt es im Zusammenspiel mit ASPM L1/L1.1/L1.2 zu einem
>Fehlverhalten der Hardware.
>
>*Workaround & Bestätigung:* Wenn ich LTR manuell über das PCIe Device
>Control 2 Register (|DevCtl2|) ausschalte (Setzen des Bits von |LTR+| auf |LTR-
>| via |setpci 02:00.0 98.w=0000|), läuft die Netzwerkverbindung wieder
>absolut stabil. ASPM selbst (|LnkCtl: ASPM L1 Enabled|) kann dabei voll aktiv
>bleiben, ohne dass es zu Abbrüchen kommt.
>
>Workaround bei mir:
>
>sudo cat /etc/udev/rules.d/99-realtek-aspm.rules
>ACTION=="add", SUBSYSTEM=="pci", KERNELS=="0000:02:00.0",
>ATTR{power/control}="auto", ATTR{link/l1_aspm}="1",
>ATTR{link/l1_1_aspm}="1", ATTR{link/l1_2_aspm}="1", RUN+="/usr/bin/setpci -
>s 02:00.0 98.w=0000"
>
>Es scheint daher, als müsste für bestimmte RTL8111/8168-Revisionen
>(mindestens rev 16) ein Quirks-Eintrag ergänzt oder LTR treiberseitig wieder
>maskiert werden.
>
>lspci | grep -i ethernet  liefert:
>02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 16)
>
>
>git bisect log
># bad: [3cb1fb7a56d2fd8011f5282bc170c0d23dc1f4b5] Linux 7.0.1 # good:
>[b9dbb4576bc8c69e87b4ca4caa2fb1c0db47d722] Linux 6.19.14 git bisect start
>'v7.0.1' 'v6.19.14' '--' 'drivers/net/ethernet/realtek/' 'drivers/pci/pcie/'
># good: [05f7e89ab9731565d8a62e3b5d1ec206485eeb0b] Linux 6.19 git bisect
>good 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
># good: [1c2b4a4c2bcb950f182eeeb33d94b565607608cf] Merge tag 'pci-v7.0-
>changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
><http://git.kernel.org/pub/scm/linux/kernel/git/pci/pci>
>git bisect good 1c2b4a4c2bcb950f182eeeb33d94b565607608cf
># bad: [37a93dd5c49b5fda807fd204edf2547c3493319c] Merge tag 'net-next-
>7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
><http://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next>
>git bisect bad 37a93dd5c49b5fda807fd204edf2547c3493319c
># bad: [b00a7b3a612925faa7362f5c61065e3e5f393fff] net: atp: drop ancient
>parallel-port Ethernet driver git bisect bad
>b00a7b3a612925faa7362f5c61065e3e5f393fff
># good: [3259d2cf94276d92bb49b782d3e138703208e353] r8169: add DASH
>support for RTL8127AP git bisect good
>3259d2cf94276d92bb49b782d3e138703208e353
># bad: [9ab94a32af704fa9c873094283ae8744a07baf25] r8169: enable LTR
>support git bisect bad 9ab94a32af704fa9c873094283ae8744a07baf25
># first bad commit: [9ab94a32af704fa9c873094283ae8744a07baf25] r8169:
>enable LTR support
>
>
>
>Viele Grüße
>
>Thomas Wilms
>
>p.s.: Ich hoffe es hilft Dir weiter, einen ganzen Tag hab ich mich damit
>abgemüht...
>
>
>
>Am Fr., 31. Juli 2026 um 18:04 Uhr schrieb Heiner Kallweit
><[email protected] <mailto:[email protected]>>:
>
>    On 31.07.2026 11:13, Thomas Wilms wrote:
>    > Hi Heiner,
>    >
>    > I am writing to report a system freeze regression with the r8169 driver on a
>Realtek RTL8111H (rev 16) ethernet chip.
>    >
>    > Hardware & Environment:
>    > - NIC: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI
>Express Gigabit Ethernet Controller (rev 16)
>    > - Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet
>    > - Mainboard: Gigabyte B560M DSH3 V2
>    > - Chip version: RTL8168H_1 / Revision 16 (XID 54100000)
>    >
>    > Observed Behavior:
>    > - Kernel 6.14: Completely stable. Reaches Package C10 successfully using a
>custom udev rule to enable L1 ASPM:
>    >   ACTION=="add", SUBSYSTEM=="pci", KERNELS=="0000:02:00.0",
>DRIVER=="r8169", ATTR{link/l1_aspm}="1", ATTR{power/control}="auto"
>    > - Kernel 7.0 (Mainline): The network connection freezes / locks up shortly
>after boot or during ASPM/power state transitions with the same setup.
>    >
>    > lspci -vv snippet for the device:
>    > 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 16)
>    >         LnkCap: Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
>unlimited, L1 <64us
>    >         LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
>    >         Capabilities: [178 v1] L1 PM Substates
>    >
>    > It seems that changes between 6.14 and 7.0 regarding L1 PM substates,
>clock gating (CLKREQ#), or L1 exit latency timing introduce a PCI bus lockup on
>this specific revision.
>    >
>    > Please let me know if you need specific dmesg logs, ftrace output, or if
>you'd like me to test a patch or run a git bisect between 6.14 and 7.0.
>    >
>    > Best regards,
>    > Thomas
>    >
>    > p.s.: Hallo nochmal, hab das mit Chatgpt erstellt, sorry. Mit Kernel 7.0 ist
>jedenfals ASPM L1 nicht stabil, mit 6.14 schon. Vielleicht hilft Dir die Info ja
>weiter.
>
>    Root cause can be in several places, incl. PCI core changes. Therefore indeed
>it would be best if you can
>    bisect between last know good and first known bad kernel version. Should
>be kernels w/o downstream changes, ideally mainline kernels.
>
>Hi Javen,
>this is one more report mentioning a problem after "r8169: enable LTR
>support"
>first bad commit: [9ab94a32af704fa9c873094283ae8744a07baf25] r8169:
>enable LTR support

Hi Thomas, Heiner

I am still unable to reproduce this issue on my local platform. Could you please help me test this patch below? 

---
 drivers/net/ethernet/realtek/r8169_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index ec4fc21fa21f..f75e611444fb 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -3609,6 +3609,8 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
 	r8168_mac_ocp_write(tp, 0xe63e, 0x0000);
 	r8168_mac_ocp_write(tp, 0xc094, 0x0000);
 	r8168_mac_ocp_write(tp, 0xc09e, 0x0000);
+
+	r8168_mac_ocp_write(tp, 0xe098, 0x0064);
 }
 
 static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
--

Thanks,
Javen