[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.=