Date: Tue, 9 Nov 2010 11:07:13 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Yamagi Burmeister <lists@yamagi.org> Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) Message-ID: <20101109190713.GA7766@michelle.cdnetworks.com> In-Reply-To: <alpine.BSF.2.00.1011090932550.2751@saya.home.yamagi.org> References: <alpine.BSF.2.00.1011051057350.9984@saya.home.yamagi.org> <20101109011410.GB1275@michelle.cdnetworks.com> <alpine.BSF.2.00.1011090932550.2751@saya.home.yamagi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101109190713.GA7766>