The kworker/0:x thingies are overwhelming my CPU's first core

EDIT TO MAKE THE SOLUTION CLEARER:

Go to this website Temporary fix for ACPI (GPE iinterrupts) failure , disable GPE6f interrupts, probably motherboard faulty ACPI implementation (reflash/update BIOS) [[!!You should take action!!]]. Install this in /usr/lib/systemd/system and run systemctl enable disable_gpe6F · GitHub and create the empty file in the directory indicated, giving it the name disable_gpe6F.service.
When you are done, open the Konsole and pastesystemctl enable disable_gpe6F.
IF your problem is the same as mine THEN you are DONE.

Please first read the post and the user’s “Solution” for a proper diagnosys.


I don’t really got much to say.

On this machine, Core_1 (out of 4) gets hammered by kworker/0:0, kworker/0:1, kworker/0:3 (and their varians with stuff like +kacpid written after the last number) even when just booted, in an idle state.



I google’d to hope to find some kind of fix, but I didn’t get lucky.
I tried editing Grub settings with the acpi_mask_gpe=0x06 that I kept seeing, but nothing.
I tried changing ACPI settings in the BIOS and whatever, and that too did nothing.

I am VERY LUCKY that I don’t need this PC at all for now, but the lack of BOTH information online and thus also easy fixes described in easy guides is very irritating.

Could anyone please link as much info as they can about this issue, and also a fix please?
I am willing to re-try even the same stuff to better document it, because DAMN there’s NOTHING online!

:~$ inxi -Fzxx
System:
  Kernel: 6.19.10-200.fc43.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 15.2.1
  Desktop: KDE Plasma v: 6.6.3 tk: Qt v: N/A wm: kwin_wayland dm: SDDM
    Distro: Fedora Linux 43 (KDE Plasma Desktop Edition)
Machine:
  Type: Desktop Mobo: ASRock model: H170 Pro4S serial: <superuser required>
    Firmware: UEFI vendor: American Megatrends v: P1.80 date: 01/22/2016
CPU:
  Info: quad core model: Intel Core i5-6400 bits: 64 type: MCP arch: Skylake-S
    rev: 3 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
  Speed (MHz): avg: 3300 min/max: 800/3300 cores: 1: 3300 2: 3300 3: 3300
    4: 3300 bogomips: 21599
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2070] vendor: ZOTAC driver: nvidia
    v: 580.126.18 arch: Turing pcie: speed: 2.5 GT/s lanes: 16 ports:
    active: HDMI-A-1 empty: DP-1, DP-2, DP-3, DVI-D-1 bus-ID: 01:00.0
    chip-ID: 10de:1f02
  Display: wayland server: Xwayland v: 24.1.9 compositor: kwin_wayland
    driver: gpu: nv_platform,nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: HDMI-A-1 model: Panasonic Panasonic-TV res: 3840x2160 hz: 60
    dpi: 104 diag: 1084mm (42.7")
  API: EGL v: 1.5 platforms: device: 0 drv: nvidia device: 2 drv: swrast
    gbm: drv: nvidia surfaceless: drv: nvidia wayland: drv: nvidia x11:
    drv: nvidia inactive: device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 580.126.18
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
    display-ID: :0.0
  API: Vulkan v: 1.4.341 surfaces: N/A device: 0 type: discrete-gpu
    driver: nvidia device-ID: 10de:1f02 device: 1 type: cpu
    driver: mesa llvmpipe device-ID: 10005:0000
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-settings,nvidia-smi
    wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170
  Device-2: NVIDIA TU106 High Definition Audio vendor: ZOTAC
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 10de:10f9
  API: ALSA v: k6.19.10-200.fc43.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.4.11 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin
Network:
  Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: kernel
    port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15b8
  IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 1.58 TiB used: 278.48 GiB (17.2%)
  ID-1: /dev/sda vendor: Samsung model: SSD 870 EVO 500GB size: 465.76 GiB
    speed: 6.0 Gb/s serial: <filter>
  ID-2: /dev/sdb vendor: Seagate model: ST1000DM003-1CH162 size: 931.51 GiB
    speed: 6.0 Gb/s serial: <filter>
  ID-3: /dev/sdc vendor: Kingston model: SA400S37240G size: 223.57 GiB
    speed: 6.0 Gb/s serial: <filter>
Partition:
  ID-1: / size: 29.25 GiB used: 22.17 GiB (75.8%) fs: btrfs dev: /dev/sdc4
  ID-2: /boot size: 1.9 GiB used: 653.6 MiB (33.6%) fs: ext4 dev: /dev/sdc3
  ID-3: /boot/efi size: 598.8 MiB used: 19.3 MiB (3.2%) fs: vfat
    dev: /dev/sdc1
  ID-4: /home size: 29.25 GiB used: 22.17 GiB (75.8%) fs: btrfs
    dev: /dev/sdc4
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
  ID-2: swap-2 type: partition size: 3.83 GiB used: 0 KiB (0.0%)
    priority: -1 dev: /dev/sdc2
Sensors:
  System Temperatures: cpu: 40.0 C pch: 35.0 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 16 GiB available: 15.54 GiB used: 5.42 GiB (34.9%)
  Processes: 338 Power: uptime: 14m wakeups: 0 Init: systemd v: 258
    default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm pm: flatpak pkgs: 15
    Compilers: gcc: 15.2.1 Shell: Bash v: 5.3.0 running-in: konsole inxi: 3.3.40

Also I’m switching PC for now to use the TV with YouTube (I am not burning my CPU to watch memes), and if that one also has the same issue I’ll just write another message below here…

Ok, the other (GT 1030 pc with a I5-3470) doesn’t have this issue, but I also forgot to say this:

The “i5-6400 PC” was also dropping the wireless M&K combo constantly.
It may be because of the problem, rather than the contrary.

Windows 10 (dual booting) on the same PC doesn’t seem to have the issue, in fact it even has more performance in games (altho Helldivers 2 has an “inverted render distance bug” on both of these PCs, both on W10 and Fkde, on W10 the i5-6400 PC reaches 60fps, while on Linux is fights to reach 40).

I have to assume you meant mouse & keyboard but that is far from clear.

Please make your comments 100% clear and do not use shortcuts similar to what may be used for text messaging. There are many users here, and many from different cultures and countries for whom idioms that may be clear to you are far from clear to others.

1 Like

https://linuxvox.com/blog/linux-kworker/#google_vignette
has an explanation. It is not unusual to have over 100 kworker threads on a lightly used system. What seems odd is that they appear to be concentrated on one CPU. The above article tells you how to limit the number of kworker threads on a CPU, or how to “isolate” CPU’s. Linux generally makes good decisions about resource allocation — you may find changes have unwanted side effects.

The kacpid in those kworker names is the key clue. That tells you these are ACPI interrupt handler threads, not general kernel workers. What is likely happening is a GPE (General Purpose Event) storm where a broken or misconfigured ACPI interrupt fires thousands of times per second, and the kernel dispatches a kworker to handle each one. All of them land on CPU 0 because ACPI interrupts are typically pinned to the first core.

To confirm, run this from a terminal:

grep . /sys/firmware/acpi/interrupts/gpe*  | sort -t: -k2 -n -r | head -20

Look for a GPE with an abnormally high count (tens of thousands or more while others are in single digits). That is your offending interrupt.

Once you find it (say it is gpe17), you can disable it:

sudo sh -c 'echo disable > /sys/firmware/acpi/interrupts/gpe17'

If the CPU usage drops immediately, that confirms the GPE storm. To make it permanent across reboots, add a systemd-tmpfiles config:

echo 'w /sys/firmware/acpi/interrupts/gpe17 - - - - disable' | sudo tee /etc/tmpfiles.d/acpi-gpe-fix.conf

This is a known issue on certain Intel 6th gen (Skylake) platforms like the i5-6400, and explains why your i5-3470 (Ivy Bridge) does not have the problem. A BIOS update from your motherboard manufacturer may also fix it if a newer version addresses the ACPI table.

The wireless keyboard and mouse dropping could be a side effect of the same storm overwhelming the USB controller’s interrupt handling on CPU 0.

5 Likes

I hope I won’t have to resort to that.

It’s a shame that “2 bios chips” isn’t the industry standard, because if the BIOS (or UEFI or whatever it’s called now) gets corrupted the MOBO is basically just junk…

That said, as soon as I’ve the chance to, I’ll try out what you told me to do, and post results.

Thank you.

:~$ grep . /sys/firmware/acpi/interrupts/gpe*  | sort -t: -k2 -n -r | head -20
/sys/firmware/acpi/interrupts/gpe_all:   49955
/sys/firmware/acpi/interrupts/gpe6F:   49954  EN STS enabled      unmasked
/sys/firmware/acpi/interrupts/gpe7F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe79:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe78:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe77:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe76:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe75:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe74:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe73:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe72:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe71:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe70:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6D:       0  EN     enabled      unmasked

“With an high number” and it’s gpe6F with almostalmost 50k…


It did drop immediately…

echo 'w /sys/firmware/acpi/interrupts/gpe6F - - - - disable' | sudo tee /etc/tmpfiles.d/acpi-gpe-fix.conf

The file got this edited in, but every time I start the PC gpe6F remains active…

I posted what I did in an edit in the opening message.

The last part of your instructions didn’t work, so I googled the quote and found that guide.

Now the PC starts up without spiking Core 1.
(It still goes at 100% while booting, but that shouldn’t be a problem, since it then “calms down” between 10 and 20% at idle, with a RTX 2070 at 4k native and 200% scale.)

I see something similar (i5-8400H/Gen8 Coffee Lake):

/sys/firmware/acpi/interrupts/gpe_all:   28404
/sys/firmware/acpi/interrupts/gpe6E:   28399  EN     enabled      unmasked
/sys/firmware/acpi/interrupts/gpe66:       5  EN     enabled      unmasked
/sys/firmware/acpi/interrupts/gpe7F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7E:       0         invalid      unmasked

Masking it quiet doesn’t sound like an ideal fix (seems like it’s still happening while just not being reported; would rather lower its polling or fix it)


I have unlocked BIOS settings and can probably find something to mess with, but where to begin?

gpe6E seems like EC according to dmesg: ACPI: EC: GPE=0x6e

acpi_osi at Windows 2013 and Linux didn’t seem to change interrupt amounts.

Masking stops newer reports:

echo 'mask' | sudo tee '/sys/firmware/acpi/interrupts/gpe6E'

Disabling EC doesn’t sound like a good idea, but if EC handles hardware on its own, why does the OS need to interface with it?

I’m not sure if there was high CPU use (Xfce’s monitor seemingly shows it different or not at all like GNOME sys monitor), but after masking I didn’t notice a FPS difference with glxgears; GTA V might be smoother but not certain.


Booting with acpi_mask_gpe='0x6E' removes it from /sys/firmware/acpi/interrupts/gpe*; haven’t seen anything different after a few minutes, but this post mentions a delay with laptop brightness keys.