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

Bruce Cran bruce at cran.org.uk
Thu Mar 26 07:42:07 PDT 2009


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.

-- 
Bruce Cran


More information about the freebsd-acpi mailing list