Auf ASR9k wurden Paritätsfehler erkannt.

Einleitung

Ein Paritätsfehler ist ein Bit-Flip im Speicher.  In der Elektronik und der Computertechnik können elektrische oder magnetische Störungen von internen oder externen Quellen dazu führen, dass ein einzelnes Bit oder ein einzelner Speicher spontan in den entgegengesetzten Zustand wechselt.  Dieses Ereignis macht die ursprünglichen Datenbits ungültig und wird als Paritätsfehler bezeichnet.  

Normalerweise fallen diese Fehler in zwei verschiedene Arten von Fehlern, weich und hart.

Weiche Paritätsfehler: Diese Ereignisse sind vorübergehend und zufällig.  Sie werden in der Regel nur einmal in einer bestimmten Speicherbank angezeigt. 

Harte Paritätsfehler werden durch eine physikalische Fehlfunktion der Speicherhardware oder durch die zum Lesen und Schreiben von Speicherzellen verwendete Schaltung verursacht.  Diese treten in der Regel wiederholt auf und müssen ersetzt werden.

Die meisten Paritätsfehler werden durch elektrostatische oder magnetbezogene Umgebungsbedingungen verursacht.  Die meisten Einzelereignisfehler in Speicherchips werden durch Hintergrundstrahlung (wie Neutronen kosmischer Strahlung, Kernanlagen), elektromagnetische Interferenz (EMI) und elektrostatische Entladung verursacht.  Diese Ereignisse können den elektrischen Zustand einer oder mehrerer Speicherzellen zufällig ändern oder die zum Lesen und Schreiben von Speicherzellen verwendete Schaltung stören. 

Problem

Paritätsfehler sind eine Tatsache, wenn es um Arbeitsspeicher mit hoher Dichte geht, wie sie auf den ASR9k Linecards verwendet werden.  Wie wir mit ihnen umgehen, ist wirklich alles, was wir kontrollieren können. Bei einigen ASR9k-Linecards (xmen/typhoon) können in seltenen Fällen Cache-Fehler in Layer 1 auftreten.  Diese werden als Kernel-Panic im Daten-Cache oder Instruktions-Cache (DCPERR oder ICPERR) angezeigt. Ein weiterer beobachteter Fehler tritt in den verschiedenen Speicherbanken auf, die von den NPs (Netzwerkprozessoren) auf den Linecards verwendet werden.  Diese werden in der Regel ab den folgenden Arten von Fehlerprotokollen erkannt:

%PLATFORM-NP-0-NON_RECOVERABLE_SOFT_ERROR

%PLATFORM-NP-3-ECC

%PLATTFORM-PFM-0-CARD_RESET_REQ

Das Problem hierbei ist, dass DCPERR/ICPERR zu einem vollständigen Linecard-Neuladen führen.  Dasselbe gilt auch für die große Mehrheit der verschiedenen NP-Speicherbanken.  Dies ist natürlich nicht ideal, da die meisten Linecards mehrere NPs haben.  Warum sollten alle NPs auf der Linecard betroffen sein, wenn nur bei einem NP ein Problem auftritt?  

Lösung

Für die DCPERR- und ICPERR-Fehler, die auf den Taifun-LC-CPU-Caches zu sehen sind, haben wir eine Lösung, um Panik zu vermeiden und die Linecard neu zu laden.  Dies geschieht mit CSCux30405 . Derzeit integriert in Version 5.3.3 und höher.  

Für die NP-Speicher wird das viel komplizierter.  Es gab eine große Anstrengung, die verschiedenen Erinnerungen zu schrubben, um zu sehen, welche wir sicher ignorieren können oder mit einem weniger beeinflussenden Weg zu erholen kommen.  Die meisten davon wurden in Version 5.3.3 und höher integriert, und es gab Umbrella SMUs, die auf den meisten populären Versionen aufgebaut waren.  

Hinweis: Dies hat auch eine Sicherheit von CSCvc69282 verursacht wo wir einen Kernel-Absturz aufgrund von fortgesetzten Unterbrechungen sehen können.  

Verbesserungen bei der Behandlung von weichen NP-Fehlern

In der letzten Jahreshälfte 2015 und Anfang 2016 wurden zahlreiche Verbesserungen bei der Behandlung von weichen NP-Fehlern sowohl für Typhoon als auch für Tomahawk vorgenommen.    Die Verarbeitung für viele verschiedene Speicher wurde von einer Methode, die ein Linecard-Neuladen erforderte, in etwas anmutigeres umgewandelt, wie z. B. das Reparieren des Fehlers im Speicher oder das Durchführen eines schnellen NP-Resets.     Auch die Handhabung von Fehlern, die keine funktionalen Auswirkungen haben, aber nicht gelöscht werden können ("klebrig"), wurde verbessert, sodass die Fehler nicht mehr weiter auftreten würden.    Darüber hinaus wurden mehrere Fehler behoben, insbesondere bei Fehlern, die im NP-Befehlsspeicher oder im internen TCAM auftreten.   Etwa 80-90 % der zuvor nicht behebbaren Fehler können jetzt behoben werden, sodass kein erneutes Laden der Linecards erforderlich ist.

Alle diese Verbesserungen und Korrekturen sind in Version 5.3.3 und höher integriert.   Die Fehlerbehebungen sind auch in Umbrella SMUs für alle wichtigen Wartungsversionen verfügbar:

434 - CSCux16975
512 - CSCux44633
513 - CSCux16975
531 - CSCux34531
532 - CSCux78563