From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 30 20:49:34 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 6D529106564A for ; Thu, 30 Jun 2011 20:49:34 +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 B471D8FC13 for ; Thu, 30 Jun 2011 20:49:33 +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 XAA24470; Thu, 30 Jun 2011 23:49:30 +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 1QcOB0-000CQE-9b; Thu, 30 Jun 2011 23:49:30 +0300 Message-ID: <4E0CE158.6030804@FreeBSD.org> Date: Thu, 30 Jun 2011 23:49:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Thu, 30 Jun 2011 20:49:34 -0000 on 30/06/2011 22:49 Vitaly Magerya said the following: > Andriy Gapon wrote: >> on 28/06/2011 22:37 Vitaly Magerya said the following: >>> Is there some simple way of sending fake advertisement? Or will >>> that lead to disaster? >> >> It doesn't make sense without actual support. >> And maybe (just maybe) it won't change much anyway. > > I see. Should I hold my breath for this code? Probably no. Here's what Intel docs say: The processor implements two software interfaces for requesting low power states, MWAIT instruction extensions with sub-state hints and P_LVLx reads to the ACPI P_BLK register block mapped in the processor’s I/O address space. The P_LVLx I/O reads are converted to equivalent MWAIT C-state requests inside the processor and do not directly result in I/O reads on the processor FSB. My interpretation is that both mechanism should work equally. >> Since we are now dealing with black box/magic behind ACPI, may I try to suggest >> doing some DSDT hacks and seeing what changes? One thing to try would be >> replacing "\_SB.VDRV" with "VDRV" in _Q51 and _Q52 methods. >> That at least should rid you of those annoying ACPI errors, at best it could >> improve something. At the very worst it may fry your machine, though... > > Just tried this. Nothing seems fried; the visible effect is that > now when I plug the power cord in backlight brightness turns all > the way up, and then back down the I turn it off. No changes in > SNVS or GNVS variables aside from the usual ones. At least some improvement (or just a difference)... Not sure how to proceed here further. Apparently we do something differently from Linux (and presumably Windows) here, but it's quite hard to tell what. The problem is that SNVS/GNVS (in particular C1ON) seem to be controlled by some firmware/hardware and that's a black box. And I am still puzzled about which exactly event triggers change in C1ON value on FreeBSD... Do you have powerd enabled? Can you check if anything changes with it disabled (just for the sake of testing). P.S. Just an idea, maybe the following script could be of some help if you have dtrace support in your kernel: $ dtrace -n 'fbt::AcpiEvaluateObject:entry { printf("%p->%s\n", args[0], (string)args[1]); }' I would like to get entries, if any, around the time that the C-states become available. -- Andriy Gapon