Wer stürzt meinen Kernel ab?

Zunächst einmal stürzt Ihr Kernel nicht ab . Bei einem Absturz würde Ihr System vollständig einfrieren und Sie könnten es nicht verwenden.

Es gibt verschiedene Arten von Problemen, die im Kernel auftreten können.

• Eine Warnung (WARN), ein Fehler (BUG) oder ein OOPS kann auftreten, wenn die eingebauten Selbstprüfungen des Kernels eine Situation erkennen, die zu Systeminstabilitäten oder zukünftigem Datenverlust führen kann. Im Allgemeinen verursachen diese Probleme jedoch keinen (sofortigen) Absturz des Systems. Im Allgemeinen sind OOPSes die schwerwiegendsten von diesen und führen dazu, dass alle zugehörigen Userpace-Prozesse SIGKILLvom Kernel ein Signal erhalten ("Du sollst sterben", nicht "Bitte geh weg").

• Bei einer Panik wird das System so abgespritzt, dass es sich weigert, weiterzumachen. Hier stoppt der Kernel einfach (nachdem er eine Stack-Trace gedruckt hat, falls dies möglich ist) und gibt die Kontrolle an .... nichts. Meistens. Wenn Sie jedoch einen Absturzkernel haben, versucht der gebrochene Kernel manchmal, einen zweiten Kernel zu laden, der dazu dient, Informationen über die Ursache des Absturzes zu sammeln und auf die Festplatte zu schreiben. Im Allgemeinen ist es nicht einmal für einen sehr robusten Absturzkern möglich, den Zustand des Systems vollständig wiederherzustellen, um ohne Neustart wieder funktionsfähig und stabil zu sein.

Meiner Meinung nach ist ein Absturz gleichbedeutend mit einer Panik . Es gibt viele Situationen, in denen ein WARNoder BUGmit einer sehr geringen Wahrscheinlichkeit eines Datenverlusts sicher ignoriert werden kann. Wenn Ihr System weiterläuft, nachdem diese "Probleme" gemeldet wurden, ist dies fast keine Panik.

Sie haben mir (vor allem dmesg) nicht genug Protokolle zur Verfügung gestellt, um die Ursache für diesen Absturz erkennen zu können. Wenn der Kernel selbst jedoch Probleme meldet, manifestiert sich dies im dmesgKernel-Ringpuffer. Führen Sie den Befehl buchstäblich dmesgauf der Konsole aus, um den Kernelringpuffer anzuzeigen.

Es scheint, als hätten Sie in Ihrem Fall einmalige Ups erlebt, die vom abrtBenachrichtigungssystem für Absturzereignisse (oder der GNOME-Benutzeroberflächeninfrastruktur, in der sie Ihnen angezeigt werden) falsch behandelt werden .

26. Mai 16:39:30 segtic-1c505e gnome-session: abrt-applet: wiederholtes Problem im Kernel, die Benachrichtigung wird nicht angezeigt

Es denkt, es zeigt es Ihnen nicht, weil es ein wiederholtes Problem ist, aber es bombardiert Sie weiterhin mit dem gleichen Fehler. Also, entweder abrt-applet denkt, es bombardiert Sie nicht, tut es aber sowieso, oder es gibt ein anderes Programm, das Kernel-Fehler behandelt (vielleicht ein anderes Applet, das sich auch damit befasst abrt?), Das keine wiederholten Probleme erkennt und Sie immer wieder mit demselben Problem zuschlägt Über.

Hier gibt es also einige Probleme:

1. Sie haben mir keine dmesgProtokolle gegeben, die auf ein wiederholtes Problem hinweisen . Die ACPI-Sache, die Sie gezeigt haben, könnte die Ursache für einen Fehler sein, aber das geschah sehr früh beim Booten, und es passiert nicht immer wieder.

2. Die Infrastruktur für die Fehlerberichterstattung scheint defekt zu sein. Ich denke, auf einer gewissen Ebene abrt weiß ich, dass es sich um eine wiederholte Nachricht für dasselbe Ereignis handelt (oder um eine Folge von unabhängigen Ereignissen, deren Ursache identisch ist), aber irgendwie werden die Benachrichtigungen trotzdem durch das System und zu Ihrer Benutzeroberfläche geleitet.

3. Es ist offensichtlich ein Problem, dass Sie eine Art Absturz oder OOPS oder BUG oder WARN haben, die in erster Linie mit dem Linux-Kernel zusammenhängen . Aber da die Kernel-Protokolle, die Sie gepostet haben, minimal und nicht besonders besorgniserregend waren, scheint die Wurzel des Problems momentan schwer zu fassen. Wenn es sich um die ACPI Ausgabe vom frühen Boot beschweren, soll es wirklich den Mund zu halten lernen; Tatsache ist, dass Motherboard-ACPI-DSDTs fast immer furchtbar kaputt und kaputt sind und das Betriebssystem nur lernen muss, mit dem bestmöglichen Umgang damit umzugehen. Als Endbenutzer können Sie nichts dagegen tun. Es ist nicht so, als würde Ihr Mobo-Hersteller immer noch BIOS-Updates veröffentlichen, um seine DSDT-Korrektheit zu verbessern (naja, es ist ziemlich unwahrscheinlich, dass sie es sowieso tun würden).

Oder vielleicht hat das Problem überhaupt nichts mit ACPI zu tun, und der eigentliche Problembericht macht es einfach nicht zum Kernel-Ringpuffer. Dies wäre in der Tat ziemlich seltsam und nicht etwas, was ich zuvor erlebt habe. Ich bin mir nicht sicher, welcher Mechanismus verwendet abrtwird, um das Vorhandensein des Fehlers zu erkennen, wenn er nicht analysiert wird dmesg.

Wenn es um Linux-Kernel-Probleme und um die Art und Weise geht, in der sie in der Benutzeroberfläche angezeigt werden, gibt es selten einen einfachen Weg zur Diagnose. Es ist die Natur des Tieres.