Bug 196165 - ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210)
Summary: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUN...
Status: RESOLVED MOVED
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: acpi_bios
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-23 08:51 UTC by Anton Kochkov
Modified: 2017-07-07 07:40 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.12_rc6
Tree: Mainline
Regression: No


Attachments
full dmesg output (90.05 KB, text/plain)
2017-06-23 08:51 UTC, Anton Kochkov
Details
acpidump output (1015.41 KB, application/x-ns-proxy-autoconfig)
2017-06-25 13:29 UTC, Anton Kochkov
Details

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)

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