Contribute
Register

kernel_task using high % of CPU, probably caused by GPE ACPI interrupt

Status
Not open for further replies.

efj

Joined
Nov 26, 2012
Messages
7
Motherboard
Dell XPS 13" 7390
CPU
i7-10510U
Graphics
UHD 620, 3840x2160 touch screen
Hey everyone!

I am reaching out here because my built would be absolutely brilliant (everything is working flawlessly), if it wasn't for one annoying detail: kernel_task is using 70% of CPU constantly, causing the fans to run at their max speed and ... battery to drain way too fast.

The current assumption is that an GPE ACPI interrupt 6F is being handled non stop. This relates probably to Thunderbolt on the machine.
The reason behind this assumption lies in the fact that the very same problem could be observed when running Linux, and fully disappeared after executing the following command:

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

I am saying this is an assumption as I could never confirm it anywhere in macOS (while checking the logs). It was quite obvious in the syslog in Linux.

I did publish all details related to the machine I am working on, over here: https://github.com/ericfjosne/Dell-XPS-7390-Opencore

I now am trying a different EFI that already has some things set up to go around the problem, but not successfully: https://github.com/sambow23/Dell-XPS-13-7390-macOS/tree/main/Monterey - Experimental/

When looking at how things were done in sambow23's EFI, it seems to be ok and all devices references seem to be the correct ones (see attached screenshot).

My questions are the following:
- Is there any way (log file, audit tool, anything) to locate the root cause of this high kernel_task CPU usage?
- I thought about removing purely the Method(_L6F) from the DSDT by patching it ... but I believe this is not the "opencore" way of doing things? Is this even a possibility? Also, I understand that it is best to prevent the interrupt to happen in the first place, but considering the workaround explained here did not work ... is this a good approach to mitigate things?
- What would be a good way forward to investigate and solve this?

Any help would be greatly appreciated.

Please let me know if there is any missing information here, I will happily provide it :)

Thanks in advance,

Eric
 

Attachments

  • Screenshot_2022-07-30_at_11.07.22.png
    Screenshot_2022-07-30_at_11.07.22.png
    1 MB · Views: 38
Hey everyone!

I am reaching out here because my built would be absolutely brilliant (everything is working flawlessly), if it wasn't for one annoying detail: kernel_task is using 70% of CPU constantly, causing the fans to run at their max speed and ... battery to drain way too fast.

The current assumption is that an GPE ACPI interrupt 6F is being handled non stop. This relates probably to Thunderbolt on the machine.
The reason behind this assumption lies in the fact that the very same problem could be observed when running Linux, and fully disappeared after executing the following command:

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

I am saying this is an assumption as I could never confirm it anywhere in macOS (while checking the logs). It was quite obvious in the syslog in Linux.

I did publish all details related to the machine I am working on, over here: https://github.com/ericfjosne/Dell-XPS-7390-Opencore

I now am trying a different EFI that already has some things set up to go around the problem, but not successfully: https://github.com/sambow23/Dell-XPS-13-7390-macOS/tree/main/Monterey - Experimental/

When looking at how things were done in sambow23's EFI, it seems to be ok and all devices references seem to be the correct ones (see attached screenshot).

My questions are the following:
- Is there any way (log file, audit tool, anything) to locate the root cause of this high kernel_task CPU usage?
- I thought about removing purely the Method(_L6F) from the DSDT by patching it ... but I believe this is not the "opencore" way of doing things? Is this even a possibility? Also, I understand that it is best to prevent the interrupt to happen in the first place, but considering the workaround explained here did not work ... is this a good approach to mitigate things?
- What would be a good way forward to investigate and solve this?

Any help would be greatly appreciated.

Please let me know if there is any missing information here, I will happily provide it :)

Thanks in advance,

Eric
please read the faq for proper hardware profile setup:
 
please read the faq for proper hardware profile setup:
Done. The machine that was described on my profile dates back to 2012 (ga-z77x-up5 th, i7-3770k, RX570 4Gb 4K) ... and I am still using it daily actually :) Hopefully, it can retire soon if I can get around the issue described here on my new laptop.

I noted there was a forum dedicated to DSDT and SSTD questions (it wasn't showing up on the device I posted this thread from originally). Maybe this would be a better location?
 
Done. The machine that was described on my profile dates back to 2012 (ga-z77x-up5 th, i7-3770k, RX570 4Gb 4K) ... and I am still using it daily actually :) Hopefully, it can retire soon if I can get around the issue described here on my new laptop.

I noted there was a forum dedicated to DSDT and SSTD questions (it wasn't showing up on the device I posted this thread from originally). Maybe this would be a better location?
no, as this is laptop support

also no problem reporting files attached
 
Hey everyone!

I am reaching out here because my built would be absolutely brilliant (everything is working flawlessly), if it wasn't for one annoying detail: kernel_task is using 70% of CPU constantly, causing the fans to run at their max speed and ... battery to drain way too fast.

The current assumption is that an GPE ACPI interrupt 6F is being handled non stop. This relates probably to Thunderbolt on the machine.
The reason behind this assumption lies in the fact that the very same problem could be observed when running Linux, and fully disappeared after executing the following command:

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

I am saying this is an assumption as I could never confirm it anywhere in macOS (while checking the logs). It was quite obvious in the syslog in Linux.

I did publish all details related to the machine I am working on, over here: https://github.com/ericfjosne/Dell-XPS-7390-Opencore

I now am trying a different EFI that already has some things set up to go around the problem, but not successfully: https://github.com/sambow23/Dell-XPS-13-7390-macOS/tree/main/Monterey - Experimental/

When looking at how things were done in sambow23's EFI, it seems to be ok and all devices references seem to be the correct ones (see attached screenshot).

My questions are the following:
- Is there any way (log file, audit tool, anything) to locate the root cause of this high kernel_task CPU usage?
- I thought about removing purely the Method(_L6F) from the DSDT by patching it ... but I believe this is not the "opencore" way of doing things? Is this even a possibility? Also, I understand that it is best to prevent the interrupt to happen in the first place, but considering the workaround explained here did not work ... is this a good approach to mitigate things?
- What would be a good way forward to investigate and solve this?

Any help would be greatly appreciated.

Please let me know if there is any missing information here, I will happily provide it :)

Thanks in advance,

Eric
Were you ever able to resolve this with Monterey ?
 
Were you ever able to resolve this with Monterey ?
Unfortunately, no. I seeked help from the community (here and opencore discord chat), as I have hit the limits of my knowledge here, but so far I unfortunately haven’t received any response or hint on how to debug this further
 
Unfortunately, no. I seeked help from the community (here and opencore discord chat), as I have hit the limits of my knowledge here, but so far I unfortunately haven’t received any response or hint on how to debug this further
I will keep digging around myself but I purchased the EFI for Monterey for the XPS 13 7390 from hackintosh expert and its the same as yours, runs flawlessly minus the fans running at 100% and the kernel_task issue. I had high hopes for that. Do you know if Big Sur has this issue as well or does it run perfectly ?
 
Unfortunately, no. I seeked help from the community (here and opencore discord chat), as I have hit the limits of my knowledge here, but so far I unfortunately haven’t received any response or hint on how to debug this further
as you still haven't uploaded any files, no one can really help
 
Ok here is my report files, let me know if you need anything else.
 

Attachments

  • tonymacx86_report_files.zip
    6.6 MB · Views: 42
Status
Not open for further replies.
Back
Top