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 <redacted>
To:     Heiner Kallweit <hkallweit1@gmail.com>



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
<hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>:

   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