Date: Thu, 30 Jun 2011 23:49:28 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Vitaly Magerya <vmagerya@gmail.com> Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook Message-ID: <4E0CE158.6030804@FreeBSD.org> In-Reply-To: <BANLkTikwgy%2BKuA5E5zXQKGT-eyV35YAVag@mail.gmail.com> References: <BANLkTim%2B1UwquMJ32WP8wZBGkYxPv78MLA@mail.gmail.com> <4E05EB91.9090509@FreeBSD.org> <BANLkTi=dyNx=TjyEqYMhSkRtddjVA4nAtw@mail.gmail.com> <4E0862A0.7060405@FreeBSD.org> <BANLkTikmVUtLyANBSqYb%2BL-xkwQ4Zo51Eg@mail.gmail.com> <4E09BADF.7050702@FreeBSD.org> <BANLkTin_%2BZH%2Bo7rdR9ijHMtrXcSdH9ZSdQ@mail.gmail.com> <4E0A41C8.3000904@FreeBSD.org> <BANLkTikwgy%2BKuA5E5zXQKGT-eyV35YAVag@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 30/06/2011 22:49 Vitaly Magerya said the following:
> Andriy Gapon <avg@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E0CE158.6030804>