http://bugzilla.kernel.org/show_bug.cgi?id=12881
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REJECTED |REOPENED Resolution|INVALID | ------- Comment #12 from [email protected] 2009-03-17 14:02 ------- There appears to be more to this problem than simply a missing package element. Here is the actual disassembly: Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0x00000000, 0x000000FD } }) Zero Zero Zero 0x00000002 ACPI Error (psloop-0225): Found unknown opcode FD at AML address 00585759 offset 56ED, ignoring [20090220] The AML parser has become confused in the middle of the package. It looks like the NumProcessors should be 2. Here is the AML from the acpidump: 56f0: 08 5f 50 53 ......_PPC..._PS 5700: 44 12 0f 01 12 15 05 0a 05 0a 00 0c 00 00 00 00 D............... 5710: 0c fd 00 00 00 0c 02 00 00 00 ...........N.\._ The inner package has an AML length of 15 and 5 objects. However, the outside package (_PSD) only has an AML length of 0F. This is what is causing the parser to abort in the middle of the package. The outside package should have an AML length at least as long as the inner package. Compiling with the original compiler used for the BIOS (iASL 20060113), we get: Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF } }) 00000057....08 5F 50 53 44 ................................. "._PSD" 0000005C....12 18 01 ....................................... 0000005F....12 15 05 0A 05 0A 00 0C FF FF FF FF 0C FF FF FF 0000006F....FF 0C FF FF FF FF .............................. Here, the inside package has the same length (15), and the outside package has the correct length (18). I used the 0xFFFFFFFF values to force the compiler to emit DWORD opcodes for the constants (0C) and bring up the package size (AML length) to what we saw in the original BIOS AML code (15). So, I don't think there is a problem with the iASL compiler. This is the kind of package that the BIOS often attempts to change on the fly. For example, if the number of CPUs changes. It may be that the BIOS screwed up the package when it tried to set the number of CPUs on the fly. Here's my guess. This was probably the original BIOS ASL code: Scope (\_PR.CPU1) { Name (_PPC, 0x00) Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0x00, 0x00, 0x00 } }) } Compiled: 00000057....08 5F 50 53 44 ................................. "._PSD" 0000005C....12 0F 01 ....................................... 0000005F....12 0C 05 0A 05 0A 00 0A 00 0A 00 0A 00 ......... Note that now the outside package length is the same as what we have seen in the acpidump -- namely, 0F. Also, note that all of the constants within the inner package are declared with a BYTE opcode (0A). I think that the BIOS stuffed new values into the inner package using DWORD opcodes. It updated the inner package length, but ***forgot to update the outer package length***. Presumably, the original code had a bunch of NOOPs or similar after the inner package so that there was room for the longer constants. The upshot of all this is that we should probably discover what Windows does with this type of problem. If the ACPICA parser did not abort when the outside package length was exceeded, it could probably parse this code as it was "intended". If we need to do this for Windows compatibility, then we should do it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
