From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 28 21:04:14 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 8D5301065675 for ; Tue, 28 Jun 2011 21:04:14 +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 BD2558FC2B for ; Tue, 28 Jun 2011 21:04:13 +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 AAA12977; Wed, 29 Jun 2011 00:04:11 +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 1QbfS6-0005sP-BS; Wed, 29 Jun 2011 00:04:10 +0300 Message-ID: <4E0A41C8.3000904@FreeBSD.org> Date: Wed, 29 Jun 2011 00:04:08 +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> <4E09BADF.7050702@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 21:04:14 -0000 on 28/06/2011 22:37 Vitaly Magerya said the following: >> 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. > > 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 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 >> >> [...] >> >> 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. > > When I boot without power, I get these dumps [1,2]. For your > convenience, the same dumps decoded are at [3,4]. After C2 and C3 > become available, I get mostly the same dumps [5,6]: only C1ON > changes from 0 to 1. Yep. Now the biggest question is what that C1ON is and what changes its value. And how do we (and Linux) trigger that change. [snip] > If someone will tell me how the hell do you dump memory in Linux, > I'll submit the dumps for it too. Currently dd fails there with > this error: > > $ sudo dd if=/dev/mem of=... bs=1 skip=0x3F5C0C7D count=0x000000FF > dd: read /dev/mem: Bad address > > (Reproduced by memory). No idea here. Maybe they don't allow to access memory reserved by kernel from userland, even to root. > [1] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-before.bin > [2] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-before.bin > [3] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-before.txt > [4] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-before.txt > [5] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-after.bin > [6] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-after.bin 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... -- Andriy Gapon