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

[John Baldwin]

On Thursday 26 March 2009 3:51:51 pm Daniel Dvorák wrote:
> Hi all,
> 
> I found out this error on the other computers. Will it be helpful for
> analyzing to send infromation about cpu, acpi table and so on ? Or is the
> first example enough ?

The example is enough, we just need someone to test the patch and make sure it 
fixes the problem.

> DD
> 
> -----Original Message-----
> From: Stephane E. Potvin [mailto:sepotvin at FreeBSD.org] 
> Sent: Thursday, March 26, 2009 4:04 PM
> To: John Baldwin
> Cc: Bruce Cran; Daniel Dvor(ák; freebsd-acpi at freebsd.org
> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid
> argument
> 
> 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 at 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
> 
> 



-- 
John Baldwin