Erreurs de parité observées sur ASR9k

Introduction

Une erreur de parité est une inversion de bit dans la mémoire.  En électronique et en informatique, les interférences électriques ou magnétiques provenant de sources internes ou externes peuvent provoquer le basculement spontané d'un seul bit ou d'une seule mémoire vers l'état opposé.  Cet événement rend les bits de données d'origine non valides et est appelé erreur de parité.  

En général, ces erreurs se répartissent en deux types d'erreurs : les erreurs matérielles et les erreurs logicielles.

Erreurs de parité logicielle, ces événements sont transitoires et aléatoires.  Ils ne seront généralement vus qu'une seule fois dans une banque de mémoire particulière. 

Les erreurs de parité matérielle sont causées par un dysfonctionnement physique du matériel de mémoire ou par les circuits utilisés pour lire et écrire des cellules de mémoire.  Ils sont généralement observés de façon répétée et doivent être remplacés.

La plupart des erreurs de parité sont causées par des conditions environnementales électrostatiques ou magnétiques.  La majorité des erreurs d'événement unique dans les puces mémoire sont causées par : le rayonnement de fond (comme les neutrons des rayons cosmiques, les installations nucléaires), les interférences électromagnétiques (EMI) et la décharge électrostatique.  Ces événements peuvent modifier de manière aléatoire l'état électrique d'une ou de plusieurs cellules mémoire ou peuvent interférer avec les circuits utilisés pour lire et écrire des cellules mémoire. 

Problème

Les erreurs de parité sont une réalité lorsqu'il s'agit de mémoire haute densité, comme c'est le cas avec les cartes de ligne ASR9k.  Donc la façon dont nous les gérons est vraiment tout ce sur quoi nous pouvons avoir le contrôle. Certaines cartes de ligne ASR9k (xmen/typhoon), dans de rares conditions, peuvent rencontrer des erreurs de cache de couche 1.  Ils apparaissent comme un kernel panic dans le cache de données ou le cache d'instructions (DCPERR ou ICPERR). Une autre erreur observée est dans les différentes banques de mémoire utilisées par les processeurs réseau sur les cartes de ligne.  Ces erreurs apparaissent généralement en commençant par les types de journaux d'erreurs suivants :

%PLATFORM-NP-0-NON_RECOVERABLE_SOFT_ERROR

%PLATFORM-NP-3-ECC

%PLATFORM-PFM-0-CARD_RESET_REQ

Le problème ici est le résultat DCPERR/ICPERR dans un rechargement complet de la carte de ligne.  Il en a été de même pour la grande majorité des différentes banques de mémoire NP.  Ce n'est évidemment pas idéal car la plupart des cartes de ligne ont plusieurs NP.  Pourquoi affecter tous les NP sur la carte de ligne si seulement 1 NP a un problème.  

Solution

Pour les erreurs DCPERR et ICPERR observées sur les caches CPU LC typhon, nous avons une solution pour éviter de paniquer et de recharger la carte de ligne.  Ceci est fait avec CSCux30405 . Actuellement intégré dans la version 5.3.3 et plus.  

Pour les mémoires NP, cela devient beaucoup plus compliqué.  Il y a eu un grand effort pour effacer les divers souvenirs pour voir ce que nous pouvons ignorer en toute sécurité ou venir avec un moyen moins impactant de récupérer.  La majorité d'entre eux ont été intégrés dans 5.3.3 et versions ultérieures et il y a eu des SMU de parapluie construits sur la majorité des versions populaires.  

Remarque : cela a également provoqué une garantie de CSCvc69282 où nous pouvons voir un plantage du noyau dû à des interruptions continues.  

Améliorations du traitement des erreurs logicielles NP

Au cours de la dernière moitié de 2015 et au début de 2016, de nombreuses améliorations ont été apportées à la gestion des erreurs logicielles NP pour Typhoon et Tomahawk.    La gestion de nombreuses mémoires différentes a été convertie d'une méthode qui nécessitait un rechargement de carte de ligne à quelque chose de plus gracieux comme la réparation de l'erreur dans la mémoire ou l'exécution d'une réinitialisation rapide NP.     La gestion des erreurs qui n'ont pas d'impact fonctionnel mais qui ne peuvent pas être effacées ("sticky") a également été améliorée afin que les erreurs ne continuent plus à se reproduire.    En outre, plusieurs bogues ont été corrigés, notamment pour les erreurs qui se produisent dans la mémoire d'instructions NP ou dans le TCAM interne.   Environ 80 à 90 % des erreurs non récupérables auparavant sont désormais récupérables et ne nécessitent pas de rechargement de la carte de ligne.

Toutes ces améliorations et ces correctifs sont intégrés dans les versions 5.3.3 et ultérieures.   Les correctifs sont également disponibles dans les SMU de parapluie pour toutes les versions de maintenance majeures :

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