High CPU Usage - System/ACPI.sys - GPE.L6F Storm [Omen 15/17/Zbook 17 G5/Other HP Devices]

[MaPo31415]

Okey then, once you get on Linux and encounter the problem once more, please try running following command as root user (sudo su):

echo disable > /sys/firmware/acpi/interrupts/gpe6F

This disables gpe6F interrupt altogether - if that helps, then we have a culprit (and a workaround for you, If you happen to use GNU/Linux on a daily basis).

[Jay889]

It's been 2 days trying to catch the logs when the cpu usage go high. I only did add "pcie_aspm=off", and I'm pretty sure this won't affect windows (Correct me if I'm wrong, Take into consideration that i have dual boot). but since than till posting this reply the cpu on windows (System process) is back to normal. I even noticed sometimes it goes to 0% which It never went to 0 since I noticed the issue and started to monitor it.

Ignore it! I catch the logs, the cpu went back high out of random

[Jay889]

we have the same problem...

[MaPo31415]

Okay, we found a common denominator.

Please post your firmware codename and version.

Running "echo disable > /sys/firmware/acpi/interrupts/gpe6F" as root on linux should be a valid workaround on Linux, unfortunatelly there is no way to do that on NT Kernel.

I'm going to do some research on ACPI DSDT patching  on Windows to see whether it is possible to override this method.

[271828182845904]

Somehow my comment got deleted by some shady hand or the forum itself, so I repost it.

My notebook omen 15 ce-0xx (I guess that's how it's spelt the model name) has the same problem with acpi interrupt flood.

Under Linux I can workaround the problem by disabling or masking the interrupt 0x6f, so the kernel doesn't have high cpu usage anymore, but this seems to be impossible to do under Windows where there is little control of the system available to the end user.

Under Linux I can disable the General Purpose Event 0x6F flood by running as root

echo disable > /sys/firmware/acpi/interrupts/gpe6F

This can be done automatically each boot by creating a systemd service.

An alternative is to send a parameter to linux kernel to ignore the interrupt, by adding

acpi_mask_gpe=0x6f

to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

Under WIndows the only thing I can do it's the trick of "close the lid, wait and open the lid", or "suspend, wait, resume".

[MaPo31415]

Hi @271828182845904

Thanks a lot your your input, this adds weight to the issue! Please provide your firmware codename and version.

Currently 3 HP Laptops are affected by this issue (and many more PC mobos, the problem seemed to emerge in the Skylake era):

HP Omen 15

HP Omen 17

Zbook 17 G5

HP send me a PM initiating a standard support procedure, but that just proves that not a single line of this thread was read by them, and also proves lack of transparency - after all, my laptop is not the only affected, and other users would want to know why their pricey hardware is not working as it should. The problem is evident - botched Firmware - method _L6F to be exact, probably due to AE_NOT_FOUND or lack of appropriate handler (I'll install GNU/Linux with ACPI-debugging-enabled kernel to find out later, for now I'm going to dump my entire ACPI .aml and recompile it to see what errors I would stumble upon).

[MaPo31415]

I found something interesting - Is firmware image provided for the OS supposed to be outdated? (I have every driver up to date, firmware in version 01.07.01 Rev. A).

I know that properly implemented ACPI shouldn't rely on OS's binary blobs, but since we live in times when Remote Access embedded in CPUs is required for some seemingly unrelated drivers to work (I'm looking at you, Intel AMT and Connexant Audio Drivers), this image could include external methods our current DSDTs depend on. Hmm...

[271828182845904]

Model: OMEN by HP Laptop 15-ce0xx (website detects it as "15-ce003la")

Serial number: **bleep**

Product number: 1GX63LA#ABM

Firmware version: F.17

I know there is a newer F.19 firmware version, but since bios updates aren't a trivial process, I wanted to research more on input from other users installing this update to know if it leads to more problems than solutions before installing the update.

I have to say that this notebook came with an earlier bios version (I think it was F.16) and then the problem was already present, and updating to F.17, hoping to end with this issue, didn't solve it.

Do you need me to provide a DSDT and SSDT ACPI tables binary dump or decompiled dump?

[MaPo31415]

Great idea, we would be able to cross reference them - I'm gonna diff them and look into implementation of _L6F. Please also attach errors from decompilation. Decompilled versions would be enough.

I'm installing Ubuntu right now and then I'm going to increase verbosity of ACPI events in the kernel.

So far I managed to get these errors from dmesg that occurred during bootup:

[   11.311378] ACPI Error: AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5) (20181213/exoparg2-396)
[   11.311420]
               Initialized Local Variables for Method [GETP]:
[   11.311421]   Local0: 00000000e4f514ac            Integer 0000000000000003
[   11.311424] Initialized Arguments for Method [GETP]:  (2 arguments defined for method invocation)
[   11.311425]   Arg0:   0000000033dc4155            Integer 0000000000000005
[   11.311427]   Arg1:   0000000018ae9584            Integer 0000000000000003
[   11.311430] ACPI Error: Method parse/execution failed \_TZ.GETP, AE_AML_PACKAGE_LIMIT (20181213/psparse-531)
[   11.311460] ACPI Error: Method parse/execution failed \_TZ.CHGZ._CRT, AE_AML_PACKAGE_LIMIT (20181213/psparse-531)
[   11.313363] ACPI Error: AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5) (20181213/exoparg2-396)
[   11.313402]
               Initialized Local Variables for Method [GETP]:
[   11.313403]   Local0: 0000000018ae9584            Integer 0000000000000003
[   11.313406] Initialized Arguments for Method [GETP]:  (2 arguments defined for method invocation)
[   11.313406]   Arg0:   0000000033dc4155            Integer 0000000000000005
[   11.313408]   Arg1:   0000000053e09a17            Integer 0000000000000003
[   11.313412] ACPI Error: Method parse/execution failed \_TZ.GETP, AE_AML_PACKAGE_LIMIT (20181213/psparse-531)
[   11.313442] ACPI Error: Method parse/execution failed \_TZ.CHGZ._CRT, AE_AML_PACKAGE_LIMIT (20181213/psparse-531)
[   11.313476] [Firmware Bug]: No valid trip found

[271828182845904]

Here's the decompiled DSDT table and SSDT tables (20): https://drive.google.com/open?id=13nqQg9KcdHou6lJ08cQk5CarZhhMa3_O

Here's kernel boot log: https://drive.google.com/open?id=1oAae1q8xDfbVzcVRqNxE1WPUz5yQAJh9