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.
rsyncwürde auf einen SD-Kartenfehler hinweisen. Sie haben eine begrenzte Anzahl von R / W-Vorgängen, und ein Jahr starker Beanspruchung könnte dies bewirken. Selbst wenn Sie externe Laufwerke für Daten verwenden, ist es dennoch möglich, dass eine Beschädigung / ein Ausfall der SD-Karte dies verursacht. Andere Hardwaremöglichkeiten sind schlechter Arbeitsspeicher und andere Fehler.