[Podcast] Kernel Panic - Board on Fire ~~> #002: Wachhunde und (nicht so) ideale Bauelemente

In der zweiten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem ich mich ausnahmsweise mal selbst beschäftigt habe. Damit ich mich dazu nicht selbst ausfragen muss springt netterweise Chris als Gastinterviewer ein. Problem dieses mal ist ein Gerät, das dann und wann einfach neu startet, und wieder einmal könnte die Ursache sowohl in der Software als auch in der Hardware zu finden sein. Es folgt eine Suche durch die verschiedenen möglichen Ursachen für Neustarts von Geräten, die uns an Watchdogs, Übertemperatur, den Eigenheiten von PoE, WAD pins und Dioden vorbei zur Lösung führt. Und wieder einmal steht die Größe der Änderung in keiner Relation zur vorherigen Suche.

Über den Kernel Panic - Board on Fire Podcast

In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann. So auch in der Welt der Software. In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen. Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch auftretenden Geistern im System führt, um bröckelnde Software, deren Quellcode schon vor Jahren verloren gegangen ist, und manchmal auch um ganz was anderes.

Shownotes

Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken orientieren:

00:00
Chris und Leonard fachsimpeln über LoRa, Gatways und Minimum Viable Products. Es soll ein Prototyp eines LoRa Gateways gebaut werden um die Anforderungen und Problemstellungen kennenzulernen.
08:40
Wie entwickelt man Software für ein eingebettetes System? Hersteller-BSP/-Kernel/-Bootloader vs. Mainline - Vor- und Nachteile. Was unterscheidet Yocto von "normalen" Linux-Distributionen?
12:15
LoRaWAN-Software Semtech Forwarder vs. Chirpstack.
13:40
Das eigentliche Problem - das Gerät läuft nicht durch sondern power-cycled nach zwei Stunden.
15:00
Möglicher Grund für neustartendes System: 1. Ein Watchdog schlägt zu und startet es neu.
27:30
Möglicher Grund für neustartendes System: 2. Die CPU/ein anderes IC schaltet wegen Übertemperatur ab
30:15
Möglicher Grund für neustartendes System: 3. Sich falsch verhaltender PoE-Injector
34:15
Auf den PoE-Leitungen zeigen sich komische Effekte wie z.B. dann und wann einbrechende Versorgungsspannung. Aber: das periodische Neustarten tritt auch auf wenn die PoE-Spannung aus einem stabilen Netzteil kommt.
39:00
Der PoE-IC auf dem Gerät selber schaltet die Versorgungsspannung ab.
42:15
Ursache des Abschaltens ist der WAD (Wall Adapter) Pin des PoE-IC, der bei angeschlossenem Netzteil die PoE-Versorgung abschalten soll. Allerdings ist kein Netzteil angeschlossen.
49:15
Grund für die Spannung am WAD-Pin ist das Aufladen der Eingangskapazität über rückwärts durch eine Diode fließenden Leakage-Strom. Durch einen Widerstand nach GND kann der Leakage-Strom abgeleitet werden.
57:00
Meldung an den Hersteller. Der WAD-Pin und einmal dort gewesener Widerstand nach GND wird im Changelog der Boardrevision erwähnt, die wir haben. Der Widerstand wurde bewusst entfernt.
60:00
Abschluss. Wieder einmal hat sich gezeigt: "Always check your voltages". Erst die Spannungsversorgungen anschauen bevor man nach komplexeren Problemen sucht.

Further Readings

[Podcast] Kernel Panic - Board on Fire ~~> #003: Ein Rennen um Nanosekunden - Nebenläufigkeit mit Hardwareeinheiten

In dieser Folge erzählt Michael Grzeschik die Geschichte eines USB-Controllers, der dann und wann einfach aufhört zu funktionieren und davon wie er dem Fehler mit Tracing, einem Disassembler und viel Codelektüre auf die Schliche gekommen ist. Wir stellen einmal mehr fest, dass Probleme mit Nebenläufigkeit schwierig zu debuggen sind und nicht nur Software-Software Interaktion betreffen, sondern manchmal auch Software-Hardware.


[Podcast] Kernel Panic - Board on Fire ~~> #001: Speculative Execution und ein Execute Never Bit

In der ersten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem sich mein Kollege Ahmad Fatoum beschäftigt hat. Wie so oft beginnt die Geschichte mit einer Aufgabe, die eigentlich™ in fünf Minuten erledigt sein sollte, driftet aber rasant ab in eine Fehlersuche in den Untiefen der Systemprogrammierung. Es geht um Caches, Adressbereiche, Spekulative Ausführung von Code, um Funktionierbits und auch um Nicht-Funktionier-Bits.