Date: Fri, 23 Apr 2010 05:20:00 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Guido Falsi <mad@madpilot.net> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, jfvogel@gmail.com Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes Message-ID: <20100423122000.GA41857@icarus.home.lan> In-Reply-To: <20100423113319.GA4925@megatron.madpilot.net> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> <20100423113319.GA4925@megatron.madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100423122000.GA41857>