From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 12:20:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84058106566B for ; Fri, 23 Apr 2010 12:20:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFF68FC17 for ; Fri, 23 Apr 2010 12:20:02 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id 8ySU1e0010cZkys570L3Aa; Fri, 23 Apr 2010 12:20:03 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.westchester.pa.mail.comcast.net with comcast id 90L11e0083S48mS3W0L10q; Fri, 23 Apr 2010 12:20:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 288F49B425; Fri, 23 Apr 2010 05:20:00 -0700 (PDT) Date: Fri, 23 Apr 2010 05:20:00 -0700 From: Jeremy Chadwick To: Guido Falsi Message-ID: <20100423122000.GA41857@icarus.home.lan> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423113319.GA4925@megatron.madpilot.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-stable@freebsd.org, Andriy Gapon , jfvogel@gmail.com Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 12:20:03 -0000 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 |