From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 22:38:11 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 CB8F016A400 for ; Tue, 10 Apr 2007 22:38:11 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF8213C44B for ; Tue, 10 Apr 2007 22:38:11 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1418467pyh for ; Tue, 10 Apr 2007 15:38:10 -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=PcZRzh2CtrjGP0f8Kzjl/OvGQJKBlDhk5+oQuDy0oq0BdxoUDk8rAAbC6awgw4JbWtLHDTxxH8/hrB8wX9KuXsPxhSu4dKdyTLkuzykJ2RNaS94BGHqbBFRBXQHg3XXc2Moo8WMjZfXH9XXunV+SItfCPgFR9j25eQPl7FZMhc0= 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=euPiM7Hahq3iby/WGS9XAUMvatSOtYvTl8FTBROCDSq3r8xIMPalh8lbYdmiEmvEQ+Qfm9jEBGyIJBW156OyyUj7xJD2VvEkRuzIOQ70E/uHtjywtKzILbl3wf39STVqEq+X7dZwsGYVZWsFJib8LpZI5+LNcQsAIcjQe2DqKS8= Received: by 10.114.148.1 with SMTP id v1mr2992599wad.1176244690331; Tue, 10 Apr 2007 15:38:10 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Tue, 10 Apr 2007 15:38:10 -0700 (PDT) Message-ID: <2a41acea0704101538l6ae90e8ckf30b10fca4b571eb@mail.gmail.com> Date: Tue, 10 Apr 2007 15:38:10 -0700 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <461C0C3A.7010304@samsco.org> 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> 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 22:38:11 -0000 On 4/10/07, Scott Long wrote: > Julian Elischer wrote: > > Jack Vogel wrote: > >> I am hoping someone here who has more familiarity with the ACPI > >> code can enlighten me.... > >> > >> I have an internal bug filed complaining that FreeBSD disables > >> wake-on-lan on the hardware. This means that if you boot, say, > >> Linux, even Knoppix as a quickie, and then shutdown, if the > >> hardware supports it, it will be left in a state where a magic-packet > >> wakeup will work. However, even if I boot up a FreeBSD kernel > >> with NO em driver, and then shutdown, it undoes the WOL setup. > >> > >> Now, I would like to have explicit WOL support added into the > >> em driver, but before I even worry about that I need to understand > >> where the kernel turns this off without the driver even needed. > >> > >> I've looked around at the dev/acpi and arch/acpi code and at > >> least so far I'm having a hard time getting an adequate picture > >> to know how it happens. > >> > >> Jack > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > > 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 :) Jack