kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument

[Andriy Gapon]

on 26/03/2009 16:41 Bruce Cran said the following:
> On Thu, 26 Mar 2009 16:33:08 +0200
> Andriy Gapon <avg at icyb.net.ua> wrote:
> 
>> on 26/03/2009 16:28 Bruce Cran said the following:
>>> On Thu, 26 Mar 2009 16:09:10 +0200
>>> Andriy Gapon <avg at icyb.net.ua> wrote:
>>>> If you specifically mean the generic case (non-cst) as you mention
>>>> in the PR, then I think that you didn't notice that cpu_cx_count
>>>> (the global variable) gets updated in acpi_cpu_generic_cx_probe,
>>>> So after looping over all CPUs it has the value of the maximum Cx
>>>> level supported by at least one CPU. Only then we loop again and
>>>> determine the smallest of the supported maximums.
>>> Yes, I had missed that.  I think the problem however is still that
>>> in the generic cx case the global is re-initialized to 0 and never
>>> gets updated.
>> It would be interesting to catch where/when this happens if this is
>> indeed the case.
>>
> 
> I added lots of printfs to acpi_cpu.c and found that it's occuring in
> acpi_cpu_startup; initializing it to 3 in that function (which I wrongly
> assumed was the lowest Cx state supported in ACPI) fixed the problem on
> my Athlon XP PC because the generic cx handling code then lowered
> cpu_cx_count to 1 based on the fact that sc->cpu_cx_count was also 1.
> 

Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in early exits
from it. So,  sc->cpu_cx_count is always set to at least 1, but if we exit via one
of the returns before the end of function, then global cpu_cx_count is never updated.

-- 
Andriy Gapon