RELENG_8 -- shutdown -p no longer powers off boxes

Fri Apr 23 15:49:22 UTC 2010

Sorry guys, somehow I've not noticed this thread for a while. It was just
pointed out to
me that I undid a change in the latest driver code, because due to one
user's problems
after I put in WOL support, I had taken out the broadcast option and left in
ONLY MAGIC,
but now as you've seen I inadvertently reintroduced it in the newest code.

I've agreed to go back to MAGIC only in the current code, but am in the
middle of some
new development and havent yet got to it but will shortly.

Jack

On Fri, Apr 23, 2010 at 5:20 AM, Jeremy Chadwick
<freebsd at jdc.parodius.com>wrote:

> 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:
> > > > > >
> > > > > > http://freshbsd.org/2010/04/02/23/04/31
> > > > >
> > > > > 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.
>
> Guido,
>
> 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. 192.168.1.255) 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. 192.168.1.255) *did* induce the machine to power up.  How
> do I know this?  Because the X7SBA system would use ports/net/wol,
> calling wol --host=192.168.1.255 $mac (where $mac = MAC address of
> X7SBL-LN2 machine), to wake the X7SBL-LN2 box up (to perform automated
> backups).  Using --host=255.255.255.255 didn't work, nor did using
> --host=what-the-machines-IP-address-last-was.
>
> --
> | Jeremy Chadwick                                   jdc at parodius.com |
> | Parodius Networking                       http://www.parodius.com/ |
> | UNIX Systems Administrator                  Mountain View, CA, USA |
> | Making life hard for others since 1977.              PGP: 4BD6C0CB |
>
>