Bug 5322 - Workaround for undeclared Z00X objects in Package declarations
Summary: Workaround for undeclared Z00X objects in Package declarations
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Robert Moore
: 5588 (view as bug list)
Depends on:
Reported: 2005-09-28 05:11 UTC by Thomas Renninger
Modified: 2006-09-28 13:13 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.14-rc1
Tree: Mainline
Regression: ---

Workaround for acpica (993 bytes, patch)
2005-09-28 05:12 UTC, Thomas Renninger
Details | Diff
Same workaround patched against 2.6.14-rc1 (1.04 KB, patch)
2005-09-28 05:14 UTC, Thomas Renninger
Details | Diff
acpidmp of a affected machine - grep for Z00G (119.98 KB, text/plain)
2005-09-28 09:29 UTC, Thomas Renninger

Description Thomas Renninger 2005-09-28 05:11:08 UTC
Some DSDTs have Package declarations like: 
Name (PBST, Package (0x04) 
Name (PBST, Package (0x04) 
The Z00X objects are never declared and therefore the whole _BST function to 
read battery state fails.
Comment 1 Thomas Renninger 2005-09-28 05:12:57 UTC
Created attachment 6172 [details]
Workaround for acpica

Add an object to the current scope if a Z00X object is used that has not yet
Comment 2 Thomas Renninger 2005-09-28 05:14:29 UTC
Created attachment 6173 [details]
Same workaround patched against 2.6.14-rc1
Comment 3 Thomas Renninger 2005-09-28 05:16:23 UTC
Kernel tested with a (not disassembled/recompiled) broken DSDT. 
One warning is printed at early DSDT parse time for undefined Z00X workaround. 
Battery state works fine now. 
Comment 4 Len Brown 2005-09-28 08:19:17 UTC
please attach the acpidump output
Comment 5 Thomas Renninger 2005-09-28 09:29:53 UTC
Created attachment 6174 [details]
acpidmp of a affected machine - grep for Z00G
Comment 6 Robert Moore 2005-09-28 14:47:11 UTC
// Workaround for undefined Z00X objects that seem to be predefined
// numbers in other compilers/interpreters.

Is this really true, or do "other" compilers/interpreters simply ignore 
unresolved names in some cases? What would be the point of having such 
predefined numbers, and why would anybody use "Z007" instead of the number 
they really wanted? Seems cryptic to me.

Comment 7 Robert Moore 2005-09-28 15:28:22 UTC
I find that the "other" compiler will compile even this code:

 Name (PBSS, Package () 

It would appear that virtually any ACPI name will work, the name is not 
checked for existence.  Therefore, a more general workaround will be required, 
not simply a check for names of the form Z00?

Actually, this is more of an ASL grammar change, I think. These names are not 
being treated as full references, they are just being treated as strings 
(albeit strings that represent a syntactically correct ACPI pathname.)
Comment 8 Thomas Renninger 2005-09-29 01:35:53 UTC
So we need an empty initialised string placeholder in package member
declarations if the name is not found in namespace?
I searched a bit to only add a new node/object if it is a package member
delaration, but I gave up ...
So in general the fix is right, but should only get triggered if it is a package
member declaration and if, we could add a placeholder for every not already
declared object (not only Z00X)?
I have to give the machine back in a week or so. I still have another bugreport,
but this would be more effort to test.
Comment 9 Thomas Renninger 2005-11-03 01:10:02 UTC
Why is this set to needinfo -> by mistake? 
Will this issue be addressed?  
I could have a look at it, with acpiexec it should be possible to test in 
userspace ... 
The ACPIspec says that external methods (and other variables, e.g. Field 
members?) can be referenced. Unfortunately only examples of declarations inside 
the Package itself are made. 
So we have a problem here similar to the not correctly referenced Alias problem 
if the declaration of the referenced Package member comes after the Package 
declaration, does this already work? 
Package(){FIEA, FIEB,META, METB, ...} 
after that comes: 
Field (....) {FIEA, FIEB, ...} 
Method META (...) {} 
Method METB (...) {} 
Is that possible and should it work? 
Additionally allow unreferenced/uninitialised objects we need something like: 
 1) Check whether the Package member is a reference, if not put it into a list  
    of unreferenced Package members 
 2) After parsing everything, check all unreferenced Package members and search  
    whether the object now exists and has been declared after the Package  
 3) If it does exist -> create the link/reference. 
 4) If it does not exist (as it is the case for these Z00x declarations) add an  
    uninitialised buffer/string object to the Package. 
This is more complex as I thought... as said I can have a look, but maybe this 
is a bit too complex for me... 
Comment 10 Robert Moore 2005-11-08 15:19:55 UTC
This is on my list of things to do. We are thinking of allowing unresolved 
references in limited contexts (in the AML interpreter). It will probably take 
some time, as your analysis suggests. Currently, names are resolved very early 
in the parsing process, and there is very little context at that time as to 
what the name will be used for.

As far as forward references -- in general, these work properly, as multiple 
passes are made through tables and control methods to resolve these. The 
problem with forward references to Aliases is a specific bug, not a general 
problem with the multipass mechanism.
Comment 11 Robert Moore 2005-11-17 10:38:09 UTC
*** Bug 5588 has been marked as a duplicate of this bug. ***
Comment 12 Robert Moore 2005-12-16 14:16:40 UTC
A fix for this has been released in version 20051216:

Implemented optional support to allow unresolved names within ASL Package 
objects. A null object is inserted in the package when a named reference 
cannot be located in the current namespace. Enabled via the interpreter slack 
flag, this should eliminate AE_NOT_FOUND exceptions seen on machines that 
contain such code.

Comment 13 Len Brown 2006-02-02 14:46:59 UTC
ACPICA 20050127 shipped in Linux-2.6.16-rc1-git6 -- closing.
Comment 14 Len Brown 2006-02-02 15:03:46 UTC
20060127 that is

Note You need to log in before you can comment on or make changes to this bug.