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.
Use on_trap is a little overhead here, it may hide really bugs and it really seems bug in acpica. > > 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
