From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 19:08:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F48106566B for ; Tue, 9 Nov 2010 19:08:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33DEC8FC1C for ; Tue, 9 Nov 2010 19:08:11 +0000 (UTC) Received: by pvc22 with SMTP id 22so1939705pvc.13 for ; Tue, 09 Nov 2010 11:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=UMjSKKWom7fBhww8Vk4/4KmJIBx4anbBx8gi6IpUNLs=; b=byXxyLteBPKpb4Xh0t4TxfPzQ1Jnbpe2zXHHoAfm1FcTassZ6nDLHrIB9l9t9RgfMQ eBQzG9BwyNavRbpx+JRwK1vvpqd9Tf/wnmQOG5G1sb9M6QT2VYRtawz3F2PzjF/LfjC0 hJ4Ks4nfDRhg6ILkWDFvM9iYe2rZKaKXXRlEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=na7uWw81N2BAc07SAMvxq/siHIzLUc78I9XedP2WgaFfkPjevkYBKGOY85pgTPsM15 NQejTNogNk7OVlplsoBJbFLcyfxDqvGOuSDqJuW3UjpgZnJt0NsTDefPBpuvDlub+2e2 1DuSZ/e8IqpNqYnHOG+smM/tM9vUtWoHV2v1I= Received: by 10.142.186.20 with SMTP id j20mr6152757wff.387.1289329690535; Tue, 09 Nov 2010 11:08:10 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y42sm2036364wfd.10.2010.11.09.11.08.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 11:08:08 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 9 Nov 2010 11:07:13 -0800 From: Pyun YongHyeon Date: Tue, 9 Nov 2010 11:07:13 -0800 To: Yamagi Burmeister Message-ID: <20101109190713.GA7766@michelle.cdnetworks.com> References: <20101109011410.GB1275@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 19:08:11 -0000 On Tue, Nov 09, 2010 at 09:49:14AM +0100, Yamagi Burmeister wrote: > > Thanks for your reply. > > On Mon, 8 Nov 2010, Pyun YongHyeon wrote: > > >Thanks for the patch. I attached slightly modified the code to > >better match other WOL capable drivers in tree. Because data sheet > >is not available I blindly made a patch based on your code. I have > >a couple of questions which I can't verify it on real hardware(I > >have no more access to the hardware). > > > >o If you established a gigabit link with link partner and shutdown > > your box, does the established link automatically change to 10 or > > 100Mbps? You can check it on your link partner. If your link > > partner still reports it established 1000Mbps link, we have to > > do other necessary work in driver(i.e. manually switching to > > 10/100Mbps). > > No, the link stays at 1000Mbps so the driver must manually switch back > to 10/100Mbps. > Hmm, this is real problem for WOL. Establishing 1000Mbps link to accept WOL frames is really bad idea since it can draw more power than 375mA. Consuming more power than 375mA is violation of PCI specification and some system may completely shutdown the power to protect hardware against over-current damage which in turn means WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for all nfe(4) controllers, it would dissipate much more power. Because nfe(4) controllers are notorious for using various PHYs, it's hard to write a code to reliably establish 10/100Mbps link in driver. In addition, nfe(4) is known to be buggy in link state handling such that forced media selection didn't work well. I'll see what could be done in this week if I find spare time. > >o When you put your box into suspend mode, can you wake up your box > > with WOL magic packet? > > I'm sorry but I can't test that since none of those boxes supports > suspend: > > % sysctl hw.acpi.suspend_state > hw.acpi.suspend_state: NONE > You can switch to suspend mode with "acpiconf -s1". If all goes well, driver would put the controller into suspend mode after reprogramming controller to accept WOL frames. After that, you can wakeup the box by sending a WOL magic packet. > >o When your system boots up with/without WOL magic packet, sending > > WOL magic packets from other hosts can hang your box? > > No they don't. No matter if the box was started by sending the WOL magic > packet or by hand it survives all WOL packets I send to it. > Ok, some controllers are known to hang the box if it receive WOL frames before initializing controller. > >o If you disabled WOL with ifconfig before system shutdown, can you > > still wakeup your box with WOL magic packet? > > No, I can't. WOL is disabled and the box must be started manually. > > >o If you reprogram your station address with ifconfig(i.e. ifconfig > > nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with > > WOL magic packet? > > Yes, with sending the WOL magic packet to the new station adress. > Sending it to the original adress doesn't work. > > >The patch I made didn't take into account management firmware so > >if you use the patch with IMPI, IMPI wouldn't work. But I think > >that's not an issue since all other parts of nfe(4) also ignores > >management firmware at this moment. > > I can't test that, because none of these machines has the IPMI option > installed. Sorry. > Ok, all other features except wakeup from suspend seem to work. Thanks for testing!