runaway ACPI interrupt/kworker cpu hog

I have a 2008 macbook that I recently installed manjaro and arch on. On both installs I have been experiencing random cpu load (40-50% steady) with resultant heat buildup and fans spinning. Doing a bit of looking around I noted that I have an ACPI interrupt that is the apparent cause.

Typing in grep . -r /sys/firmware/acpi/interrupts/gpe* I get the following (truncated a bit but you get the idea):

/sys/firmware/acpi/interrupts/gpe3B: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe3C: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe3D: 0 STS invalid unmasked
/sys/firmware/acpi/interrupts/gpe3E: 0 EN enabled unmasked
/sys/firmware/acpi/interrupts/gpe3F: 141018 EN enabled unmasked
/sys/firmware/acpi/interrupts/gpe40: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe41: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe42: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe43: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe44: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe45: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe46: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe47: 0 STS invalid unmasked
/sys/firmware/acpi/interrupts/gpe48: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe49: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4A: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4B: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4C: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4D: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4E: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe4F: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe50: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe51: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe52: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe53: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe54: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe55: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe56: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe57: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe58: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe59: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe5A: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe5B: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe5C: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe5D: 0 STS invalid unmasked
/sys/firmware/acpi/interrupts/gpe5E: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe5F: 0 invalid unmasked
/sys/firmware/acpi/interrupts/gpe_all: 141018

Sometimes gpe3F has been spotted at over 250k and rising! Is there a fix for this, or is it just a product of using an 11 year old core2duo? Appreciate any help, thx!

Try adding acpi_osi=!Darwin to the boot kernel parameter.

1 Like

I'll give it a whirl thx.

To be sure I have it right, insert that into /etc/defaults/grub and then grub-update?

If I do the same in my arch install, do I then go back to manjaro and grub-update from there? I use manjaro's grub due to the issues getting anyone else's to work with manjaro...

Well, i would test it first by adding it from boot grub menu by editing it, and if works then add it to GRUB_CMDLINE_LINUX_DEFAULT line in /etc/defaults/grub ...

1 Like

I should have mentioned I would do that first. I jumped straight to making it permanent.

So far I think you've got it! Absolutely amazing help - seems everyone on the interwebs, including myself, was looking to disable the interrupt as opposed to avoiding the error in the first place. Been running for about 30 minute with 0 errors.

1 Like

ok my only remaining problem is how to make this permanent for the arch install. Arch doesn't have a /etc/default/grub file, and i wouldn't expect running update-grub in manjaro to reference that file. I don't have to edit the grub.cfg file in boot do i?

When you installed Arch, you did not installed the Grub boot loader for it, but using the one installed in Manjaro. There is nothing else to do then, just boot in Arch from Manjaro's Grub.

True - but the acpi parameter we put into etc/default/grub would not be passed on when booting arch would it? I thought I may need to edit one of the files in etc/grub.d to get it to work.

As it turns out, it doesn’t seem to work with the arch kernel, which is currently at v5 on this machine. I added the line manually at the grub menu when booting. Don’t know if the parameter was deprecated in the latest kernel or not.

@bogdancovaciu Any reason we prefer killing Darwin entirely instead of disabling gpe3F ?
Ex:
sudo echo "disable" > /sys/firmware/acpi/interrupts/gpe3F
https://askubuntu.com/questions/176565/why-does-kworker-cpu-usage-get-so-high

I didn’t think that his instruction was killing Darwin but rather telling acpi that this was a Darwin based bios?

Most posts I’ve seen regarding this problem seem to advise to just disable the offending register as you suggest but I was not certain that’s a good idea.

I thought it was more like

by appending acpi_osi=!Darwin in command
line, thus Apple hardware regards it as an incompatible OS X system,
hence turns off the Thunderbolt.

Some Mac models will have abnormal and hidden load with the gpe* disabled. With the Darwin thing, AFAIK, is telling to ACPI that this is not macOS (and that part is correct because is linux). Also, as i mentioned previously, i would have made the test from GRUB first, so was the shortest and quicker test to make :slight_smile:

I did the grub test first. It worked and then made it permanent.

Now the battery monitor is not working in i3. Guess that's an unintended side effect that could cause problems in the future since the battery is only good for 1 1/2 hours or so. Macs are a pain in the ass.

Interesting follow-up. I couldn't get the acpi_osi=!Darwin to do anything with my arch install, although it did work with manjaro. I started trying different options in both, and think the problem is that this command does nothing with kernel version >5. Upgrading manjaro to 5.05 broke the command, and downgrading back to 4.19 made it work again. So the parameter might be deprecated in 5.x kernels.

And what real advantage is to run the 5 kernel on that machine ? :slight_smile:

Nothing. At All. One of the problems with arch installation is it defaults to the latest and greatest. In 20 years of using linux I've never had a holy s**t moment with a kernel update. LTS is my middle name.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by