Date: Wed, 29 Jun 2011 00:04:08 +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: <4E0A41C8.3000904@FreeBSD.org> In-Reply-To: <BANLkTin_%2BZH%2Bo7rdR9ijHMtrXcSdH9ZSdQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E0A41C8.3000904>