Errors in dmesg annoy me and some of my contributions to the Linux kernel are powered by the desire to get rid of them. Not that error messages in themselves are so bad, but there is always the chance that they indicate a real or some deeper problem.

But fixing them is less easy when it comes to ACPI errors.

On my HP 2510p notebook I've been seeing this:

  ACPI Exception: AE_AML_PACKAGE_LIMIT, \
      Index (000000005) is beyond end of object 20090521 exoparg2-445
  ACPI Error (psparse-0537): Method parse/execution failed \
      [\_SB_.C2C3] (Node ffff88007e01eea0), AE_AML_PACKAGE_LIMIT
  ACPI Error (psparse-0537): Method parse/execution failed \
      [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e044de0), AE_AML_PACKAGE_LIMIT

I'm finally starting to be able to read disassembled ACPI code a bit, and that allowed me to finally trace this to a bug in the SSDT1 table. AFAICT it is harmless, as the value on which it fails is never used, but still.

So the problem is that the SSDT1 table defines two "packages" (which I understand to be similar to arrays; index starts at 0):

  C3F4 { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } /* six elements */
  C3F5 { 0x00, 0x00, 0x00, 0x00, 0x00 }       /* five elements */

Then in method \_SB_.C003.C0F6.C3F3._STM there are two calls to another method C2C3, using four arguments (Arg0 to Arg3):

  \_SB.C2C3 (Local2, Local3, Local1, C3F4)
  \_SB.C2C3 (Local2, Local3, Local1, C3F5)

And that method C2C3, which is defined in the DSDT table, does the following in two branches:

  Store (Local2, Index (Arg3, 0x05))
  Store (0x00, Index (Arg3, 0x05))

The first line tries to store value Local2 in the sixth element of the package passed as Arg3, i.e. either C3F4 or C3F5. In the case where Arg3 is C3F4, this works fine, but in the case where Arg3 is C3F5 it fails because that package only has five elements.