From owner-freebsd-acpi@FreeBSD.ORG Mon May 23 21:35:20 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6403216A41C for ; Mon, 23 May 2005 21:35:20 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E67243D1D for ; Mon, 23 May 2005 21:35:20 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGY009XEPAURSI1@vms040.mailsrvcs.net> for acpi@freebsd.org; Mon, 23 May 2005 16:35:19 -0500 (CDT) Date: Mon, 23 May 2005 17:32:54 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <42921446.2000405@root.org> To: Nate Lawson Message-id: <1116883974.681.4.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <1116811842.671.22.camel@RabbitsDen> <20050523103252.GX21800@poupinou.org> <42921446.2000405@root.org> Cc: acpi@freebsd.org Subject: Re: S3 state handled in BIOS? 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: Mon, 23 May 2005 21:35:20 -0000 On Mon, 2005-05-23 at 10:35 -0700, Nate Lawson wrote: > Bruno Ducrot wrote: > > On Sun, May 22, 2005 at 09:30:42PM -0400, Alexandre Sunny Kovalenko wrote: > > > >>Good people, > >> > >>after much pocking around my laptop (Averatec > >>3150H), /usr/src/sys/i386/acpica/acpi_wakeup.c > >>and /usr/src/sys/contrib/dev/acpica/hwsleep.c, I came to conclusion that > >>S3 state in my case causes BIOS to suspend machine at the point when > >>SLP_TYP and SLP_EN are set and resume it from that same point, > >>completely ignoring wakeup vector. > >> > >>This would cause FreeBSD to hit infinite loop in acpi_sleep_machdep > >>(acpi_wakeup.c) and never come back. Replacing that loop with > >>AcpiOsSleep(5000) lets system resume properly. > >> > >>This kind of sleep (pseudo S3?) about doubles battery life, which is not > >>much to write home about, but matches what Windows does on the same > >>hardware, so, I guess, it is best I am going to get. > >> > >>Question that I have to the list is whether somebody who knows ACPI > >>thinks that it is common enough situation to warrant tunable along the > >>lines of 'hw.acpi.s3bios', which would eliminate infinite loop if set? > >> > >>I have unconditionally eliminated the loop for now and have been testing > >>it here for awhile without any bad side effects. > >> > >>If your system appears to hang after resume from S3 while turning power > >>on, you might want to try attached very simplistic patch. > >> > > > > > > I think your machine actually perform S1, not S3, likely because the > > values associated to _S3 (a package in the asl) are for _S1. > > > In that case, it would be interesting to see the acpidump -t -d and > compare values for the _S1 and _S3 nodes. > It does not seem to have S1 entry in ASL (see below). I will play with it a little bit more and see whether creating S1 node with the set of flags from \_S3 results in some logical behavior. Is it sufficient to duplicate an entry, or do I need to add it elsewhere? Name (\_S0, Package (0x04) { 0x00, 0x00, 0x00, 0x00 }) Name (\_S3, Package (0x04) { 0x04, 0x00, 0x00, 0x00 }) Name (\_S4, Package (0x04) { 0x02, 0x00, 0x00, 0x00 }) Name (\_S5, Package (0x04) { 0x02, 0x00, 0x00, 0x00 }) Thank you for your help, -- Alexandre "Sunny" Kovalenko (Олександр Коваленко)