Li, Aubrey wrote:
> Dana H.Myers wrote:
>
>> Bill Holler wrote:
>>> Try disabling C-states (C2 and C3) in BIOS.
>>> We still parse the _CST object when idle_cpu_no_deep_c is set
>>> to be able to report what C-states are available. :-(
>>>
>>> I will have a fix you can try in under an hour.
>> Whoa. Let's figure out why ACPI CA is returning an
>> apparently invalid Package structure from AcpiEvaluateObject()
>> first - it's likely not directly the result of a buggy _CST "table".
>>
>> [_CST is an ACPI object encoded as AML, it's not simple
>> table like the firmware tables are; ACPI CA parses it and
>> constructs the returned object which is tripping over a panic]
>>
>> What I need to see is the entire output of '/home/sethg/iasl -g' for
>> this machine.
>>
>> Dana
>>
> Inconsistency of _CST count and package elements caused this problem.
> The count looks fine while the package elements don't exist.
>
> We could be more robust to check elements before deref to it.
> But I don't think it's ACPI CA related.
>
> Thanks,
> -Aubrey
ontrap is good to me, who knows how the buggy BIOS implements object.
But if we pinpoint this issue, something like this may work.
diff -r 6adf6294c134 usr/src/uts/i86pc/os/cpupm/cpu_acpi.c
--- a/usr/src/uts/i86pc/os/cpupm/cpu_acpi.c Mon Mar 02 22:33:16 2009 -0800
+++ b/usr/src/uts/i86pc/os/cpupm/cpu_acpi.c Wed Mar 18 11:28:09 2009 +0800
@@ -646,6 +646,8 @@
return (-1);
}
+ if (obj->Package.Elements == NULL)
+ return (-1);
/*
* Does the package look coherent?
*/
@@ -671,6 +673,8 @@
ACPI_OBJECT *element;
pkg = &(obj->Package.Elements[i]);
+ if (pkg == NULL)
+ return (-1);
reg = (AML_RESOURCE_GENERIC_REGISTER *)
pkg->Package.Elements[0].Buffer.Pointer;
cstate->cs_addrspace_id = reg->AddressSpaceId;
