Welche Tools eignen sich zur Fehlerdiagnose von Kernel-Problemen auf dem Nothing Phone (3)?

Melden
  1. Allgemeines Vorgehen und Vorbereitung
  2. adb und dmesg
  3. kernel-logging und kmsg, printk
  4. ftrace und trace-cmd
  5. perf und BPF/eBPF
  6. Crash-Dumps: kdump, pstore, ftrace-Persistence
  7. Hardware-Diagnose und Treiberlogs
  8. Spezielle Android-Tools: systrace, atrace, bugreport
  9. Analyse und Visualisierung

Allgemeines Vorgehen und Vorbereitung

Vor der Nutzung von Diagnosetools solltest du sicherstellen, dass das Nothing Phone (3) entsperrten Bootloader hat oder ein Entwickler- oder Testgerät ist, da viele Kernel-Diagnose-Methoden Root-/Bootloader-Zugriff benötigen. Erstelle ein vollständiges Backup und sammele Kernel- und Log-Zugriffsrechte (adb, fastboot, su). Aktiviere Entwickleroptionen, USB-Debugging und, falls nötig, root oder temporäre adb-Root-Shell. Kenntnis der verwendeten Kernel-Version und des Kernel-Konfigurations-Setups (dmesg-Ausgabe, /proc, /sys) ist wichtig, um passende Tools und Parameter zu wählen.

adb und dmesg

adb ist das primäre Werkzeug zur Kommunikation mit dem Gerät. Mit adb logcat und adb shell dmesg bekommst du Kernel- und Systemmeldungen. dmesg zeigt Kernel-Ringpuffer, der bei Boot-Problemen, OOM-Killern oder Hardware-Treibern oft die ersten Hinweise liefert. Achte auf Vergabe von Puffergrößen und das Sammeln direkt nach einem Repro-Schritt, denn der Ringpuffer rotiert. Kombiniere adb logcat -b kernel für integrierte Kernel-Logs.

kernel-logging und kmsg, printk

Der Kernel schreibt via printk in kmsg (/proc/kmsg oder /dev/kmsg). Tools oder Skripte, die /dev/kmsg auslesen, erlauben Echtzeit-Überwachung. Auf Android-Geräten kann der Zugriff eingeschränkt sein; Root ist oft nötig. Durch Anpassung von printk-Leveln (z. B. echo "" > /proc/sys/kernel/printk) und durch Aktivierung spezieller Debug-Flags in Treibern lässt sich die Detailtiefe erhöhen.

ftrace und trace-cmd

ftrace ist das eingebaute Tracing-Framework des Linux-Kernels. Über /sys/kernel/debug/tracing kannst du Funktionsaufrufe, Scheduler-Ereignisse, IRQ-Latenzen und mehr beobachten. trace-cmd und Kernelshark (Desktop-Tools) helfen bei Sammlung und Visualisierung der Traces. Auf dem Nothing Phone 3 musst du DebugFS mounten und berechtigt sein, die Tracing-Interfaces zu nutzen; trace-Aufnahmen sind sehr nützlich bei sporadischen Hängern oder Latenzproblemen.

perf und BPF/eBPF

perf kann CPU-Profile, Wakeups, IRQ- und Kontextwechsel analysieren. eBPF-Tools (bpftrace, bpftool) erlauben fein granulare Laufzeitinstrumentierung ohne permanente Kernel-Änderung. Diese Tools sind mächtig bei Performance- und Scheduling-Problemen, erfordern aber kompatible Kernel-Unterstützung und meist ein Desktop, um die Daten zu sammeln und zu analysieren.

Crash-Dumps: kdump, pstore, ftrace-Persistence

Für Kernel-Panics sind persistente Crash-Dumps entscheidend. pstore/pmsg oder RAM-OOPS-Mechanismen speichern OOPS-Informationen über Reboots hinweg, wenn richtig konfiguriert. Einige Android-Geräte verwenden spezielle Crash-Collector-Daemons; prüfe /sys/fs/pstore. Kdump ist auf mobilen Geräten seltener, aber wenn vorhanden, erlaubt es Kernel-Crash-Image-Sammlung und Post-Mortem-Analyse mit crash (kernel crash utility) auf einem Host.

Hardware-Diagnose und Treiberlogs

Viele Kernel-Probleme sind hardwarebezogen (SoC, Blobs, PMIC). Nutze sysfs-/proc-Einträge der betreffenden Subsysteme (/sys/class/*, /proc/interrupts), I2C-/SPI-Adapterlogs und Diagnose-Tools des SoC-Herstellers (Qualcomm/Mediatek-Tools sind oft OEM-spezifisch). Serieller Kernel-Console-Ausgang (UART/serial) ist sehr hilfreich bei frühen Boot-Problemen, verlangt aber Hardware-Zugang.

Spezielle Android-Tools: systrace, atrace, bugreport

Android-spezifische Werkzeuge ergänzen Kernel-Infos um Userspace-Events. atrace/systrace erfassen Trace-Events, die Scheduler und Binder-Aktivität sichtbar machen. adb bugreport erzeugt systemweite Sammlungen (inkl. dmesg/logcat) und ist praktisch für die Kommunikation mit Entwicklern.

Analyse und Visualisierung

Sammle reproduzierbare Traces und Crash-Logs und analysiere sie mit Desktop-Tools wie Kernelshark, flamegraph-Generatoren oder GDB (für Crash-Dumps). Vergleiche Verhalten vor/nach Kernel-Parametern. Dokumentiere Kernel-Version, Build-Konfig, Modul-Liste und genaue Reproduktionsschritte, damit Fehlerberichte verwertbar sind.

0