From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 28 11:28:38 2011 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 5EF631065670 for ; Tue, 28 Jun 2011 11:28:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A9A118FC08 for ; Tue, 28 Jun 2011 11:28:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA06852; Tue, 28 Jun 2011 14:28:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QbWT4-0005PF-Il; Tue, 28 Jun 2011 14:28:34 +0300 Message-ID: <4E09BADF.7050702@FreeBSD.org> Date: Tue, 28 Jun 2011 14:28:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Tue, 28 Jun 2011 11:28:38 -0000 on 27/06/2011 21:04 Vitaly Magerya said the following: >> It seems that possibly we present different OS capabilities to ACPI... >> Needs more investigation. >> >> Can you also send me two binary files produced as follows: >> 1. dd if=/dev/mem size=1 iseek=0x3F5B9B71 count=0x00000203 of=... >> 2. dd if=/dev/mem size=1 iseek=0x3F5B92DA count=0x00000708 of=... >> >> Or, if it's not too much trouble for you, you can send results of >> decompilation of those files using iasl -d > > You can find them all at [1] and [2]. > > [1] http://tx97.net/~magv/n143-acpi/mem-3f5b9b71.dsl.txt > [2] http://tx97.net/~magv/n143-acpi/mem-3f5b92da.dsl.txt OK, thank you, very interesting. I think that part (but not all) of the differences between FreeBSD and Linux can be explained by the fact that FreeBSD currently doesn't advertise itself as featuring ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE. I am not sure what it would take to actually support these features. I think that Linux does support (or at least advertise support) for these features. I see one repeated condition for providing advanced C states, it's: (\_SB.C1ON) and (LAnd (LOr (LNot (PWRS), \_SB.C4AC), \_SB.C3SU))). I think that PWRS is supposed to reflect current AC state (1 - connected, 0 - disconnected). All of C1ON, C4AC and C3SU are declared in a special memory region: OperationRegion (SNVS, SystemMemory, 0x3F5C0C7D, 0x000000FF) My guess is that SNVS stands for "System Non-Volatile Storage" or some such, which may serve similarly to CMOS NVRAM for BIOS settings. Further, I guess that C4AC is a configuration setting for whether to provide C4 state while on AC, and C3SU - is whether C3 state should be supported. C1ON - not really sure. I would be interested to see memory dumps of the above region both early after boot and later when you get additional C states. This can be done with: dd if=/dev/mem size=1 iseek=0x3F5C0C7D count=0x000000FF I am not sure if the values in SNVS can change during OS run-time, so I would like to check that. At least they are not modified via ACPI code as far as I can see. Then, PWRS is declared in GNVS region ("Global Non-Volatile Storage"?): OperationRegion (GNVS, SystemMemory, 0x3F5C0D7C, 0x0100) I would like to get two dumps for this region too. I see that PWRS value is being manipulated in a few of EC (embedded controller device) methods. So maybe we do not call something related as early as Linux does. And, I also see that there is an interesting variable MPEN which controls whether to send Processor notifications when PNOT ("processor notify"?) method is called; these notifications are what leads to re-evaluation of _CST (avialable C states). I hope that the additional data will shed some light. -- Andriy Gapon