kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid
argument
Daniel Dvorák
dandee at hellteam.net
Thu Mar 26 13:11:08 PDT 2009
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 ?
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
More information about the freebsd-acpi
mailing list