fwts: C state capability support check fails

@Alex,

So I've scanned a bunch of machines and some have P_LVL2_LAT and P_LVL3_LAT defined as non supporting C2/C3 and the DSDT does not contain a _CST. Some newer CPUs such a Sandybridge are configured like this and the Intel idle driver figures out the number of C states from the CPU id rather than trusting the firmware provided data (be it existent or not).

So.. perhaps I could phrase the warning something like:

"FADT P_LVL2_LAT is 101, a value > 100 indicates that the C2 state is not defined in the FADT. C states either defined in the _CST object or determined by the kernel from the CPU id."

Hi Colin,

The _CST are not located in DSDT but in a SSDT. Maybe I can get a
machine and send you a screenshot if I can get a Sandy Bridge - probably
need to install a Windows because some utilities only run on Windows :(

Any idea whom I can borrow a Sandy bridge system from?

On Thu, 2011-08-25 at 13:34 +0000, Colin King wrote:
> @Alex,
>
> So I've scanned a bunch of machines and some have P_LVL2_LAT and
> P_LVL3_LAT defined as non supporting C2/C3 and the DSDT does not contain
> a _CST. Some newer CPUs such a Sandybridge are configured like this
> and the Intel idle driver figures out the number of C states from the
> CPU id rather than trusting the firmware provided data (be it existent
> or not).
>
> So.. perhaps I could phrase the warning something like:
>
> "FADT P_LVL2_LAT is 101, a value > 100 indicates that the C2 state is
> not defined in the FADT. C states either defined in the _CST object or
> determined by the kernel from the CPU id."
>
> ** Changed in: fwts (Ubuntu)
> Status: In Progress => Incomplete
>

@Colin,

The below code is dumped from a Huron River system with a SandyBridge
CPU (Insyde BIOS).

Name(SSDT, Package(12)
{
"CPU0IST ", 0xA4B29018, 0x00000804, "APIST ", 0xA6E71A98, 0x00000303,
"CPU0CST ", 0xA6E70798, 0x00000727, "APCST ", 0xA6E6FD98, 0x00000119
})

The _CST objects are hidden in a package in a SSDT table and located in
the memory address.

Hi Alex,

I can add a lot of more complex code to hunt down and evaluate the _CST objects to figure out if any C states are defined on a system. However, the modern kernel idle handler for Intel CPUs tries to identify the CPU and decide the given C states so effectively ignores information anyway. I'm quite tempted to drop this warning as it's alarming and not giving an real information that's useful to us. I suppose if we want deeper C state checking, we should move that into the cstate test rather than overload the FADT checking.

Colin

For now, I will remove these warnings from the acpitables test and on a later spin add in more complex C state checks in the cstate test where it belongs.

See commit 683d6c8cf3bf92c103ca61ec0d8177c52340951b