Sie befinden sich hier

Inhalt

Blockierter Server mehrere Stunden nach "TSC unstable"-Erkennung des Linux-Kernels mitten im Betrieb

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...

Kommentare, Anregungen, Ergänzungen?

Michael, 24.07.2013 14:47:
Das hier wollte ich schon länger kommentieren, aber leider ist es mir nicht gelungen, die damaligen Informationen nochmals zusammenzutragen. Ich weiß nur noch, daß ich wenige Tage nachdem ich das hier gelesen hatte ebenfalls ein TSC Problem hatte, z.T. mit den selben Fehlermeldungen.

Irgendwie hing selbiges bei mir aber mit dem nVidia Treiber (also wirklich "nvidia", nicht nv oder nouveau) zusammen, oder es gab zumindest eine Korrelation zwischen den beiden.

Das resultierende Verhalten waren teilweise minutenlange Freezes, zwischen denen das System für wenige Sekunden normal weiterzulaufen schien. Natürlich unbenutzbar. Es hat mich mehrere solcher kurzer funktionierender Abschnitte gekostet, um endlich das shutdown Kommando eingeben zu können. Und dann noch die Warterei.

Schade nur, daß ich die Logs nicht mehr habe, die Beziehung zwischen der TSC und dem Grafiktreiber wäre evtl. nicht ganz uninteressant gewesen.

Bei mir war die instabile Quelle übrigens HPET, dies hier ist ein HPET-fähiges System mit dynamischer Taktänderung (Enhanced Intel Speedstep & Turbo Boost).

Kernel ist ein mit Backportpatches ausgestatteter 2.6.32 von RedHat. Die genaue Version weiß ich leider auch nicht mehr. Gab vielleicht auch TSC Fixes inzwischen, wer weiß.
Kommentar hinzufügen

* - Pflichtfeld

*

*


*

Kontextspalte