Wenn im System nichts mehr läuft und nur noch kryptische Meldungen auftauchen, fängt für mich der interessante Teil an. Ich grabe mich durch Register, Logs und Speicherinhalte, bis klar ist, was wirklich passiert. Dabei geht’s nicht um Perfektion, sondern ums Verstehen – Schicht für Schicht, Bit für Bit.
Kurz vor Veröffentlichung, 17:12. Ich sitze unterm Vordach, der Himmel hängt grau über Passau, 3‑Komma‑irgendwas °C, und der Wind flüstert leise ums Dach. Perfektes Licht, um Traces zu lesen – dieses diffuse Winterlicht blendet nix. Heute also der angekündigte Deep‑Dive: das erste clocksource->read() nach do_clocksource_switch(). Messaufbau Ich hab wieder meine kleine VM mit QEMU/KVM genutzt, Kernel instrumentiert, trace-cmd und eine BPF‑kprobe…
Der Regen tropft leise aufs Vordach, während ich auf dem Balkon sitze – Laptop halb unter Dach, Kabel nur kurz raus fürs Antennensignal. Knapp über null Grad, nasskalt, aber es geht noch. Passt ganz gut zum Thema heute: Single‑File‑Mode bei trace‑cmd ausprobieren – also alles in eine Datei schreiben anstatt den Ring‑Buffer laufen zu lassen. Ziel: prüfen, ob’s genauso stabil…
Steh grad auf dem Balkon, Laptop halb unter dem Vordach. Wolken hängen tief über Passau, -4 °C, kaum Wind. Man spürt richtig, wie die Luft alles klirrend klar macht – ideal, um endlich den offenen Loop mit trace‑cmd zu schließen. Heute ging’s darum herauszufinden, welche Kombination aus Filter und Buffer‑Größe clocksource_switch‑Events wirklich vollständig mitschreibt. Ich hatte schon länger den Verdacht, dass…
Seit der Zeitumstellung spuken mir wieder 2–18‑Sekunden‑Zeitsprünge ins System. GPS‑1PPS läuft stabil, keinerlei Drift – aber die Systemuhr entscheidet spontan, dass jetzt halt später ist. Heute will ich einkreisen, ob das tief im Kernel passiert oder irgendwo im User‑Space nachzieht. Ich sitze unter dem Vordach; es ist bedeckt, die Luft leicht feucht, aber ruhig genug, um Oszi und Logger draußen…
