Regression: Wake on LAN fails after shutdown on OPNsense 25.x (em driver / ACPI _OSC error)

[Phil8811]

Hi

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Wake on LAN (WoL) regression after upgrading from OPNsense 24.x to 25.x. WoL works after a physical power cycle (S5 from G3), but fails after a clean software shutdown (S5 from S0). The system logs show critical ACPI errors related to the PCI bridge (_OSC method failure) which likely prevents the NIC from being correctly armed for PME (Power Management Event) during the transition to S5.

Last known working version: OPNsense 24.7

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce
Steps to reproduce the behavior:

1. Go to Interfaces -> [LAN/WAN Interface].
2. Enable Wake on LAN.
3. Verify WOL_MAGIC is active using ifconfig in the shell.
4. Go to System -> Power -> Shutdown and perform a clean shutdown.
5. Send a Magic Packet to the device: Device fails to wake.

Expected behavior
The device should wake up upon receiving a Magic Packet after a clean software shutdown, as it did in OPNsense 24.x

Describe alternatives you considered

1. Attempted to disable ACPI strict mode by adding hw.acpi.strict_mode="0" to /boot/loader.conf.local.

2. Verified that the NIC hardware and motherboard still support WoL by testing after a physical power unplug/replug (where it works).

3. Checked if the em driver correctly reports the WoL flag (it does).

4. Considered forcing PCI Power Management Event (PME) via system tunables, but I am awaiting developer guidance on the specific sysctl/tunable compatible with the FreeBSD 14.3 em driver stack to ensure the NIC stays powered in S5.

Relevant log files

ifconfig em0 (WOL is armed):
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>

dmesg ACPI Errors:
[1] pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
[1] Firmware Error (ACPI): \134_SB.PCI0._OSC: Excess arguments - ASL declared 5, ACPI requires 4 (20221020/nsarguments-311)
[1] Firmware Error (ACPI): Failure creating named object [\134_SB.PCI0._OSC.CAPD], AE_ALREADY_EXISTS (20221020/dsfield-352)
[1] ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20221020/dswload2-639)
[1] ACPI Error: Aborting method \134_SB.PCI0._OSC due to previous error (AE_ALREADY_EXISTS) (20221020/psparse-689)
[1] pcib0: _OSC failed: AE_ALREADY_EXISTS

Additional context
The system is an older HP Desktop platform. The issue is likely a regression in the FreeBSD 14.3 ACPI implementation or the em driver's interaction with it during the S0 to S5 transition.

Since WoL works perfectly after a physical power cycle (G3 to S5), the hardware is correctly configured in the BIOS. The failure only occurs when the OS (OPNsense) handles the shutdown, suggesting that the ACPI _OSC failure on pcib0 prevents the kernel from maintaining the power to the NIC's PME (Power Management Event) logic. This was not an issue in OPNsense 24.x (FreeBSD 13.x).

Environment
OPNsense 25.x (FreeBSD 14.3-RELEASE-p5) CPU: Pentium(R) Dual-Core E5300 @ 2.60GHz NIC: Intel(R) 82567LM-3 ICH10 (em0)

Hardware: HP Desktop PC (older platform)

CPU: Pentium(R) Dual-Core E5300 @ 2.60GHz

NIC 1 (Target): Intel(R) 82567LM-3 ICH10 (em driver)

NIC 2: Realtek PCIe GbE Family Controller (re driver)

Software version used and hardware type if relevant, e.g.:

Best Regards

[Phil8811]

Additional technical evidence and cross-site reproduction

Hi, I would like to provide more technical data and physical observations to help narrow down this regression.

1. Precise Hardware Identification: Here is the pciconf output for the affected NIC (Intel 82567LM-3):

em0@pci0:0:25:0: class=0x020000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x10de subvendor=0x103c subdevice=0x3034 vendor = 'Intel Corporation' device = '82567LM-3 Gigabit Network Connection' class = network subclass = ethernet

2. Systematic Regression (Two separate locations): I have confirmed this exact behavior on two identical OPNsense units (same HP hardware) located in two different geographical locations (different ISP, different switches, and different local networks). Both units worked perfectly for WoL on version 24.x and both failed immediately after the 25.x upgrade.

3. Physical Observation (Power Management): On both units, the NIC LEDs turn completely OFF immediately after a clean software shutdown via the GUI/Console.

   This confirms that the kernel/driver is not just failing to "filter" the packet, but is explicitly cutting power to the NIC, preventing it from remaining in a D3 / "listen" state for WoL.

   As a reminder, if I physically pull and replug the power cord, the LEDs stay on (standby power) and WoL works, confirming the hardware/BIOS is capable.

This seems to be a clear regression in how the em driver or the ACPI shutdown routine handles the S5 transition for this specific Intel chipset in FreeBSD 14.3.

Best Regards

[fichtner]

Hi @Phil8811,

If you say 25.x then 25.1 would be FreeBSD 14.2. To narrow this down further 24.7.12 still works on FreeBSD 14.1?

Cheers,
Franco

[Phil8811]

Hi @fichtner
I tried to downgrade to 24.7.12 using opnsense-update -r 24.7.12, but it returns 'Nothing to do'. Since I'm on a production remote unit, forcing a full downgrade via pkg seems risky. However, I am certain it worked on the 24.x branch. Is there a specific sysctl or dev.em.X parameter I can check on 25.1 to see how the NIC is being handled during shutdown?

Best regards