Liu, Jiang wrote: > 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!
Right, we need to use AcpiEvaluateObjectTyped to call _CST with ACPI_TYPE_PACKAGE if we run into this case. But who knows how BIOS implements _CST, I'm waiting for the DSL file. And again, I don't think this is ACPICA related. Thanks, -Aubrey > > 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 >>
