Created attachment 254885 [details]
acpidump output

Created attachment 254887 [details]
dmidecode

Created attachment 254889 [details]
"lspci -vvnn" output

Created attachment 254891 [details]
Disassembled and recompiled dsdt

Created attachment 254893 [details]
Disassembled and recompiled dsdt

Created attachment 254895 [details]
Partially corrected DSDT.dsl

I spent some time to fix some of the warn/remarks in dsl file but after compiling and overriding it in grub behavior is the same.

This appears to be a firmware bug. Examining the method WMPV:

    Method (WMPV, 3, Serialized)
    {
        Local4 = WVPI (Arg0, Arg1, Arg2)
        Local0 = DerefOf (Local4 [Zero])
        Local3 = DerefOf (Local4 [One])
        If ((Local0 == Zero))
        {
            PVWS = 0x03
            GSWS (0x80F3)
            If ((PVWS == 0x03))
            {
                Local2 = HVWA ()
            }
            ElseIf ((PVWS == 0x05))
            {
                Local6 = HVWA ()
                If ((0x00010000 != DerefOf (Local6 [Zero])))
                {
                    Local2 = Local6
                }
            }
            Else
            {
                Local5 = Zero
                While (((PVWS == 0x04) && (Local5 < 0x8000)))
                {
                    Sleep (0x19)
                    PVWS = 0x03
                    GSWS (0x80F3)
                    Local5++
                }
            }
        }

        Local1 = WVPO (Local3, Local2)
        If ((Local0 == Zero))
        {
            WVCM ()
        }

        Return (Local1)
    }

There are several code paths through this method that do not initialize Local2. The method WVPO expects the second argument to be a package object, and uses it as such (Arg1). It appears that Local2 is not being initialized, and the default initial setting for all locals is an integer of value 0. When method WVPO attempts to use Local2 as a package, an AE_AML_OPERAND_TYPE results because Local2 is in fact an integer.

Here's the statement in WVPO that causes the exception:

    FRTC = DerefOf (Arg1 [Zero])

We could track this down with AML tracer.
Please enable CONFIG_ACPI_DEBUG, rebuild the kernel and boot the kernel with:

acpi.trace_method_name=_SB.WMIV.WMPV acpi.trace_state=opcode-once

After triggering this issue, upload the dmesg output here.

Thanks in advance.

Thanks guys that was really quick :-). I will follow Lv Zheng advice and post results. This machine is preatty useless as laptop with current acpi problems. Do you think it makes sense to submit ticket to HP so that they release bios update or I'm doomed to use overriden dsdt?

(In reply to Mateusz from comment #9)
> Thanks guys that was really quick :-). I will follow Lv Zheng advice and
> post results.

Just to obtain the proofs of Bob's analysis.

> This machine is preatty useless as laptop with current acpi
> problems. Do you think it makes sense to submit ticket to HP so that they
> release bios update or I'm doomed to use overriden dsdt?

Yes, HP need to be aware of aware of their firmware issues.

I think it is sufficient to say that this is a buggy BIOS, and we will not continue debugging this issue unless the firmware bug has been fixed.

Bug closed, and please raise the problem to HP.