From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 2 06:34:06 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A983B1065673 for ; Sat, 2 Oct 2010 06:34:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0E64B8FC1D for ; Sat, 2 Oct 2010 06:34:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o926Y3Qt059026; Sat, 2 Oct 2010 16:34:03 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 2 Oct 2010 16:34:03 +1000 (EST) From: Ian Smith To: Paul B Mahol In-Reply-To: Message-ID: <20101002142419.G62022@sola.nimnet.asn.au> References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> <20101001144505.C62022@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Matt , freebsd-acpi@freebsd.org Subject: Re: Sleep/Lenovo SL410 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 06:34:06 -0000 On Fri, 1 Oct 2010, Paul B Mahol wrote: > On 10/1/10, Ian Smith wrote: > > On Thu, 30 Sep 2010, Matt wrote: > > > Success! > > > > > > After setting every possible suspend/resume sysctl, > > > "sysctl hw.pci.do_power_resume=0" > > > allowed suspend and resume. Still beeps 1-3 times before suspend, with > > rapid > > > sleep light flashing until suspend complete. > > > > Interesting; $someone may document do_power_resume a bit more $someday? > It is already documented. Well, there's all of: t23% sysctl -ad | grep do_power_resume hw.pci.do_power_resume: Transition from D3 -> D0 on resume. unless you mean RTFS :) where there's: t23% sh -c 'find /usr -type f -exec grep -Hi do_power_resume {} \; 2>/dev/null' /usr/src/sys/dev/pci/pci.c:static int pci_do_power_resume = 1; /usr/src/sys/dev/pci/pci.c:TUNABLE_INT("hw.pci.do_power_resume", &pci_do_power_resume); /usr/src/sys/dev/pci/pci.c:SYSCTL_INT(_hw_pci, OID_AUTO, do_power_resume, CTLFLAG_RW, /usr/src/sys/dev/pci/pci.c: &pci_do_power_resume, 1, /usr/src/sys/dev/pci/pci.c: if (pci_do_power_resume) /usr/src/sys/dev/pci/pci.c: if (pci_do_power_resume) Binary file /usr/obj/usr/src/sys/GENERIC/pci.o matches Binary file /usr/obj/usr/src/sys/GENERIC/kernel matches Binary file /usr/obj/usr/src/sys/GENERIC/kernel.debug matches Binary file /usr/obj/usr/src/sys/GENERIC/kernel.symbols matches .. including manpages, handbook, faq, articles etc. Is that it? I know what D3->D0 means but it hardly describes when/how/why to {,not} use it, leaving me surprised it would make S3 resume work in this case, and why? 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Sep 5 15:53:00 EST 2010 GENERIC i386 > > > Kernel conf is attached. > > > World built from last Friday's CVS, -CURRENT > > > > > > acpiconf -s3 works perfectly from console > > > previously opened windows are garbled until refresh in X > > > > Some thinkpads have responded positively in this regard to setting > > hw.syscons.sc_no_suspend_vtswitch=1 > > > > > acpiconf -s4 causes shutdown, does not resume on power on. > > > > Suspend To Disk is not expected to work; your laptop (like most) has no > > BIOS support for S4, as per your hw.acpi.s4bios: 0 > > Suspend to disk does not work because FreeBSD does not support it. > (s4bios is irrelevant here) Ah, when did that break? It worked fine on my old Compaq 1500c ('99!) on FreeBSD 5.5, s4bios=1, though for another reason I couldn't usually run ACPI on it, and APM STD and STR work. I found a message from someone with a Dell Inspiron something a few years ago reporting S4BIOS working, modulo a fixable screen resume issue that he had resuming from S3 also. Of course you needed a DOS slice, probably as s1, with a pre-allocated hibernation file that the BIOS can find to use, but it had that anyway. It could be argued that acpiconf ought to just ignore S4 requests unless hw.acpi.s4bios=1, where it has some chance of working .. cheers, Ian (current@ dropped from ccs as I'm not subscribed. Feel free to re-add)