Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Mar 2009 10:50:51 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Bruce Cran <bruce@cran.org.uk>
Cc:        Daniel =?utf-8?q?Dvo=C5=99=C3=A1k?= <dandee@hellteam.net>, freebsd-acpi@freebsd.org
Subject:   Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
Message-ID:  <200903261050.51602.jhb@freebsd.org>
In-Reply-To: <20090326143731.0d2b7711@gluon.draftnet>
References:  <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote:
> On Thu, 26 Mar 2009 09:37:50 -0400
> John Baldwin <jhb@freebsd.org> wrote:
> 
> > No, the code is doing things differently on purpose (though I'm not
> > completely sure why).  For _CST it sets cpu_cx_count to the maximum
> > Cx level supported by any CPU in the system.  For non-_CST it sets it
> > to the maximum Cx level supported by all CPUs in the system.  I think
> > it is correct for cpu_cx_count to always start at 0 and only be
> > bumped up to a higher setting.  Setting it to 3 would be very wrong
> > for the _CST case as I've seen CPUs that support C4.
> 
> From briefly reading through the specifications I'd assumed the maximum
> power state was C3.

For the non _CST case that is all that is defined, yes.  However, _CST is a 
variable length array of Cx states, so it can support arbitrary numbers of 
states.

> I had thought the _CST block was wrong because in
> acpi_cpu_global_cx_lowest_sysctl it validates the new value against
> cpu_cx_count; if one CPU has a lower cx state than the others, then
> won't this tell the other CPUs to use an unsupported state?

It depends on if the CPU driver is smart enough to cap requests to 
sc->cpu_cx_count, though if it does presumably it would do that in the 
cx_generic case as well.  I'm not sure why it behaves differently for the 
_CST case, but I do think it is on purpose at least rather than an accidental 
bug.  Perhaps Nate can chime in with why?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903261050.51602.jhb>