Bug 189531

Summary:	[fxp] Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL does not work
Product:	Base System	Reporter:	Jim <jkriordan>
Component:	kern	Assignee:	freebsd-net (Nobody) <net>
Status:	Closed Not Enough Information
Severity:	Affects Only Me	CC:	sbruno
Priority:	Normal	Keywords:	IntelNetworking
Version:	Unspecified
Hardware:	Any
OS:	Any

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

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

2018-05-28 19:46:02 UTC

batch change:

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

DO:

Reset to open status.


Note:
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.