Dana.Myers wrote: > Liu, Jiang wrote: >> >>> 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. >>
Overhead here may not be a problem. We are only evaluate during initializatoin and _CST change notification. > it may hide really bugs and >> it really seems bug in acpica. Yeah, I thought we can trust acpica, although we received a update to 20080829 recently. >> > > Agreed. The observed issue is that AcpiEvaluateObject() returns > a Package object, with Package.Count >= 2 (as expected), but > accessing Package.Element[0] results in a GP trap. Package.Count > is a value determined by the ACPI CA parser - it thinks it found two > (or more) elements in the Package AML, but ACPI CA didn't copy > the elements to the returned object structure. The element ptr is just pointing an offset of the buffer we passed. If this this ptr is valid, we shouldn't encounter GP trap, it has nothing to do with what ACPI CA copied. > > At the very least, if this is actually caused by a broken Package AML > stream, ACPI CA should detect this and return an error. > > Other than Bill's conclusion that this must be caused by a bad _CST > "table", I haven't seen anything to indicate that actual ACPI BIOS > is incorrect. Perhaps Bill did look at the DSL for this > system to reach > this conclusion? > > Cheers, > Dana I'm waiting for the dsl file. Thanks, -Aubrey
