"Enter" drücken, um zum Inhalt weiterzugehen

ubuntu 14.04: Hohe CPU Last durch kworker

Beitragsbild: „old painted Ubuntu logo on wood planks“ von: blumblaum, flickr.com, lizenziert unter einer Creative Commons Namensnennung 2.0 Generic Lizenz.

Auf meinem Sony Vaio Notebook, über dessen Kauf mit Hindernissen ich vor zwei Jahren hier bereits berichtet hatte, lief seit Frühjahr 2013 die ubuntu-Version 13.04 („Raring Ringtail“), die ja seit dem 27. Januar 2014 nicht mehr supportet wird. Darum nahm ich mit einer Neuinstallation ein Upgrade auf die aktuelle ubuntu-Version 14.04 („Trusty Tahr“) vor, das auch in einer viertel Stunde durchgelaufen war. Ich konnte sofort an gewohnter Stelle weiterarbeiten. Leider stellte sich schnell heraus, dass mein Notebook nun plötzlich vom Start an bei untätigem Desktop mit einer CPU-Last von ca. 80% Prozent lief, die den Lüfter ständig surren ließ. Woran konnte das liegen?

Mein ubuntu-Notebook: Systeminformationen
Mein ubuntu-Notebook: Systeminformationen

Um das Problem einzugrenzen, ließ ich mir erst einmal den Übeltäter anzeigen, der die hohe CPU Last erzeugte. Die Eingabe von „top“ im Terminal brachte folgendes Resultat, womit ich als Übeltäter den „kworker“-Prozess ausmachen konnte.

 Hier zeigt sich, wer für die CPU Last von 76% verantwortlich ist: ein Prozess namens kworker
Hier zeigt sich, wer für die CPU Last von 76% verantwortlich ist: ein Prozess namens kworker

Erste Anlaufstelle war natürlich das Netz. Zunächst wurde ich dort nicht fündig. Erst ein englischsprachiger Artikel, der sich eigentlich auf die ubuntu-Version 12.04 („Precise Pangolin“) bezog, brachte mich auf die richtige Spur. Und weil mir das Verfahren wieder zu einem leisen Desktop und einer kühlen CPU geholfen hat, schreibe des Rätsels Lösung hier einfach mal in Deutsch auf.

CPU Last adé: Drei Schritte zur Ruhe

1) Zunächst einmal muss man den GPE (General Purpose Event) herausfinden, der für die Systemlast verantwortlich ist. Vorstellen kann man sich einen GPE wie eine Art Interrupt, über den die Hardware das Betreibssystem via ACPI informiert, dass ein bestimmtes Ereignis vorliegt.

Wir öffnen also eine Shell, werden ‚root‘ mittels sudo und geben ein:

grep . -r /sys/firmware/acpi/interrupts/

In der nun erscheinenden Liste suchen wir nun einen GPE mit einem hohen Wert. (Mein GPE war der mit der Nummer 13, es kann aber je nach Hardware auch ein anderer GPE sein, der die CPU Last erzeugt).

2) Danach editieren wir die Datei crontab, um den GPE mit der Nummer 13 (entsprechend ändern bei anderer Hardware!) schon beim Booten auszuknocken:

crontab -e

Wir schreiben dazu folgende Zeile in die crontab:

@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe13

Bitte die Datei sichern.
Durch diesen Eintrag wird gpe13 bereits beim Booten deaktiviert, das hilft meistens schon viel.

Was aber, wenn ich den Deckel des Notebooks zuklappe, und das Notebook dann beim Deckelaufklappen wieder aktiv wird und den gleichen GPE dynamisch wieder erzeugt?

3) Dazu muss ich ins Suspend-Verhalten eingreifen und folgende drei Schritte tun: eine bestimmte Datei erstellen, diese ausführbar machen und abschließend editeren. Also:

~ touch /etc/pm/sleep.d/30_disable_gpe13
~ chmod +x /etc/pm/sleep.d/30_disable_gpe13
~ mcedit /etc/pm/sleep.d/30_disable_gpe13

In die so erstellte und ausführbar gemachte Datei „30_disable_gpe13“ füge ich mit dem Editor (ich nutze auf der Konsole gerne mcedit, es geht aber auch vi oder joe, je nach Vorliebe) folgendes ein:

#!/bin/bash
case "$1" in
    thaw|resume)
        echo disable > /sys/firmware/acpi/interrupts/gpe13 2>/dev/null
        ;;
    *)
        ;;
esac
exit $?

Das wars. Nach einem Reboot arbeitet kworker normal. Zumindest war dies bei mir so.

Im Übrigen ist der sog. „kworker-bug“ bereits älter, er trat schon mit mancher Hardware beim 2.6er Kernel auf. Auch auf meinem iMac, der anfangs unter ubuntu wegen kworker ebenfalls von hoher CPU Last „gequält“ wurde, half dieser Tipp. Feedback erbeten!

7 Comments

  1. Kalle Kalle 2. Februar 2015

    Das hat wirklich funktioniert, was immer es war, nun is Ruhe.. soliden Dank!

  2. siegrid brand siegrid brand 3. Januar 2018

    Danke für deine Lösung, hat super geklappt, nur mit dem crontab Eintrag hat genügt.

    • Ulrich Berens Ulrich Berens 4. Januar 2018

      Das freut mich! Zugleich wundert es mich, dass das Problem immer noch oder bzw. schon wieder auftritt…

  3. Achim Westermann Achim Westermann 26. Februar 2018

    Das gleiche hier: Ubuntu 16.4. Danke für die Lösung.

    • Ulrich Berens Ulrich Berens 27. Februar 2018

      Danke für die Rückmeldung! Dass sich das Problem so quer durch die Versionsnummern zieht…

  4. Obi-Wan Kenobi Obi-Wan Kenobi 20. September 2018

    Danke Ulrich. Ich nutzte Deinen Tipp schon sehr lange. Aber es gibt noch eine elegantere Lösung. Nämlich den Kernel-Parameter ‚acpi_mask_gpe‘. Das habe ich heute per Zufall im Netz gefunden. Funzt bei mir 1a.

    Mein Grub-Eingetrag (Beispiel):
    video=1920×1080 resume=/dev/disk/by-uuid/ea7750c4-7721-43a7-8824-855e1ac7618c acpi_mask_gpe=0x61 acpi_mask_gpe=0x03 acpi_mask_gpe=0x66 splash=silent quiet showopts

    Meint:
    /sys/firmware/acpi/interrupts/gpe61
    /sys/firmware/acpi/interrupts/gpe03
    /sys/firmware/acpi/interrupts/gpe66

    So musst Du den CRONTAB und das SUSPEND-Verhalten nicht anrühren.

    • Ulrich Berens Ulrich Berens 20. September 2018

      Das sieht in der Tat deutlich eleganter aus! Vielen Dank für den Hinweis!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.