Li, Aubrey wrote: > 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. > Agreed; that occurred to me this morning, that we're not checking the type of the returned object before accessing it, or using AcpiEvaluateObjectTyped(). So, yes, this is a necessary change, after we understand what it actually broken here. > But who knows how BIOS implements _CST, I'm waiting for the DSL file. > So, now that I've had a chance to look at the ACPI BIOS from an M10, the issue is more interesting.
There's no _CST object in the disassembly; the Toshiba BIOS uses the ASL 'Load' operator to dynamically load objects as part of the per-CPU _OSC object evaluation, which is where, I'm certain, the _CST objects are coming from. This makes inspecting the relevant BIOS code a little more difficult. I suggest that we first insert a kernel printf to tell us what type of object is returned from AcpiEvaluateObject(), to research this. > And again, I don't think this is ACPICA related. > Why, again, are you discounting this possibility? Is there some evidence you've seen that I haven't? :-) We have an unusual case here - few BIOSes load tables at run time in my experience. It's not inconceivable there's an ACPI CA bug here. Dana
