Wie kann ich Kernel-Paniken beheben?

Mein Raspberry Pi 3 arbeitet seit einem Jahr stabil als kopfloser Server. Im letzten Monat stürzt es häufig ab (alle zwei Tage). Ich kann einen Monitor anschließen und feststellen, dass eine Kernel-Panik aufgetreten ist. Ich bin mir jedoch nicht sicher, wie ich die Ausgabe interpretieren soll, es gibt keine Protokolle und die Ausgabe auf dem Bildschirm wurde fortgesetzt.

Hier sind Fotos von zwei verschiedenen Kernel-Paniken. (Entschuldigung für die Fotos; es gibt keine Textprotokolle.)

Gibt es eine Möglichkeit, die gesamten Protokolle anzuzeigen, und wie kann ich Kernel-Paniken beheben?

(Es ist auch offensichtlich, wo das Problem bei diesen Fotos liegt. Als Hintergrund tritt dies häufig um 3 Uhr morgens auf, wenn die automatisierten rsync-Backups (Backintime-Backups) durchgeführt werden. Dies hängt möglicherweise mit der Festplatten-E / A zusammen. Ich habe versucht, sie auszutauschen um ein neues RPi 3 zu verwenden, fsck-ing Volumes und den Kernel von auf 4.4.35-v7+zu aktualisieren 4.9.65-v7+, mit rpi-update.)

Gibt es eine Möglichkeit, die gesamten Protokolle anzuzeigen ...?

Auf Ihrem Raspberry Pi ist normalerweise eine serielle Konsole auf einem der integrierten UARTs aktiviert (oder kann so konfiguriert werden, dass eine serielle Konsole vorhanden ist), die an den GPIO-Pins 14 und 15 freigelegt ist. Mit dem entsprechenden Kabel (wie diesem ) können Sie dies verbinden bis zu einem anderen Computer und protokollieren Sie die gesamte Ausgabe in einer Datei. Dies erleichtert das Anzeigen / Kopieren / Einfügen usw. erheblich.

In diesem Dokument wird erläutert, wie Sie die serielle Konsole in neueren Versionen von Raspbian aktivieren.

Auf dieser Seite werden die seriellen Schnittstellen ausführlicher beschrieben.

... und wie kann ich Kernel-Paniken beheben?

Das ist eine schwarze Kunst, für die ich kein besonderer Experte bin.

Adressierungspunkt 2

... und wie kann ich Kernel-Paniken beheben?

Eine Kernel-Panik ist nur ein Absturz im Kernel. Ein Absturz, der durch eine beliebige Anzahl normaler Software- oder Hardwarefehler verursacht wird.

Das Debuggen des Kernels unterscheidet sich nicht von jeder anderen Software. Eine Kombination von

• Protokollnachrichten untersuchen
• Stapelspuren untersuchen
• Verwenden eines Debuggers mit Haltepunkten
• Fehlerisolierung (Entfernen / Deaktivieren von Softwarekomponenten, bis nur noch der fehlerhafte Abschnitt ausgeführt wird)

Eine zusätzliche Option für Kernel

• Durch die Überwachung des Kernels werden interne Überwachungsstrukturen unter /proc/und /sys/angezeigt. Dies kann Ihnen beispielsweise dabei helfen, Trends zu verfolgen (z. B. die Anzahl der Ausnahmen steigt vor einem Absturz, die CPU-Auslastung steigt, viele Swap- / Kontextwechsel). Dies ist jedoch eine sehr qualitative und "nicht in Echtzeit" Debugging-Information.

Da der Kernel das System ausführt, ist es leider schwieriger, an Ort und Stelle zu debuggen als User Space Code. Protokollnachrichten sind so ziemlich alles, was Sie wirklich haben

Es ist möglich, Ihren eigenen Kernel-Code vor Ort zu debuggen , wenn Sie wissen, was er tut und wo er falsch läuft, indem Sie ausführliche Protokollierung und anderes logarithmisches Debuggen in Ihrem benutzerdefinierten Modul / Kernel durchführen, aber zeitweise Abstürze in einem vorkompilierten Code diagnostizieren Release-Kernel kommt so gut wie nicht in Frage. Sie werden nichts Besseres tun, als ohne zusätzliche Hardware zu protokollieren

Sie benötigen eine Hardwareschnittstelle, um das Debugging auszuführen. In der eingebetteten Welt wird dies als In Circuit Emulation( ICE ) bezeichnet und wird üblicherweise mithilfe der JTAGSchnittstelle erreicht

Sie müssen nämlich JTAGeine Hardware-Debugging-Schnittstelle verwenden. Dies ermöglicht es, Haltepunkte zu setzen und die CPU mit externer Hardware zu unterbrechen.

Bei korrekter Einrichtung können Sie JTAGproblemlos gdbauf einem Host-PC laufen, um eingebettete Linux-Kernel zu debuggen. Die Verwendung ist identisch mit der Verwendung gdbmit anderen Anwendungen, die Schnittstelle ist jedoch Hardware.

Sie würden dieses Setup verwenden

• "fangen" (brechen) diese Kernel-Panik, bevor sie auftreten
• Der Haltepunkt hält die CPU an
• Führen Sie die CPU Befehl für Befehl durch den Absturz
• Untersuchen Sie den gesamten Speicher, der geändert wird
• Untersuchen Sie den Speicher und den Stapel der CPU mit Ihrem Debugger
• Verwenden Sie diese Informationen, um die Hauptursache für den Absturz zu ermitteln

Gutes Ressourcen-Tutorial: https://www.elinux.org/Debugging_The_Linux_Kernel_Using_Gdb

Beachten Sie, dass selbst dies möglicherweise nicht ausreicht. Es gibt viele Probleme, die nur auftreten, wenn Dinge "mit Geschwindigkeit" ausgeführt werden, dh das Einwerfen eines Debuggers oder sogar zusätzliche Protokollmeldungen können das System so stark verändern, dass der Fehler ausgeblendet oder maskiert wird.

Zusamenfassend

Es ist eher eine Kunst als eine Wissenschaft

Ihr Protokoll ist tatsächlich abgeschnitten. Ich vermute, Sie haben einen Hardwarefehler, der eine nicht behandelte CPU-Ausnahme auslöst, die den Kernel-Absturz / die Panik verursacht.

Ein sehr häufiges Szenario ist intermittierender / fehlerhafter / beschädigter Speicher, der dazu führt, dass ein falscher Befehl in die CPU geladen wird, was eine Ausnahme verursacht.