Fwd: [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