|
Description
|
A user on OpenSolaris reported that SpeedStep was not working on his laptop and
was receiving the following error messages:
Feb 8 22:34:06 unknown cpudrv: [ID 805513 kern.info] NOTICE: cpu_acpi: _PSS package not found.
Feb 8 22:34:06 unknown cpudrv: [ID 978953 kern.warning] WARNING: cpu_acpi: error parsing _PSS for CPU instance 1
Inspecting his ACPI tables, I found the following ASL for \PR.CPU1:
Scope (\_PR.CPU1)
{
Name (HI1, 0x00)
Name (HC1, 0x00)
Name (TLD1, 0x00)
Method (_PDC, 1, NotSerialized)
{
CreateDWordField (Arg0, 0x08, CAP1)
Store (CAP1, PDC1)
If (LEqual (TLD1, 0x00))
{
-----> If (LEqual (And (PDC1, 0x0A), 0x0A))
{
If (And (CFGD, 0x02))
{
OperationRegion (IST1, SystemMemory, DerefOf
(Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05
)))
Load (IST1, HI1)
}
Store (0x01, TLD1)
}
}
}
}
In particular, note the line marked with the arrow above. It's
checking to see if bits 1 & 3 are enabled in the PDC and will load
cpu1ist if true. I believe this is the problem since Solaris does not
enable bit 1. According to the Intel Processor Vendor-Specific ACPI
enabling bit 1 indicates:
if set, OSPM supports the C1 "I/O then Halt" FFH sequence for
multi-processor configurations.
Typically, I've seen PDC methods check to see if bits 0 & 3 (0x9) are
enabled. These make a lot more sense given that they are P-state related
bits:
bit 0: if set, OSPM is capable of direct access to Performance State MSRs.
bit 3: if set, OSPM is capable of independent C1, P state and T state
support for each processor for multi-processor configurations.
I contacted folks at Intel and was told that this was a weel-known BIOS bug on some
platforms. Their suggestion was for Solaris to enable the bit as it was fairly hopeless
to expect this to be fixed by the BIOS writers. This was what they did for Linux.
|
