Bug 189531 - [fxp] Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL does not work
Summary: [fxp] Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL d...
Status: Closed Not Enough Information
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
Keywords: IntelNetworking
Depends on:
Reported: 2014-05-09 22:00 UTC by Jim
Modified: 2018-05-29 14:52 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jim 2014-05-09 22:00:02 UTC
Intel 82562EZ ethernet adapter uses the if_fxp driver. This driver allows the adapter to function properly in most capacities, but wake on lan (WOL) via magic packets appears to not not be supported by the driver.

ifconfig was used to enable WOL for the Intel 82562EZ and ifconfig was used to confirm that WOL_MAGIC was successfully enabled.

WOL functions properly with the Intel 82562EZ when other operating systems are used, including Ubuntu. WOL in FreeBSD 9.2 was tested with the same configuration as when it was successful in Ubuntu. The same remote computer and the same command were used to wake the Intel 82562EZ in Ubuntu as when attempting to use WOL in FreeBSD 9.2.

How-To-Repeat: Send magic packet to computer with Intel 82562EZ adapter. The computer does not wake up.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-05-13 05:47:02 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Sean Bruno freebsd_committer 2015-08-03 17:33:46 UTC
(In reply to jkriordan from comment #0)
Please post the revision of FreeBSD you are using for this issue.  Looking at logs, WOL has not been touched since:

r251600 | yongari | 2013-06-10 00:31:49 -0700 (Mon, 10 Jun 2013) | 24 lines

Avoid unnecessary controller reinitialization by checking driver
running state.  fxp(4) requires controller reinitialization for the
following cases.
 o RX lockup condition on i82557
 o promiscuous mode change
 o multicast filter change
 o WOL configuration
 o TSO/VLAN hardware tagging/checksum offloading configuration
 o MAC reprogramming after speed/duplex/flow-control resolution
 o Any events that result in MAC reprogramming(link UP/DOWN,
   remote link partner's restart of auto-negotiation etc)
 o Microcode loading/unloading
Apart from above cases which come from hardware limitation, upper
stack also blindly reinitializes controller whenever an IP address
is assigned. After r194573, fxp(4) no longer needs to reinitialize
the controller to program multicast filter after upping the
interface. So keeping track of driver running state should remove
all unnecessary controller reinitializations.

This change will also address endless controller reinitialization
triggered by dhclient(8).

Tested by:      hrs, Alban Hertroys <haramrae@gmail.com>
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:02 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.