Bug 196165

Summary: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210)
Product: ACPI Reporter: Anton Kochkov (anton.kochkov)
Component: BIOSAssignee: acpi_bios
Status: RESOLVED MOVED    
Severity: normal CC: anton.kochkov, lv.zheng
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.12_rc6 Tree: Mainline
Regression: No
Attachments: full dmesg output
acpidump output

Description Anton Kochkov 2017-06-23 08:51:46 UTC
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)
Comment 1 Anton Kochkov 2017-06-25 13:29:18 UTC
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/
Comment 2 Lv Zheng 2017-06-26 06:52:09 UTC
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
Comment 3 Anton Kochkov 2017-06-28 05:41:34 UTC
(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?
Comment 4 Anton Kochkov 2017-07-07 04:05:58 UTC
(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?
Comment 5 Lv Zheng 2017-07-07 07:23:10 UTC
    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.
Comment 6 Lv Zheng 2017-07-07 07:40:35 UTC
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)