Der TSC (Time Stamp Counter) ist eigentlich eine sehr präzise Zeitquelle diverser x86-CPUs, die allerdings unter bestimmten Bedingungen (z.B. Stromsparmodi) und bei bestimmten CPU-Typen (z.B. solchen mit Speedstep oder auf ähnliche Weise wechselnden Frequenzen) Unstetigkeiten und/oder Varianz aufweisen kann - siehe Wikipedia.

Aus diesem Grund hat der Linux-Kernel eine recht ambivalente Haltung zum TSC und führt sowohl beim Startvorgang wie auch dauerhaft zur Laufzeit verschiedene Plausibilitätsprüfungen durch, nutzt ihn aber dennoch, sofern und solange er verfügbar ist und "stabil" wirkt.

Normalerweise sollten diese Prüfungen einen "wackligen" TSC direkt beim Start entdecken und auf eine alternative Zeitquelle umschalten. So kenne ich das z.B. von meinen Laptops mit Pentium-3-Prozessoren, wo aufgrund Speedstep und Stromsparmodi sofort auf acpi_pm gewechselt wird.

Die Prüfungen zur Laufzeit scheinen dagegen so paranoid zu sein, daß sie auch "false positives" liefern können und ungefragt nach Tagen stabilen Betriebs den TSC verwerfen - so wie es vor wenigen Tagen auf meinem IBM Netfinity 5000 passiert ist, wo variable Frequenzen oder ähnliches nicht gegeben sind:

Apr 29 03:20:13 netfinity5000 kernel: [507140.635990] Clocksource tsc unstable (delta = -292934800 ns)
Apr 29 03:20:13 netfinity5000 kernel: [507140.636217] Switching to clocksource acpi_pm

Wenn das beim Start passiert wäre, hätte es höchstwahrscheinlich keinen Fehler verursacht - hier allerdings hatte ich das Problem, daß etwa 12 Stunden später das System mit einem Locking-Problem stehenblieb. Die CPU-Aktivitäts-Leuchtdioden blinkten rhythmisch abwechselnd, wie das für so ein Problem typisch ist, und es half nur ein harter Reset. Man beachte, daß dem Kernel dieses angebliche TSC-Problem nach fast 6 Tagen kontinuierlichen Betriebs aufgefallen ist!

Eine Internet-Recherche zu diesem Sachverhalt ergab einen interessanten Fund, der genau das Phänomen beschreibt (und teils mit recht unwissenden, aber überheblichen Kommentaren beantwortet wurde). Ein weiterer Fund beschreibt als eine mögliche Lösung den generellen Verzicht auf den TSC und die direkte Nutzung von acpi_pm. Doch damit wollte ich mich nicht zufriedengeben.

Weiteres Recherchieren und Prüfen einer aktuellen Kernel-Boot-Parameter-Liste brachte die Lösung - die TSC-Checks können deaktiviert werden, wenn man weiß, daß die interne Stabilität gewährleistet ist. Auf Pentium-3-Prozessoren ohne Speedstep ist dies der Fall, daher habe ich nun folgendes Zeilenfragment in meine Boot-Optionen eingetragen:

tsc=reliable

Mit dieser Option werden nach erfolgreicher Kalibrierung des TSC alle späteren Plausibilitätsprüfungen deaktiviert, was eine stabile Nutzung des TSC erlaubt.

Da dieser Server, wie auch meine Quad-P3-Xeon-Systeme, schon stetige Betriebszeiten von weit über 100 Tagen mit TSC erreicht hat und hier der Kernel niemals den TSC infragestellte, gehe ich von einem Fehler in den Prüfungsroutinen aus. Der Parameter "tsc=reliable" hat offensichtlich eine lange Geschichte und schon für einigen Diskussionsstoff gesorgt...