Opensuse 42.2 Kworker legt System lahm

Hinweis: In dem Thema Opensuse 42.2 Kworker legt System lahm gibt es 14 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Tach auch,
    seit einigen Tagen legt der kworker das System alle 2 Tage lahm.
    Was habe ich geändert: 'eigentlich' nichts außer:
    1. habe versucht die saudämliche Passwort Abfragen nach dem Aufklappen des Laptops abzuschalten;
    ohne Erfolg.
    2. habe SimpleScan neu drüber installiert.


    An mehr kann ich mich nicht erinnern.


    linux-bik2:~ # uname -a


    Linux linux-bik2.site 4.4.74-18.20-default #1 SMP Fri Jun 30 19:01:19 UTC 2017 (b5079b8) x86_64 x86_64 x86_64 GNU/Linux

    Für den Inhalt des Beitrages 112544 haftet ausdrücklich der jeweilige Autor: oracle123

  • seit einigen Tagen legt der kworker das System alle 2 Tage lahm.

    Es gibt immer mehrere Kernelthreads mit dem Namen kworker. Welcher macht die Probleme? In Netz gibt es immer mal wieder Meldungen, wie Du Sie beschreibst. Häufig ist das Problem behoben mit einem down- oder upgrade des Kernel.
    Wenn Du die Suchmaschine Deines Vertrauens nutzt, findest Du u.a. dass teileweise Interrupt-Service-Routinen wie sie bspw. von Programmen-/teilen zur Einbindung von usb-devices genutzt werden, dies verursachen können. Dieses fehlerhafte Verhalten kann ggf. auch mit !würgaround!


    behoben werden. Wie Du hier lesen kannst, war ein kworker-Prozess mit einer Graka von Intel "schwer" beschäftigt - was behoben werden konnte. Mit den Infos, die Du gibst, ist wenig anzufangen.


    Was habe ich geändert: 'eigentlich' nichts außer:
    1. habe versucht die saudämliche Passwort Abfragen nach dem Aufklappen des Laptops abzuschalten;
    ohne Erfolg.
    2. habe SimpleScan neu drüber installiert.

    Natürlich kann das die Ursache sein - muss aber nicht. Was hast Du verändert (1.)? Was meinst Du mit "Passwort Abfragen" - werden mehrere Passwörter abgefragt? Warum hast "SimpleScan neu drüber installiert" - hört sich für mich nach einer Vorgehensweise an, die eher für Windows üblich ist. Mit "drüber installieren" erreicht man häufig gar nichts.

    be tolerant - not ignorant
    Alle Hunde sind schwarz.
    Es gibt einen Hund der nicht weiß ist.

    Für den Inhalt des Beitrages 112580 haftet ausdrücklich der jeweilige Autor: Boreas

  • So, hab gestern Abend noch den Kernel upgedatet. Heute nach dem Aufklappen des Laptops(Fujitsu Lifebook S, i5 8GB; KDE)
    war 136 mal der kworker aktiv; kurze Zeit später dann nur noch so um die 26 Prozesse.
    Hab einige (2) Anleitungen im Netz gefunden, die ich bei Gelegenheit ausprobieren werde und das Ergebnis dann hier poste . . .


    Mit der 'Saudämlichen' Passwortabfrage meine ich Kwallet, das immer nach dem Aufklappen das Wlan Passwort und das von root haben möchte.
    Hier versuche ich demnächst das hier'http://linux-club.de/forum/viewtopic.php?t=121297'.

    Für den Inhalt des Beitrages 112593 haftet ausdrücklich der jeweilige Autor: oracle123

  • Wenn da nur die Intel Grafikkarte und sonst nichts verbaut ist, mal mit dem Kernel aus kernel:stable versucht?

    Für den Inhalt des Beitrages 112594 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Hier der Misthaufen; coredumpctl


    Hmm, seit heute ist auch die eth0 wech ...
    Ich sehe sie zwar in yast > netzwerkeinstellungen; kann sie dort aber nicht aktivieren oder gar löschen(wicked).






    Nachtrag:
    eth0 ist wieder da; wahrscheinlich wegen dem hier: collectNWDataGUI.sh


    Danke

    Einmal editiert, zuletzt von oracle123 ()

    Für den Inhalt des Beitrages 112619 haftet ausdrücklich der jeweilige Autor: oracle123

  • OK!


    So, jetzt wieder zum eigentlichen Thema: dem kworker; aktuell sind es:



    Code
    linux-bik2:/etc # ps -ef | grep kworker | wc -l
    30

    Prozesse.


    Werde das System noch einige Tage beobachten, und dann hoffentlich als erledigt markieren!


    Danke!

    Für den Inhalt des Beitrages 112627 haftet ausdrücklich der jeweilige Autor: oracle123

  • Bei mir laufen 15 kworker Prozesse von root mit 0% Cpu und 0 Speicher.


    Sie lassen sich nicht beenden und auch nicht killen.


    Elternprozess ist kthreadd läßt sich auch nicht beenden oder killen.
    (auch nicht als root mit icewm)


    Manchmal verschwindet ein Prozess und ein anderer kommt.


    Manchmal kommt bei einem Prozess die Meldung "disk sleep" und geht wieder.


    Manchmal kommt bei einem Prozess die Meldung "inaktiv auf Festplatte" und geht wieder.


    kworker hat etwas mit Speichermedien zu tun, und benötigt bei mir keine Ressourcen.


    Ich denke, wir sollten kworker einfach seine Arbeit machen lassen!

    Für den Inhalt des Beitrages 112661 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • kworker sind Arbeitsprozesse des Kernels. Sie sind NICHT direkt einem Programm oder einer Funktion zuordenbar.
    Im wesentlichen lässt der Kernel von einem solchen Worker-Prozess einen System-Request abarbeiten. Meist durch einem Interrupt aufgerufen.


    Tritt ein solcher SysRequest auf, wissen wir noch lange nicht, was diesen Request ausgelöst hat.
    Wir wissen nur, dass ein Interrupt gerufen wurde, und die unmittelbare Reaktion des Systems verlangt worden ist.
    Dem Kernel ist das alles erst mal völlig egal.
    Er ruft für diesen Interrupt die zugehörige Serviceroutine auf, eben einen solchen kworker, und kümmert sich vorerst gar nicht weiter darum.


    Meist wird dann irgendein Hardwareereignis verarbeitet.
    Die Mouse wurde geschubst, die Netzwerkkarte gepingt, der Akku demonstriet gewalttätig für mehr Lohn und Nahrung,
    der Bildschirm hat keinen Bock mehr und hisst den Trauerflor.
    Was auch immer, wir wissen es nicht.


    Die jeweiligen kworkers tun ihre Arbeit und erklären dem Akkuwatchdog, dass der Oberlooser jetzt benachrichtigt wird.
    Die Netzwerkkarte wird von dem Pingpaket entlastet, eine Antwort gesendet und der Krempel gelöscht.
    Dem Bildschirm wird der Saft abgedreht.
    Der Mousezeiger wird rumgeschubst.


    Das ganze ist im ACPI verankert. (AdavancedConfigurationandPowerInterface)
    Es geht also um die gesamte Hardware und das Powermanagement.


    Man kann einem solchen Übeltäter auf die Spur kommen, wenn man top oder dergleichen laufen lässt
    Wenn man sieht, dass die Last richtig hoch geht, drückt man in einer weiteren Konsole <enter> um den schon eingegeben Befehl echo l > /proc/sysrq-trigger auszuführen. Der veranlasst einen Backtrace, der dann Aufschluss geben kann, was denn die Ursache sein könnte.
    Man muss das schon mehrmals machen, um den oder die Schuldigen zu finden. Man lese alles, was nach dem getriggerten Backtrace erscheint.
    Was am häufigsten auftaucht, wird der Grund für die Last sein.
    Mitlesen tut man den Krempel am besten in einer dritten Konsole, wo der Befehl journalctl -f  dann beständig Unverständliches blubbert.
    Dazu muss man jedoch schon ein wenig mehr von Hardware und den jeweiligen Akronymen für die Hardware verstehen.
    Dass ein NMI ein NichtMaskierbarerInterrupt ist, ist noch Kindergartenwissen. Mittlere Reife sollte man schon haben.
    Etwas bequemer wäre wohl performance, was aber erst mit zypper in perf installiert werden will.
    Mit perf record -g -a sleep 10 erstellt man einen 10 Sekunden langen Log aller Prozessoren und mit perf report kann man dann gemütlich nachlesen, was da so passiert ist. ( Die Cursortasten zum Navigieren, <enter> um eine Zeile dann aufzuklappen und etwas mehr Infos zu lesen)


    In diesen Traces findet sich am Anfang (also nach Datum/Zeit und Hostname am Anfang der eigentlichen Meldung) dann immer der Kernelmodulname, das dafür verantwortlich ist. Ein beherztes rmmod <modulname> und die Load sollte schlagartig zurückgehen.
    Dann weiß man, wo man zu graben hat, falls man das dann überhaupt noch lesen kann und nicht zum Hardreset gezwungen ist.


    Etwas leichter und weniger Wissen fordernd mag die etwas rustikale Methode sein:
    In /sys/firmware/acpi/interrupts/ sind alle Genossen gelistet, die als Ursache in Frage kommen können.
    Mit dem Befehl grep -r . /sys/firmware/acpi/interrupts/ erhält man eine Liste mit der Anzahl der Interrupts.
    Der Befehl ist etwas schräg:
    grep Mit dem GlobalRegularExpressionPrinter suchen wir
    -r rekursiv (also in allen Dateien einschliesslich aller Unterverzeichnisse)
    nach einem beliebigen Zeichen in dem Verzeichis
    /sys/firmware/acpi/interrupts/
    Da der grep Befehl bei -r den Pfadnamen der Datei mit ausgibt, haben wir danach die Dateinamen mit der zugehörigen Zeile (Dort ist immer nur eine Zeile mit der Anzahl und in der suchen wir ein beliebiges Zeichen, was wir auf jeden Fall finden.), und können so bequem lesen, welcher dieser Interrupts am häufigsten gerufen wurde.
    Eine solche Fundzeile mag so aussehen:
    /sys/firmware/acpi/interrupts/gpe39: 0 invalid
    Damit wäre der Interrupt Nummer gpe39 unser Target.


    Und den schalten wir einfach aus mit: echo disable > /sys/firmware/acpi/interrupts/gpe39
    Die Last sollte auch da schlagartig runter gehen, oder man muss weiter suchen, falls man das noch kann.


    Die Verzeichnisse /sys und /proc sind Pseudodateisysteme. Statt in "echte" Dateien zu schreiben, schreiben wir direkt in die Kerneldatenstrukturen, oder lesen daraus.
    Getreu dem heiligen *nix Dogma: Alles ist eine Datei


    Keine Angst vor dem Kernel!
    Immer feste druff!


    Mehr als stehen kann das System nicht.
    Und auf ein Neues, und sofort wieder feste druff!!!