Well, yes, if the external cannot be resolved at runtime, it will generate an error -- Unless you have the update to ACPICA that allows unresolved references within packages, AND you enable the interpreter slack mode.
> I got the DSDT.aml (the result of successfully compiling dsdt.dsl > remember) and decompiled it - the result is expected to be the same as > dsdt.dsl... but it wasn't! There were substantial differences. When this > new version was compiled, it produced errors. Any disassembler is not *guaranteed* to generate the exact source code. I would be interested in a bit more explanation, however. Bob > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Simon Bridge > Sent: Tuesday, January 24, 2006 7:42 PM > To: Moore, Robert > Cc: Thomas Renninger; [email protected] > Subject: RE: reality check: dsdt.dsl -> compile -> DSDT.aml -> decompile - > >DSDT.dsl but dsdt.dsl neq DSDT.dsl > > On Tue, 2006-01-24 at 14:39 -0800, Moore, Robert wrote: > > The change to ACPICA to "support" such non-existent names was > > implemented in the run-time interpreter but not the compiler. > > > > The iASL compiler will still emit an error in this case, and I feel this > > is correct since we want the compiler to catch these kinds of errors. > > The "-f" flag will override this and any other errors, however. > > > > Another very simple fix to this kind of error is to add an "External" > > statement to the ASL code (for the missing symbol), same as any other > > symbol which is defined in another table. > > > > Bob > > > > > Cool - thanks guys. (Robert and Thomas) > > I should note, in responce here, that Z007 is not in the code. > "Externalling" it produces the same kernel messages. > > The CPU0 symbol is different - neither of you seemed to have spotted > that (correct me). > > The firmware dsdt was decompiled to dsdt.dsl and this edited. It > compiled *without error* to DSDT.aml and was acepted by the kernel. > > There were kernel messages (explained by Thomas - thanks) which I > thought I'd got rid of. So I decided to check that the aml code was what > I thought it was. > > I got the DSDT.aml (the result of successfully compiling dsdt.dsl > remember) and decompiled it - the result is expected to be the same as > dsdt.dsl... but it wasn't! There were substantial differences. When this > new version was compiled, it produced errors. > > I was hoping this was a known problem with iasl or something. Has nobody > seen this before - it happens every time on this machine. Perhaps it's > just me. But if I cannot trust the compiler to render the code properly > where am I? > > Thomas: I'll try the patches ... isn't the patch you posted for the > 2.6.16 kernel? (Hmmm... to self: isn't that what he said?) > > It has already occurred to me to test this all out with a vanilla kernel > - done it before - only I'm going to have to support this distro to > others so I'd rather do what's possible with the distro kernel as well. > > (I'd normally do this sort of fiddling in Fedora. I hoped to keep the > Ubuntu box standard as possible so I can anticipate what users are > experiencing.) > > If you think I'll really need to upgrade the kernel, you're probably > right. My old problem of the DSDT not being taken into the kernel was > solved by a kernel upgrade :) > > Hopefully the ubuntu folk will add the next big ACPI patch to their > repos in good time. > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:linux-acpi- > > > [EMAIL PROTECTED] On Behalf Of Thomas Renninger > > > Sent: Tuesday, January 24, 2006 1:11 AM > > > To: Simon Bridge > > > Cc: [email protected] > > > Subject: Re: reality check: dsdt.dsl -> compile -> DSDT.aml -> > > decompile - > > > > DSDT.dsl but dsdt.dsl neq DSDT.dsl > > > > > > Simon Bridge wrote: > > > > # iasl -ta dsdt.dsl > > > > > > > > Intel ACPI Component Architecture > > > > ASL Optimizing Compiler version 20050930 [Nov 20 2005] > > > > Copyright (C) 2000 - 2005 Intel Corporation > > > > Supports ACPI Specification Revision 3.0 > > > > > > > > ASL Input: dsdt.dsl - 3471 lines, 121247 bytes, 1565 keywords > > > > AML Output: DSDT.aml - 13975 bytes 377 named objects 1188 executable > > > > opcodes > > > > > > > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 542 > > Optimizations > > > > > > > > ... which seems fine so far. > > > > > > > > # cp DSDT.amp /etc/mkinitramfs/DSDT.aml > > > > > > > > reboot. > > > > I see a syslog saying that this DSDT.aml is detected and loaded. > > > > However, I get errors as follows: > > > > > > > > ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] > > (Node > > > > cbed7be0), AE_NOT_FOUND > > > > ACPI-0362: *** Error: Looking up [Z007] in namespace, AE_NOT_FOUND > > > > > > > > ... ad infinitum. > > > Those Z00X objects should get fixed as soon as the next big ACPI patch > > > from > > > Len goes mainline. > > > > > > This should be interesting for a lot people here, currently patching > > > there DSDTs because of this error. > > > > > > See: http://bugzilla.kernel.org/show_bug.cgi?id=5322 > > > I expect you used an iasl compiler newer than 20051216 that already > > > includes > > > the fix and therefore does not complain about the missing Z007 object. > > > Your kernel is probably still missing this fix and constantly > > complains. > > > > > > You may want to patch 2.6.16-rc1 with Len's latest patches: > > > > > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6 > > .1 > > > 6/ > > > If you try this out, I'd be glad if you could report back whether the > > > Z00X issue is really finally solved for you. > > > > > > > > > > > Puzzled - especially since Z007 does not appear in dsdt.dsl > > (replaced by > > > > "ones" on advice from this forum - a la acer laptops and Z007 being > > > > nonexistant anywhere.) > > > ... > > > > > > > which provides the following error: > > > > Error 1061 - Object does not exist (\_PR.CPU0._PPC) > > > The object is probably declared in SSDT. > > > acpidmp >/tmp/acpidmp > > > acpixtract ssdt acpidmp >ssdt > > > iasl -d ssdt > > > > > > To get rid of the compiler error just declare it: > > > External (\_PR.CPU0._PPC) > > > So that the compiler knows it is declared in some > > > other, later loaded ACPI table. > > > > > > > > This appears six times overall, across methods: > > > > _Q8A, _Q8D, _Q8D ... which seem unhelpful. > > > > > > > > I see /proc/acpi/processor/CPU0 contains files; > > > > info limit power throttling > > > > > > > > I see that _PPC is a reserved method name: > > > > _PPC Method with 0 arguments, must return a value > > > It is probably because of the above missing external(). > > > > > > If the Z00x is your only problem, don't waste time by trying > > > to rewrite your DSDT, better try out Len's patches > > > and let us know if you still see anything bad. > > > > > > Thomas > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" > > in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
