Created attachment 257139 [details] full dmesg output Laptop Dell Inc. XPS 15 9560/05FFDN, BIOS 1.3.3 05/08/2017 [ 0.001000] ACPI: Core revision 20170303 [ 0.032597] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210) [ 0.032605] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170303/psobject-241) [ 0.032647] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp11) while loading table (20170303/tbxfload-228) [ 0.035511] ACPI Error: 1 table load failures, 12 successful (20170303/tbxfload-246)
Created attachment 257173 [details] acpidump output Attaching "acpidump -o acpidump.dat" result, for checking the result. From my understanding those two are related: https://bugzilla.redhat.com/show_bug.cgi?id=1413342 and https://bugzilla.kernel.org/show_bug.cgi?id=193531 Moreover seems that this PR supposed to fix it: https://github.com/acpica/acpica/pull/189/
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. I've linked the bug there: http://bugs.acpica.org/show_bug.cgi?id=962
(In reply to Lv Zheng from comment #2) > 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. > > I've linked the bug there: > http://bugs.acpica.org/show_bug.cgi?id=962 Hm, are you sure you used the right bug link?
(In reply to Lv Zheng from comment #2) > 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. > > I've linked the bug there: > http://bugs.acpica.org/show_bug.cgi?id=962 Sorry, but I don't see any relationship to this bug. And no linked entry either. Are you sure it's the valid bug number?
If ((PCHV () == SPTH)) { Scope (_SB.PCI0.XHC.RHUB) { Device (HS11) The "If" block is executed in a deferred way. Thus the issue. ACPICA calls such table level executable AML as "module level code". The bug link is: https://bugs.acpica.org/show_bug.cgi?id=963 Not 962, sorry for the mistake.
In fact, ACPICA supports support MLC in an old style (deferred). If there is no strict execution order required, ACPICA can execute such If block correctly. And if the required strict order is not related in one table but across tables, ACPICA can work it around by this patch: https://patchwork.kernel.org/patch/9347347/ The final fix should be this patch: https://patchwork.kernel.org/patch/9347349/ The fixes are blocked by another issue. Enabing them could cause regressions because without fixing that issue. See ACPICA bug 963 for reference. Your case doesn't look like a one-table order problem. You can give the 2 patches a try. DSDT Line 11757: OperationRegion (PNVA, SystemMemory, PNVB, PNVL) Field (PNVA, AnyAcc, Lock, Preserve) { PCHS, 16, DSDT Line 12751: Name (SPTH, One) Name (SPTL, 0x02) Method (PCHV, 0, NotSerialized) { If ((PCHS == One)) { Return (SPTH) /* \SPTH */ } If ((PCHS == 0x02)) { Return (SPTL) /* \SPTL */ } Return (Zero) } DSDT Line 13978: If ((PCHV () == SPTH)) { Scope (_SB.PCI0.XHC.RHUB) { Device (HS11) SSDT3 Line 215 Scope (\_SB.PCI0.XHC.RHUB.HS11)