improve cx_lowest logic

Kevin Oberman kob6558 at gmail.com
Thu Sep 6 03:51:59 UTC 2012


On Wed, Sep 5, 2012 at 1:36 PM, Andriy Gapon <avg at freebsd.org> wrote:
> on 05/09/2012 20:41 Kevin Oberman said the following:
>> On Wed, Sep 5, 2012 at 9:32 AM, Andriy Gapon <avg at freebsd.org> wrote:
>>> on 05/09/2012 19:23 Kevin Oberman said the following:
>>>> On Wed, Sep 5, 2012 at 9:12 AM, Andriy Gapon <avg at freebsd.org> wrote:
>>>>> on 05/09/2012 18:17 Kevin Oberman said the following:
>>>>>> Thanks so much! This should finally make Cx states work on my
>>>>>> ThinkPad! I really appreciate it. Guess it's time to do my weekly
>>>>>> upgrade of this system.
>>>>>
>>>>> I haven't sneaked in that other commit :-(
>>>>
>>>> Oops! :-(
>>>>
>>>> Oh, well. At least it should make it to /base/stable/9 soon. Right???
>>>> (I only run release/ or releng/ or for an occasional test.)
>>>>
>>>
>>> It's already in stable/9 :)
>>
>> Ahh! I now see C3/109, but I see some strange behavior. When on AC
>> power, only C1/1 and C2/104 are available, but cx_lowest is C3, even
>> though C3 is not available. If I switch to battery, C1/1, C2/80 and
>> C3/109 are available (???), but cx_lowest is set to C2. I find the Cx
>> value sets a bit odd, but the setting of cx_lowest appears to be a
>> bug, at least to me. I can manually set cx_lowest to C3 and I actually
>> use C3.
>>
>> My suspicion is that there is either a race or a logic issue where
>> x_lowest is reset to the lowest value before the available Cx values
>> are set, so cx_lowest is always set the the lowest Cx state from the
>> previous power configuration. (This is a guess, but it fits what I am
>> seeing very well.)
>>
>
> Hmm, this looks like the older behavior.
> What revision are you at?  Also, any local ACPI-related patches?
>
> --
> Andriy Gapon


I'm at R239879, exactly a week ago. Do you have the rev of the commit?
I probably just missed it.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6558 at gmail.com


More information about the freebsd-acpi mailing list