Please post the acpidump for this machine, thanks.

Created attachment 255169 [details]
acpidump

I don't see where WMPV is being called from anywhere within the static ACPI tables, nor is it called from Linux.

Perhaps it is in a dynamically loaded SSDT (via Load operator).

$ grep -n WMPV *.dsl
dsdt.dsl:3728:        Method (WMPV, 3, Serialized)

$ grep -n Load *.dsl
ssdt13.dsl:266:                    Load (CST0, HC0) /* \_PR_.CPU0.HC0_ */
ssdt13.dsl:274:                Load (IST0, HI0) /* \_PR_.CPU0.HI0_ */
ssdt13.dsl:285:                        Load (HWP0, HW0) /* \_PR_.CPU0.HW0_ */
ssdt13.dsl:289:                            Load (HWPL, HW2) /* \_PR_.CPU0.HW2_ */
ssdt13.dsl:376:                Load (CST1, HC1) /* \_PR_.CPU1.HC1_ */
ssdt13.dsl:386:                Load (IST1, HI1) /* \_PR_.CPU1.HI1_ */
ssdt13.dsl:398:                    Load (HWP1, HW1) /* \_PR_.CPU1.HW1_ */

I think there is a way to grab the dynamically loaded SSDTs on Linux, but I don't know how to do it.

Anyway, it looks like somewhere, WMPV is being called with an incorrect argument, and the runtime typechecking is catching it.

> I don't see where WMPV is being called from anywhere within the static ACPI
> tables, nor is it called from Linux.

WMPV should have been invoked by OS WMI driver.

> Anyway, it looks like somewhere, WMPV is being called with an incorrect
> argument, and the runtime typechecking is catching it.

Is the typechecking wrong?
Is the OS invocation itself wrong?

Please ask WMI driver maintainers first.
It's maintained in platform specific driver category.

Thanks
Lv

It looks like there is another issue in the DSDT:

ACPI Warning: Unsupported module-level executable opcode 0x70
at table offset 0xC655 (20170303/psloop-347)

Here is the code that causes the warning:

    Name (GF17, Zero)
    GF17 = \_SB.GGOV (0x02050011)

The code is at module level, and the assignment to GF17 is a Store() operation (opcode 0x70).

After some more analysis, this is starting to look like some kind of bug in the ASL, or even possibly a hardware issue.

The bottom line is that the code ends up attempting to take an Index() on an Integer, which is in fact illegal.


Attempt to trace the sequence below.


It looks like the interface to WMPV is:
Arg0 - Integer
Arg1 - Integer
Arg2 - Buffer

        Method (WMPV, 3, Serialized)
        {
/* return from WVPI is a package */

            Local4 = WVPI (Arg0, Arg1, Arg2)
            Local0 = DerefOf (Local4 [Zero])
            Local3 = DerefOf (Local4 [One])


            Local1 = WVPO (Local3, Local2)


        Method (WVPI, 3, Serialized)
        {
/* There is a path through WPVI where return value is a package {0, 1} */

            Local1 = Package (0x02)
                {
                    Zero, 
                    Zero
                }

            If ((FDAS > 0x1060))
            {
                RTCD = 0x05
                Local1 [Zero] = One
            }
            Else
            {
            }
            Return (Local1)
        }

Interface to WVPO is:
Arg0 - Integer
Arg1 - Package with 2 elements, returned from WVPI

        Method (WVPO, 2, Serialized)
        {

            If ((ObjectType (Arg1) == Zero))
            {
                FRTC = RTCD /* \RTCD */
                Local0 = DASO /* \DASO */
            }
            Else
            {
                FRTC = DerefOf (Arg1 [Zero]) /* ERROR HERE */

Here, Arg1 is not a package, it is an integer, apparently incorrectly returned from WPVI

This causes the runtime error, because Index() is not allowed on an integer.



ACPI Error: Needed [Buffer/String/Package], found [Integer] 00555DA0 (20170303/exresop-724)
ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20170303/dswexec-608)
[AcpiExec] Exception AE_AML_OPERAND_TYPE during execution of method [WVPO] Opcode [Index] @34
[WVPO] @00031 #0088:  Index (Arg1, Zero)

(In reply to Robert Moore from comment #7)
> It looks like there is another issue in the DSDT:
> 
> ACPI Warning: Unsupported module-level executable opcode 0x70
> at table offset 0xC655 (20170303/psloop-347)
> 
> Here is the code that causes the warning:
> 
>     Name (GF17, Zero)
>     GF17 = \_SB.GGOV (0x02050011)
> 
> The code is at module level, and the assignment to GF17 is a Store()
> operation (opcode 0x70).

This is trivial, and is not related to this bug.
This issue can be fixed after we enable acpi_gbl_parse_table_as_term_list.

(In reply to Robert Moore from comment #8)
> After some more analysis, this is starting to look like some kind of bug in
> the ASL, or even possibly a hardware issue.
> 
> The bottom line is that the code ends up attempting to take an Index() on an
> Integer, which is in fact illegal.
> 
> 
> Attempt to trace the sequence below.
> 
> 
> It looks like the interface to WMPV is:
> Arg0 - Integer
> Arg1 - Integer
> Arg2 - Buffer
> 
>         Method (WMPV, 3, Serialized)
>         {
> /* return from WVPI is a package */
> 
>             Local4 = WVPI (Arg0, Arg1, Arg2)
>             Local0 = DerefOf (Local4 [Zero])
>             Local3 = DerefOf (Local4 [One])
> 
> 
>             Local1 = WVPO (Local3, Local2)
> 
> 
>         Method (WVPI, 3, Serialized)
>         {
> /* There is a path through WPVI where return value is a package {0, 1} */
> 
>             Local1 = Package (0x02)
>                 {
>                     Zero, 
>                     Zero
>                 }
> 
>             If ((FDAS > 0x1060))
>             {
>                 RTCD = 0x05
>                 Local1 [Zero] = One
>             }
>             Else
>             {
>             }
>             Return (Local1)
>         }
> 
> Interface to WVPO is:
> Arg0 - Integer
> Arg1 - Package with 2 elements, returned from WVPI
> 
>         Method (WVPO, 2, Serialized)
>         {
> 
>             If ((ObjectType (Arg1) == Zero))
>             {
>                 FRTC = RTCD /* \RTCD */
>                 Local0 = DASO /* \DASO */
>             }
>             Else
>             {
>                 FRTC = DerefOf (Arg1 [Zero]) /* ERROR HERE */
> 
> Here, Arg1 is not a package, it is an integer, apparently incorrectly
> returned from WPVI
> 
> This causes the runtime error, because Index() is not allowed on an integer.
> 
> 
> 
> ACPI Error: Needed [Buffer/String/Package], found [Integer] 00555DA0
> (20170303/exresop-724)
> ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Index]
> (20170303/dswexec-608)
> [AcpiExec] Exception AE_AML_OPERAND_TYPE during execution of method [WVPO]
> Opcode [Index] @34
> [WVPO] @00031 #0088:  Index (Arg1, Zero)

So this is a BIOS bug and we can move it to that category.

Thanks
Lv

Yes, a BIOS bug.

Could be exposed due to some hardware issue that forces a different code path through the ASL.

I'm seeing the same error messages with HP EliteBook 820 G4.  I tracked them down to CONFIG_HP_WMI (drivers/platform/x86/hp-wmi.c).

So fair enough, the driver may be triggering a BIOS bug, but I guess it's really an indication that HP has changed their APIs and the driver needs to be updated. For all intents and purposes, the driver does not work *at all* on these new HP laptops right now (kernel 4.11).

Andreas, which special keys [do not] work on your system?  I'm particularly interested to hear about Wifi, Volume mute, and Microphone mute (both keys and lights).

Microphone mute (Fn+f10) doens't work here. Volume mute and Wifi/BT hardware switch (two extra keys above keyboard) seem to work well. Nothing in the log when hitting "Mute" or "Mic mute" but Wifi switch gives:


Jun 23 20:08:03 laptop64 kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
Jun 23 20:08:03 laptop64 kernel: atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
Jun 23 20:08:03 laptop64 systemd[1]: Starting Load/Save RF Kill Switch Status...
Jun 23 20:08:03 laptop64 systemd[1]: Started Load/Save RF Kill Switch Status.
Jun 23 20:08:03 laptop64 kernel: wlp2s0: deauthenticating from c4:6e:1f:ea:da:f9 by local choice (Reason: 3=DEAUTH_LEAVING)
Jun 23 20:08:03 laptop64 kernel: iwlwifi 0000:02:00.0: Failed to find station
Jun 23 20:08:03 laptop64 kernel: wlp2s0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-22)
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Interface wlp2s0.IPv6 no longer relevant for mDNS.
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Leaving mDNS multicast group on interface wlp2s0.IPv6 with address 2a02:8109:953f:ed90:7eb0:c2ff:fe33:946f.
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Interface wlp2s0.IPv4 no longer relevant for mDNS.
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Leaving mDNS multicast group on interface wlp2s0.IPv4 with address 192.168.1.110.
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Withdrawing address record for 2a02:8109:953f:ed90:7eb0:c2ff:fe33:946f on wlp2s0.
Jun 23 20:08:03 laptop64 avahi-daemon[268]: Withdrawing address record for 192.168.1.110 on wlp2s0.
Jun 23 20:08:04 laptop64 kernel: atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
Jun 23 20:08:04 laptop64 kernel: atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.

Its functionality seems to work though. I hope this helps.

Let's re-assign this bug to hp-wmi maintainers.
Feel free to re-open it under platform specific hardware.