From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 23:05:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8743316A405 for ; Tue, 10 Apr 2007 23:05:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227]) by mx1.freebsd.org (Postfix) with ESMTP id 322B213C46A for ; Tue, 10 Apr 2007 23:05:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1503560nza for ; Tue, 10 Apr 2007 16:05:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tfY1SRd4TGO++Boq/2I65idtWti1hOzsExAHpNWwm1dINhg7FOfuPzGJwfUP2DpvcGFrXh3CZji2eN1oyX4KBGFdm93m7Iu2XggZvvscwLW/IhZmy/3X9HYCGG36Gt19ojnPGyNngxRDMqvSYSHlwBWfvKEbeIVUQATopwG1BII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sgsVgiGN2vHjvu+jIdJwUfNmyIu6jkMbc7mR4tba0c9sbBLVtWZyclSDHIRx1Qi9SY+rfvl9uoS5Zhgx4MmHJT5NWR7q0Dy/VCuPH/LAZ0wuI7sDpsnD7bcL8fRstP3dRCFewVziXTMM4paFeJAK2K0QQ6dZBRPGaKsz7wbEI34= Received: by 10.115.89.1 with SMTP id r1mr3012532wal.1176246305356; Tue, 10 Apr 2007 16:05:05 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Tue, 10 Apr 2007 16:05:05 -0700 (PDT) Message-ID: <2a41acea0704101605xd56b7a8md755df552679e761@mail.gmail.com> Date: Tue, 10 Apr 2007 16:05:05 -0700 From: "Jack Vogel" To: "David Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90303A029F6@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0704101439l17ba9347o8b9844416dbb25a1@mail.gmail.com> <461C08DF.8010201@elischer.org> <461C0C3A.7010304@samsco.org> <2a41acea0704101538l6ae90e8ckf30b10fca4b571eb@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90303A029F6@NT-IRVA-0750.brcm.ad.broadcom.com> Cc: freebsd-current , Julian Elischer Subject: Re: WOL question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 23:05:06 -0000 On 4/10/07, David Christensen wrote: > > > > I think I heard once that some BIOSes turn it off during > > the boot cycle > > > > somewhere and it is up to the OS to turn it back on. I do > > know that some > > > > BIOSes > > > > phuck with the NIC enough to stop IPMI from working > > during the boot. > > > > > > > > > > That would make sense; you don't want the card to generate > > an NMI during > > > boot from a spurius WOL package before the system is ready > > to handle it. > > > > Hmm, so I have two competing views about things, one is that > > the kernel > > is actively doing something to disable WOL on shutdown, and now the > > theory that its just not rearming the system. > > > > I really need to know which it is, because I'm putting code > > in the driver that > > I think should rearm it, and it doesnt work, and I've been > > left wondering if > > my code is wrong, or if something deeper in the kernel is > > clobbering the > > things I am trying to set up :) > > Is this a NIC or a LOM? For Broadcom NICs there is a procedure > implemented > in firmware for toggling power to the chip from MAIN to VAUX prior to > entering D3cold so that the controller still has power and can recognize > > the magic packet. For LOM designs that's not required because the VAUX > rail is always powered by the motherboard. The easy way to check is to > see if you still have a link LED lit on the back of the controller when > you expect to be in WoL mode. No LED, no power. Are you resetting the > link speed to 100Mbps or less? Running at 1000Mbps generally draws more > than 375mA and I've seen some systems that shutdown power to a slot when > it draws too much power in VAUX. Its a LOM. I think I have come up with a test that settles things. I boot Knoppix and init 0, I know that in this state a magic packet will wake the box up. Next I just boot thru the BIOS to the Knoppix boot prompt, then power the system off. When I do this etherwake will no longer wake it up. I believe this proves Julian's claim is correct. Next, I would just like to be confident that the ACPI layer is not going to clobber something my driver does, but at least I need to take another look at my code, maybe I got it wrong... Thanks for the inputs everyone, Jack