Date: Fri, 1 Jul 2011 01:52:34 +0300 From: Vitaly Magerya <vmagerya@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook Message-ID: <BANLkTinRY-h%2BkpXtwWJ_L86qVRdoynFSdg@mail.gmail.com> In-Reply-To: <4E0CE158.6030804@FreeBSD.org> 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> <4E0CE158.6030804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon <avg@freebsd.org> wrote:
> 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.
I see.
>> 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)...
Since VDRV is always 0, you can't really say if it's a coincidence
or the intended behavior.
> 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...
I got the dumps for Linux (it appears that you can't just read
/dev/mem on there, you need to mmap it). The summary of differences
between FreeBSD and Linux right after the boot:
DB00: 01 -> 00
P80D: 06:08:00:00 -> 06:08:4C:00
PCP0: 1D -> BF
PCP1: 1D -> BF
BRTL: 00 -> 1E
VDRV: 00 -> 01
(Note that C1ON is 0 just as with FreeBSD, and yet powertop does
report C2 and C4).
Then, after about 4 minutes of uptime, C1ON changes to 1 (and
powertop still reports the same states).
> Do you have powerd enabled? Can you check if anything changes
> with it disabled (just for the sake of testing).
I do; nothing changes if I don't.
> 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.
I'll try to compile the kernel with dtrace and post the results back.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinRY-h%2BkpXtwWJ_L86qVRdoynFSdg>