Date: Thu, 26 Mar 2009 11:04:18 -0400 From: "Stephane E. Potvin" <sepotvin@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: =?ISO-8859-1?Q?Daniel_Dvor=28=E1k?= <dandee@hellteam.net>, freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <49CB9972.4030502@FreeBSD.org> In-Reply-To: <200903261050.51602.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > 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? > The intent when I added support for cx states on SMP systems was to use the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present and can be used. This whole piece of code is really convoluted and there's been a few errors found in it over time so I wouldn't be surprised if there were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CB9972.4030502>