[Bug 166724] if_re(4): watchdog timeout
[email protected] Mon, 13 Jul 2026 14:23:30 +0000
| Newsgroups | gmane.os.freebsd.devel.net |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D166724 --- Comment #138 from J=C3=A9r=C3=A9mie Jourdin <[email protected]>= --- (In reply to Adrian Chadd from comment #137) Yes, making ASPM configurable is cheap and worth it for mobile systems. I'll add a loader tunable following the existing hw.re.* pattern: hw.re.aspm_disable (default 1) 1 (default): current behaviour =E2=80=94 ASPM L0s/L1 + CLKREQ cleared at = attach and re-asserted on watchdog timeout. 0: the driver leaves the firmware-configured ASPM state alone, both at attach and in the watchdog recovery path. I kept "disable" as the default because this PR's history (and the vendor driver's behaviour) point at ASPM as a stall trigger on many 8168 revisions. A laptop that prefers the power savings can set it to 0 and accept the occasional timeout =E2=80=94 and with the new watchdog diagnostics it will = at least be visible which failure class such a system is hitting. I'll split the series into a stacked set of differential revisions so the pieces can be tested and landed independently: D1 if_rlreg.h MCU/FIFO-status definitions + re_stop() quiesce and reset-before-free (the use-after-free / cross-NIC corruption fix) D2 re_txeof() TxPoll doorbell re-kick D3 re_intr_msi() lost Tx-completion MSI re-check + posted-write flush D4 re_watchdog() hardening + single-line diagnostics D5 hw.re.aspm_disable tunable (D4 depends on it for the re-assert gate) I'll add you as reviewer once they're up. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=