Dana.Myers wrote: > 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.
Did you receive the tar.gz file I sent? _CST is already there in cs0/cs1.dsl. the dynamical table can be dump out by acpidump. anyway, _CST call YCST eventually, which will return the package we need. >> 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 All of my thoughts depends on this report. ================================= > Your kernel is panicking on this line: > > /* > * Does the package look coherent? > */ > cnt = obj->Package.Elements[0].Integer.Value; ================================= This is weird because as I pointed out, the element ptr is just pointing an offset of the buffer we passed. If the kernel really panic on this line, It's centernly not a ACPI CA bug. Whatever ACPI CA does can't change the address. Does this make sense? But I doubt the panic place is really here, can the bug reporter send the panic stack here? Thanks, -Aubrey
