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

[MaPo31415]

Actually, the problem is that method _L6F (part of ACPI, OS-hardware interface for handling hardware events, energy, low-level stuff in general) is either working properly (and is being respawned by some signal that's being generated ad nauseam, spontaneously, and in this case updated firmware for Embedded Controller is needed) or is not working properly (no handler in method is able, well, to handle the signal, or there is no generic handler to at least stop interrupts coming, in this case ACPI-part of BIOS needs to be updated). What are interrupts, you may ask - as you might know, deep under the mask there is motherboard with hundreds of connections. Interrupts are signals that are intercepted by processors to be handled immediately - even if it does a list of task it was given - that's by design, and that's okey, some thing must be able to be handled instant. The problem is when part A (Embedded Controller in this case) is storming CPU with these signals ad nauseam - usually in multi-core architecture, separate interrupt lines (described as IRQ number x) are distributed among cores, to distribute load caused by interrupts (in theory) - causing Core to be out of commission in our case, which in turn, similar to domino, causes other problems, such us ramped-up core clock frequencies. Think of Interrupts as signals for creating a top-priority process that continues unless Interrupt goes from high state to low state (level-triggered) or Interrupt keeps occurring (edge-triggered). In this case, method _L6F is level-triggered, thus either no functions are telling Embedded Controller "Hey pal, I handled your interrupt, would you be so kind to shut it off?" or there is no appropriate function in a first place, OR, Embedded Controller happens to be deaf to what Interrupt Handler says to him.

Now, for the sleep-wake. We managed to single-out some triggers for this issue - once method _L6F starts, it cannot stop. For me it was shutting of internal display (either by timeout or closing the lid) and some internal CPU values breaching predefined thresholds (in this case I overridden them with Throttlestop). I also noticed that it may occur if you start the laptop from power-off state. Technically, waking from hibernation is similiar to starting the laptop from powered-off state. It just loads a hibernation file with memory dump during boot-up of the OS, thus you're coming back where you left, but from the issue perspective, it is the same as starting from shutdown laptop. Also, your power plan may include transitioning from sleep to hibernation (180 minutes by default).

That said, once you stumble upon Interrupt Storm, please give it a try to put your laptop into sleep (not hibernation, that's crucial) - and wake it up, then take a peek at Task Manager. You cannot make things worse after all, and it may as well go away if you do that (temporally, in my case without custom Throttlestop settings, the issue reoccurs after 5-10 minutes, but we'll at least know that it's the same spice)

[Arv55]

I hibernated yesterday and resumed it today. The system process popped up again.

It happened exactly like you said. After I put it to sleep and resumed it, the CPU usage of system process went from 15% to 2%. I have recorded everything in screen capture. I could mail you if you want. I also tried that log-man thing but I didn't get any warnings. Should I try this only when the system process is running high? because I tried this after sleep.

[MaPo31415]

Hi Arv55!

"Should I try this only when the system process is running high?"

Yeah, this logman thingy logs ACPI warning and errors, and since interrupt storm went dormant after this sleep-wake trick, no errors are popping up in the log. So yeah, go ahead and log events just as storm starts blazing anew, a short sample would suffice, 10 seconds tops. It's just to confirm that it's the same ACPI Method though, I'm convinced that you're yet another victim of this firmware, not hardware issue. Also, I noticed that you reported heat issues back in March 2018. Well, the storm makes all of your cores go turbo at all times, no matter the load - go figure.

I've been reached out by another escalations officer, but it bothers me that they seem not to be able to well - escalate things per se. They told me to give HP Zbook and HP Omen teams a call. That's odd, why should customer ever do that? Is internal communication a thing of the past? Well, I'm waiting for alternative contact to reach these teams, as this issue requires analysis of data, which I'm not able to convey through my voice - besides, I'm pleading ad nauseam for ANYBODY at HP to pass this thread to the appropriate team inside HP. I'm sure they would make use of it, if it wasn't for sticking to the support script every company other than Apple seems to do nowadays. RMA is not a solution to every problem, and yet they always start with it, that's exactly why I avoid 1st line support - But I digress, I hope that finally somebody competent, with professional attitude, will pick up this case - after all, the reputation of Business and Gaming platforms is at stake.

[jncraton]

I wanted to report that I am experiencing this issue on my ZBook 17 G5 as well. Under Linux (Ubuntu 18.04), I can see a storm of gpe6F interrupts. I was able to work around the issue by masking these interrupts:

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

That does solve the CPU usage issue, but I'd prefer a proper fix.

[Arv55]

• I am in touch with hp about this issue. BTW, the user MaPo31415 is the Boss here 🙂 

[MaPo31415]

Hi Jncraton!

I'm glad to see more Zbook users coming out of hiding.

The best course of action for you would be to initiate an HP Support via HP Support Assistant. Provide assigned Support Agent a link to this thread, tell that person that this is a widespread firmware, not hardware issue that affects both HP Omen and HP Zbook, you're not the first reporting this, and nobody seems to be eager to tackle this inside HP.

Also, it wouldn't hurt if you created your own thread with a description of the problem. We have amassed a small network of people that have to deal with this problem - we need to force HP into acknowledging the existence of this widespread bug, by any means necessary. I really hope that we won't be forced to gain audience on social media, but it depends on how long HP decides to ghost us - to my knowledge, there are at least two HP Employees on this community that are aware of this problem, and a couple of local support teams in various countries that were informed about the issue and the existence of this thread.

Yesterday I was told by Executive Escalations officer that we will not be reached out on this forum by any HP Employee, because it is being handled internally (despite our good will). I can't tell whether this is a fact or yet another case of corporate BS, but we'll see.

[271828182845904]

I did the logman thing you suggested. I find something I didn't expect. The "warning" logs don't mention \_GPE._ L6F but the following ones:

"ACPI method \_SB.PCI0.B0D4._TMP has high frequency 31678." (something within "Intel(R) Dynamic Platform and Thermal Framework Processor Participant"?)

"ACPI method \_SB.GEN1._TMP has high frequency 20231."

"ACPI method \_SB.GEN2._TMP has high frequency 17993."

and less frequently:

"ACPI method \_SB.BAT0._BST has high frequency 3975." (battery status?)

"ACPI method \_SB.ADP1._PSR has high frequency 3974." (adapter?)

I don't know if I did it right or if at that time was at some heavy usage to trigger these ones. Under linux the issue was always GPE.L6F besides the logs from boot screen about some errors in acpi firmware.

(EDITED: added screenshot).

[MaPo31415]

No worries, these methods seem to accompany GPE.L6F, maybe you didn't stumble upon it due to sheer number of entries. If you stumbled upon it on Linux then that's it nonetheless.

[271828182845904]

I cleared the logfile and ran logman again just in case, and this time appeared a lot of GPE L6F events during a high cpu usage status due to ACPI.sys, so the previous case could be older logs less relevant and maybe could be ignored.

Examples of these new events:
[Info] "ACPI method \_GPE._L6F evaluation has started."

[Info] "ACPI method \_GPE._L6F evaluation has finished."

[Warn] "ACPI method \_GPE._L6F has high frequency 3586897."

[Arv55]

Like everyone I also got warnings in log-man (OMEN by HP - 15-ce003na).