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

[MaPo31415]

Hi, after a quick glimpse I noticed that our files are very different - despite that we're both dealing with L6F storm - this leads me to believe that L6F itself is not at fault, but rather something that spawns this General Event ad nauseam - and that would be an embedded controller AFAIR. Still, this is related to the firmware provided by HP. I'm going to do some further research on that.

[Jay889]

I'm on the latest bios and i still have the issue,

I actually tried every bios available for my model and still the same.

System Model:

OMEN X by HP Laptop 17-ap0xx

Operating system:

Windows 10 Enterprise 64-bit

Microprocessor:

Intel(R) Core(TM) i7-7820HK CPU @ 2.90GHz

System memory:

32GB

Memory slot 1:

16GB Kingston 2400MHz

Memory slot 2:

16GB A-Data 2400MHz

System board:

83A5 54.33

System BIOS:

F.21

[MaPo31415]

My suspicion around Embedded Controller feeding gpeL6E (Level-Activated Event to be handled by OS/ACPI) and perceived events with high frequency from EC0 just before L6F storm gave me an idea - I disabled Intel DPTF in the BIOS and set my own limits via Intel XTU on Windows / intel-undervolt on Linux (undervolted by offset -140mV, disabled short term turbo boost, package wattage for Turbo Boost limited to my nomial TDP, time window reduced to 1 second, these setting are optimal for my rig). So far I haven't perceive any storm on idle on any OSs - it is too soon to junp into conclusion, this needs further testing with multiple reboots.

However, I noticed that L6F storm starts on Ubuntu, if I enable blanking monitor after x minutes. As soon as DPMS kicks in, disabling the display, the storm unleashes. This gives me a general idea of the bigger picture, but for now I'm going to keep it to myself. And for the record, on windows I'm not using automatic turning off of the display.

[MaPo31415]

Also, I noticed that implementation of _L6F in my firmware, which I believe queries all devices on PCI-E bus whether they're able to handle the event (CondRefOf device), seems to be missing a branch that resets pin 6F if no handler was found, thus leading to infinite loop, since this method is level activated rather than activated by rising edge. I might be wrong, ACPI is very complicated, but it kinda makes sense. 

What I'm doing right now is trying to determine what can be done to avoid creating 6F event in a first place since it is easier, rather than modifying the method itself (it would require DSDT patching). If my sysops's intuition is working properly, one of routines that fires 6F is DFTP, while the other is DPMS. I'll come back with results of my tests tomorrow.

[MaPo31415]

I think that we're having a breakthrough, I left my laptop on through the night, and once I woke up, for the first time ever, there was no 6F storm eating up my Core! I'll test this further on both OSs, trying to measure impact of DPTF/DPMS and oce we're done here, we'll focus on HP Omens.

Speaking of which - colleagues, If you noticed any correlation between any of the system event other than Laptop being idle for 5-10 minutes and monitor blanking, and start of the storm, let me know - this way we'll be able to cover all bases in our attempt to avoid spawning unhandleable L6F in the first place. Also please provide me with ACPI .etl logs that would cover transition to the 6F storm, as well as timestamps of it starting.

@HP if you need any diagnostics or dumps in order to analyze this problem in any of the scenarios, just say so, I'll be happy to deliver.

Also, since I had to disable DPTF for my PC to work properly, something that's supposed to handle energy and thermals, and set limits on my own, perhaps its botched integration with firmware that causes these high CPU temperatures HP Omen users are reporting on this Community EACH DAY. You're welcome, all you have to do is just to fix it.

[Jay889]

Sometimes i have the problem while doing light stuff such browsing the web or watching youtube.

Once i finished a game and checked the task manager, the storm was there. ( I can't confirm that now because i have no time for gaming )

I noticed that after several restarts the cpu usage go back to normal till i shut down the system.

The issue is weird, but it is related to BIOS 100% and not hardware.

@HP it's been long time and there's no official statement from HP. I guess they will not cover this issue

[MaPo31415]

Allegedly this issue has been escalated to the product support team, perhaps fixes will introduced in a new version of our firmware (Q70, F.19, F.21).

[271828182845904]

I'm not sure about installing F.19. I've found this in the forum:

https://h30434.www3.hp.com/t5/Gaming-Notebooks/Omen-15-BIOS-F-19-Rev-A-issues/td-p/7134476

[MaPo31415]

Oh, I thought that F.19 is a family of Firmware, not a particular version.

Speaking of Thermals - I've overridden default PL1 and PL2 limit with ThrottleStop and locked it, because in my case it was 23W (lower that nominal TDP of the CPU with Turbo Boost disabled, lol) - Another proof that firmware is seriously messed up. Actually, I isolated PL1 being lower than TDP to be one of the triggers of L6F. I noticed that if you start the laptop from complete shutdown, sometimes it is able to override my lock and impose 23W PL1 back, causing OS to be vulnerable to the storm.

In my case the startup pattern that ensures stability is: power up, lock PL1 in throttle stop to my desired level, sleep and wake to clear other ACPI routines, lock PL1 again. Then I need to enable PL1 lock each time I resume from sleep.

[Christoph_W]

I have the same issue with my Zbook G5 17. 

Modell: HP ZBook 17 G5

Product-ID: 2ZC46EA#ABY

Bios-Date: 04/15/2019

Bios-Revision: Q70 Ver. 01.07.00

Windows Version: 1903

Processor: Intel(R) Xeon(R) E-2186M CPU @ 2.90GHz

Memory: 2x16GB Hyundai

SSD 1: KXG50ZNV512G TOSHIBA 512GB

SSD 2: Samsung SSD 970 PRO 1TB

From HP Support I've got a lot of instructions, but nothing lower down the ACPI.sys process usage. I have a usage about 10% from the ACPI.sys! That's annoying.