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;
>
>   


Reply via email to