RELENG_8 -- shutdown -p no longer powers off boxes

Jeremy Chadwick freebsd at
Fri Apr 23 12:20:03 UTC 2010

On Fri, Apr 23, 2010 at 01:33:19PM +0200, Guido Falsi wrote:
> On Fri, Apr 23, 2010 at 01:54:01AM -0700, Jeremy Chadwick wrote:
> > On Fri, Apr 23, 2010 at 11:46:06AM +0300, Kostik Belousov wrote:
> > > On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote:
> > > > on 22/04/2010 17:35 Jeremy Chadwick said the following:
> > > > > I went digging through HEAD commits between the above dates and wasn't
> > > > > able to find much other than this, which appears to be the HEAD commit
> > > > > that was MFC'd to RELENG_8:
> > > > > 
> > > > >
> > > > 
> > > > I don't think this has been MFC-ed to 8.
> > > > Most likely a red herring.
> > > > 
> > > > AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so
> > > > the issue must be elsewhere.
> > > 
> > > I have the 5046A-XB SuperWorkstation, and I can confirm that it restarts
> > > shortly after power halt. On the other hand, I thought that this is a
> > > hardware bug.
> > 
> > In my case, it's not a hardware nor BIOS (ACPI) bug.  Both of my systems
> > have worked just fine with "shutdown -p now" until recent commits to
> > RELENG_8.  Something broke this functionality between March 30th and
> > April 22nd.
> > 
> > I'll try to spend some time this weekend tracking it down...
> Since I find this quite annoying I tried some experiments.
> First I tried an "ifconfig em0 -wol" and after that the PC was able to
> power down and stay powered down (left it there for 2 minutes...It
> powers back up in no more than a second otherwise).
> Disabling WOL from the BIOS on this machine seems not to change
> anything. the functionality is enabled anyway by the driver.
> As a temporary workaround I commented out this piece of code in if_em.c
> (lines 2710-2714):
> 	/* Enable All WOL methods by default */
> /*	if (adapter->wol) {
> 		ifp->if_capabilities |= IFCAP_WOL;
> 		ifp->if_capenable |= IFCAP_WOL;
> 	} */
> I had a look at if_em.c and diffs from previous versions and noticed
> that the last update adds this snippet of code to unconditionally
> enable WOL on em cards. Is this correct policy? I checked with
> another machine with an older world and WOL used to be off by
> default.
> Anyway there is also a problem because even with WOL on the machine
> should not turn on on ANY packet. I tried to make something out,
> but I have no idea where to look at. I suspect something is incorrect
> in the programming of the PHY to enable WOL.
> It definitely is an em WOL problem though.

CC'ing Jack Vogel on this one too.


Thanks for the investigative efforts.  I can validate your statements:
doing "ifconfig emX -wol" does in fact address the problem.

The ifconfig(8) man page had this to say:

	There are three types of packets that may wake a system:
	ucast (directed solely to the machine's mac address), mcast
	(directed to a broadcast or multicast address), or magic
	(unicast or multicast frames with a ``magic contents'').

I read the ucast definition to mean **any** packet directed to the
machine's MAC, which would almost guarantee the machine be woken up;
think ARP packets.  The same goes for mcast -- **any** packet directed
to the broadcast of the network (e.g. or a multicast
address (e.g. addresses within RFC3171 range) would wake the machine up.

How is this behaviour at all desirable?

I can see the above features working *in addition* to the WOL_MAGIC
(magic packet) requirement, but that's not what the man page implies,
nor is it what's being seen in driver 7.0.5.  It's as if nearly any kind
of packet arriving on the NIC powers the machine up.

I'll spend some time later today messing around with combinations of
ifconfig em0 -wol_ucast and -wol_mcast to see if I can narrow down the
condition.  I'll report back with those findings.

I've already noticed that "ifconfig em0 -wol_mcast -wol_ucast" results
in the WOL_MCAST being removed but WOL_UCAST + WOL_MAGIC being left
enabled.  I have a feeling this is by design (e.g. you can't just have
WOL_MAGIC set and that's it), but I'm not sure.

One thing I do want to note:

Prior to driver 7.0.5, ifconfig did not show any WOL capabilities.
However, magic packets directed to the broadcast address on the local
network (e.g. *did* induce the machine to power up.  How
do I know this?  Because the X7SBA system would use ports/net/wol,
calling wol --host= $mac (where $mac = MAC address of
X7SBL-LN2 machine), to wake the X7SBL-LN2 box up (to perform automated
backups).  Using --host= didn't work, nor did using

| Jeremy Chadwick                                   jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-stable mailing list