[Bug 296675] em0 WOL not working in 15.1 (82579LM)
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 11 Oct 2026 00:56:21 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296675
--- Comment #7 from commit-hook@FreeBSD.org ---
A commit in branch stable/15 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0cab2bc676d7f978ebda6cfff324990c70cdb64f
commit 0cab2bc676d7f978ebda6cfff324990c70cdb64f
Author: Kevin Bowling <kbowling@FreeBSD.org>
AuthorDate: 2026-08-30 06:06:02 +0000
Commit: Kevin Bowling <kbowling@FreeBSD.org>
CommitDate: 2026-10-11 00:55:44 +0000
e1000: Rework Wake-on-LAN policy and programming
The driver used the NVM APME default as both the hardware-support
decision and the mutable filter mask. Consequently, an NVM-disabled
but capable port did not advertise wake support, disabling a wake mode
once could keep it disabled across later suspends, and directed-unicast
wake could never be selected.
Require the PCI power management capability to report D3hot PME support
before advertising or arming wake. A PM capability alone does not mean
the function can signal PME from the state used during system sleep.
Separate the board and port capability matrix from the NVM-selected
magic packet default. Read the proper per function NVM word on igb
controllers, cover the newer PCH generations, and retain the documented
legacy, multi-port, and OEM restrictions. Decode the distinct APM
Enable locations used by 82544, 82541EI/82547EI, and the later 8254x
parts. Do not advertise wake on the 82541ER, whose power-management
logic cannot assert PME for wake events. For I210/I211 internal iNVM,
use the hardware-loaded WUC.APME state; the shared reader does not
expose the optional Initialization Control 3 word.
Build WUFC from the enabled ifnet capabilities for each suspend.
Reconstruct RAR0, the multicast table, and the receive filter after the
stop-time reset so unicast and multicast wake use the current interface
state. Fill the MTA on legacy PCI/PCI-X controllers and 82575 through
82580 when the address list overflows; their multicast wake matchers
require the indexed MTA bit and do not use RCTL.MPE as a substitute.
Do not access PF-only wake CSRs from the igb VF suspend and resume
paths.
Use the shared BM page access helpers and propagate every PHY receive
address and wake-register programming failure. On resume, perform the
required LCD reset before clearing host PHY-wake ownership, report the
saved PHY or MAC wake cause, and clear PCI PME after removing the device
wake source. Preserve management engine wake ownership throughout.
Keep WUC.APME set only when early 82545EM/82546EB manageability needs
its D3 clock-tree workaround; ordinary host wake uses PCI PME.
Keep the link powered while host wake is armed. With no host wake,
evaluate management pass-through at each suspend. Leave a
management-owned link untouched and keep PCI PME enabled. Otherwise,
use the Intel shared code PHY power-down hook, or its matching SerDes
shutdown hook on igb fiber and SerDes devices. Track that state and
restore the link without another PHY reset before hardware
initialization. Ordinary ifconfig down behavior is unchanged.
Apply and undo the PCH Sx workarounds across their full supported range.
Use controller-specific CTRL and laser semantics, and restore RCTL when
wake setup fails. Always run the pending PCIe-transaction drain and
bus-master-disable sequence before D3. Suspend reports a
wake programming failure rather than sleeping without wake, shutdown
logs it and continues through the fencing sequence.
Do not apply the ICH/PCH IGP3 D3 power-down workaround to igb
controllers. The merged driver inherited an unconditional call from the
em-only driver. On 82575 and 82576 it asserted CTRL.PHY_RST after the
wake filters were armed, preventing the link from receiving wake
traffic.
The implementation was checked against the Intel controller data
sheets, the Intel Linux e1000, e1000e, and igb lifecycle code, DPDK,
and the Intel FreeBSD em-7.7.8 and igb-2.5.31 drivers. The 8254x audit
also covered the PCI/PCI-X Software Developer's Manual, the 82541/82547
NVM guide, and the 82544, 82545, and 82546 specification updates. The
out of tree drivers carry the family-specific power down and reset block
hooks but do not call them from suspend. DPDK supplies the stop/start
pairing.
On PCH controllers including an 82579LM, I217-LM, and various I219s,
device-only D3 tests observed PME and BM_WUS.MAG for a magic packet, no
PME with every host filter disabled, and BM_WUS.EX with only
directed-unicast wake enabled. With dev.em.0.wake enabled, ACPI S3
slept until a delayed magic packet and resumed with the interface
operational. After wake traffic stopped and resume completed, a second
cycle again waited for a newly delayed magic packet. Traffic restored
after both host and firmware wake were enabled.
An 82574L woke from S3 after one magic packet, reported MAC wakeup
status, and returned with link and traffic operational.
On 82571EB and 82573L adapters, device-only D3 tests observed WUS.MAG
and PCI PME status after a magic packet, then returned to D0 with link
and traffic operational. Full S3 did not wake either add-in card.
The positive device tests and negative S3 isolate the remaining failure
outside the MAC filter programming and my cards may lack aux power
wiring because the link was off in S3.
On 82575EB and 82576 adapters, pre-fix device only D3 tests left PMCSR
at 0x2103 despite ten verified magic packets, and the handoff showed
CTRL.PHY_RST asserted. With the em-family gate, identical tests changed
PMCSR from 0x2103 to 0xa103, resume reported WUS.MAG, and both links
returned operational. S3 testing on these separated controller from
board behavior. An Intel 82576 card retained link in S3 and woke the
system from a delayed magic packet, reported WUS.MAG, and returned with
interface operational. The tested 82575 add-in card lost its
link LED in S3 and retained no WUS cause after manual resume, although
its identical D3hot test passed. That points the 82575 S3 result to
card aux power wiring as well.
D3 tests were performed on I210 and I350 but S3 has not yet been
attempted on them.
lem(4) testing has not been attempted yet.
Community reports of success and failure are welcome.
PR: 232708, 238411, 295443, 296675
Sponsored by: BBOX.io
(cherry picked from commit 46cf612d98e99967204185829fe829350cfa51a1)
share/man/man4/em.4 | 24 +-
sys/dev/e1000/e1000_ich8lan.c | 41 ++-
sys/dev/e1000/e1000_ich8lan.h | 2 +-
sys/dev/e1000/e1000_regs.h | 2 +-
sys/dev/e1000/if_em.c | 599 +++++++++++++++++++++++++++++++++---------
sys/dev/e1000/if_em.h | 13 +-
6 files changed, 534 insertions(+), 147 deletions(-)
--
You are receiving this mail because:
You are the assignee for the bug.