Bug 198051

Created attachment 260971 [details]
Output of commands

Created attachment 260973 [details]
Compressed decoded acpidump files

I think I assigned this to the wrong  Component

We've seen code like this before and it has to do with the firmware. RHUB.HS11 is being declared as a device object in a firmware table called the DSDT based on some conditional expression like so:

if (Expr)
{
    Device (HS11){...}
}

This means that HS11 is created only when Expr evaluates to true.
The scope operator opens the scope of a device (like HS11). In the SSDT4 firmware table, the ASL opens a scope under HS11 without any conditional expression:

Scope (HS11){...}

The message you see is a result of the Expr evaluating to 0 and failing to create HS11. By the time Scope (HS11) {.. is executed, the linux ACPI interpreter returns an error saying that this object does not exist.

Is this something I need to worry about or maybe I should ask can it be fixed?

It could be some sort of BIOS option that could fix this but other than that, you may want to talk to the firmware vendor to see if they have newer firmware.

Actually, this could be an issue with module-level code. We are in the process of fixing this. Linking to this bug https://bugs.acpica.org/show_bug.cgi?id=963
As of now, we execute if statements at the root scope after all tables have been loaded. So this code

if (Expr)
{
    Device (HS11){...}
}

gets executed after

Scope (HS11){...}

We are working on changing the order so that the the if statements get executed in the correct order. If we have the correct order of execution and Expr evaluates to a non-zero value, Device HS11 will be declared and fix this error:

[    0.000000] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170831/dswload-210)

Is there a way to test AcpiGbl_ParseTableAsTermList enabled?

Created attachment 273793 [details]
Patch to enable parse_table_as_term_list

Created attachment 273799 [details]
Dmesg with Patch

So I'd say that's an improvement but there's still a lot of these type of messages:

[    0.021138] ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
[    0.021151] ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
[    0.021162] ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
[    0.021174] ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)

I was also hoping these ACPI errors might have been related to why my USB-C connector doesn't work under Linux

Hi Mike,

We are currently working on a fix for this issue. I'm going to mark this as a duplicate and you can track the issue here: https://bugs.acpica.org/show_bug.cgi?id=963