Hi all.
I have analyzed relative code with Aubrey, and could only give one
possible explanation for the phenomenon. It may be caused by buggy ACPI
BIOS implementation which returns non Package object on _CST evaluation,
and current cpupm driver dosen't check whether the returned object is a
package object before access it. So if a Integer object is returned,
obj->Package.Elements will be NULL, then #GP happens. Otherwise I couldn't
explain why "cnt = obj->Package.Elements[0].Integer.Value;" cause #GP.
Thanks!
Dana H. Myers <> wrote:
> Li, Aubrey wrote:
>> 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.
>>
> I'm fairly convinced that ontrap() is entirely the wrong solution to
> this issue.
> AcpiEvaluateObject() parses the _CST AML stream, allocates memory
> and constructs a structure in it. The structure is apparently
> incorrect; the
> structure is created by ACPI CA, and is not the BIOS data structure
> verbatim.
>
> I mean, AcpiEvaluateObject() is ACPI CA code. Let's make sure
> it's doing the right thing first.
>
> Sure, using ontrap() avoids a GP trap, but it's not addressing the
> actual problem.
> At least, I haven't seen any evidence this is the correct solution
> yet.
>
> First things first - I need to see the iasl -g of the system BIOS
> which encounters this issue.
>
> Dana
>
>> 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;
>>
>>
>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
