There are still some issues pertaining to the support of the technically illegal "module-level code". This is executable AML code that appears outside of any control method. 1) Forward references are not supported. 2) Only a limited subset of AML opcodes are supported. The solution to these issues may require some large changes to the table loading mechanism. A possible solution may be something like this: Execute the entire “root” of the table as a single, large control method. Would perform one or two load passes, then an execute pass. The main difference from a regular method would be that all objects that are created are permanent. After this, the table would be "loaded" into the namespace, and all of the module-level code will have been executed. This provides a general-purpose solution that solves the problems above.
IMO, this bug implies the divergent handling of TermList between Linux AML parser and Windows AML parser. Let me ask several questions about this: 1. IMO, there is no forward reference in AML. We can identify that Windows doesn't support forward reference in Method. My question is do we support forward reference in module level code? 2. There are several TermList related AML syntax: AMLCode := DefBlockHeader TermList DefScope := ScopeOp PkgLength NameString TermList DefMethod := MethodOp PkgLength NameString MethodFlags TermList DefElse := Nothing | <ElseOp PkgLength TermList> DefIfElse := IfOp PkgLength Predicate TermList DefElse DefWhile := WhileOp PkgLength Predicate TermList I can see ACPICA supports module level code for If/Else/While TermList. And we know for Method, TermList needn't to be descent parsed. But for Scope, what should we do? I can even see an issue in iASL which doesn't allow module level code to be compiled in Scope. Is there any limitation for doing so for Scope? Thanks and best regards -Lv
The bottom line is that ACPICA parser performs a two-pass parse for ACPI tables (DSDT/SSDT), while ignoring control methods. Individual control methods are only parsed once, so forward references are not supported. I'm not sure if any of this is in the actual ACPI spec.
According to the spec, where TermList is defined, we should also parse the module level code once. There is no explicit definition in the AML spec that the module level code should be parsed twice. If we took the AML spec as the "priori" concepts, then the 2-pass parsing might be the "posteriori" errpr resulted from the bug fixes. We parsed the module level code twice because of the bug that we didn't support TermList or any list of terms in the ParseLoop correctly, which made the possible module level execution impossible.
IMO, the new direction is worthy of try. We could do the following things to avoid regressions: 1. fix TermList parsing in the parser component, by doing so, most of the module level code will be executed in the first-pass parsing. 2. add an option for the second-pass parsing. 3. test the whole ASLTS with second-pass parsing disabled and figure out the cases that cannot be supported by this mode. IMO, only limited forward reference in the module level code cannot be supported in this mode. Some of them may because of the "SimpleName"/"SuperName"/"Opcode types" support issue in ACPICA. 4. re-validate the cases on Windows to figure out which mode is the the way Windows is parsing the module level code.
*** Bug 763 has been marked as a duplicate of this bug. ***
Hi, Bob I did following experiments: 1. In acpiexec Move address space handler initialization before acpi_load_tables(). Combine 2 load pass into 1 execute pass. Make AcpiPsLinkModuleCode() and AcpiNsExecModuleCodeList() no-op. With some efforts around the WalkState->MethodNode and ACPI_PARSE_MODULE_LEVEL, everything works. So this is not a big issue for ACPICA. 2. In Linux I tried to move address space handler initialization before acpi_load_tables(). But kernel panic can be obeserved during boot. I tried to move the acpi_load_tables() to a later initialization step before acpi_initialize_objects(), then graphics driver seems not working any more. We need to filter out which namespace nodes are referenced during acpi_early_init() and acpi_bus_init(). So this seems to be a big issue for ACPICA OSPM users. Do you know any historical Linux reasons the load parsing is implemented in such a way. Thanks and best regards -Lv
You can find the required fixes here: https://github.com/acpica/acpica/pull/120
Fixes are updated here: https://github.com/acpica/acpica/pull/134 Thanks -Lv
Upstreamed on top of the lock fixes. So re-close it.
Linking Linux kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=189931 Re-opening as this option is not enabled.
Linking Linux kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=153541
There is still no OSPM enabling this fix. So re-open it. The issue is blocked by the following bug: https://bugs.acpica.org/show_bug.cgi?id=1333 Thanks Lv
Linking a kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=192621 Thanks
Created attachment 1080 [details] acpi dump 4.9.3-200 for acpi errors Fatal errors occur in Kernel 4.9.3 that did not occur with 4.8.15 and earlier
Created attachment 1081 [details] dmidecode for comment #13 These issues occurred with Kernel 4.9.3 and where not present in kernel 4.8.15 or earlier. See comment #13 above
Created attachment 1087 [details] acpidump for Eurocom Commander acpidump that parses with fatal errors as describe in kernel bug here. https://bugzilla.kernel.org/show_bug.cgi?id=192621
Created attachment 1088 [details] dmidecode for Eurocom Commander, same machine as attachmetn 1087
Lv, Can we close this one?
It looks like module level code is still disabled by default. https://github.com/acpica/acpica/blob/master/source/include/acpixf.h#L312 Are there plans to enable this by default eventually?
New report here: https://bugzilla.kernel.org/show_bug.cgi?id=196165
so, can this be closed?
From the explanation I understand that now instead of breaking changes the "package" pull request would not be merged, but the issue was solved in a different, slighter way: "The pull request doesn't fix the problem while the fix is already upstreamed. The upstreamed fix just cannot be enabled as it is blocked by the issue fixed by the PR. However the PR wouldn't be accepted by ACPICA upstream. It's been planning to do a slighter change to still treat in-package name string as object reference." But at the same time it is still disabled in master. So, what exactly preventing from enabling it, if it's fixed? Or there are still some problems with it? If yes - why to urge to close this issue?
New report here: https://bugzilla.kernel.org/show_bug.cgi?id=197207 Thanks Lv
New bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=198051 Fixing module-level code could fix this issue.
(In reply to erik.schmauss from comment #24) > New bug report here: > https://bugzilla.kernel.org/show_bug.cgi?id=198051 > > Fixing module-level code could fix this issue. This bug reveals issues in forward referencing of package elements.
Linking kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515 This is a module-level code issue and doesn't involve forward references of package elements.
ACPICA version 20180209: We believe that all of the various issues in this report are resolved in 20180209. The new architecture for the module-level code is now the default.
