Date: Thu, 26 Mar 2009 14:41:40 +0000 From: Bruce Cran <bruce@cran.org.uk> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <20090326144140.2203c0d8@gluon.draftnet> In-Reply-To: <49CB9224.6010509@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Mar 2009 16:33:08 +0200 Andriy Gapon <avg@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090326144140.2203c0d8>