| Notes de version de System Management Services (SMS) 1.5 |     |
| Notes de version de System Management Services (SMS) 1.5 | |
| C H A P I T R E 2 |
|
Bogues identifiés dans SMS 1.5 |
Ce chapitre présente des informations sur les bogues connus de SMS 1.5 et sur ceux qui ont été corrigés dans les patchs SMS prenant en charge le processeur UltraSPARC IV+. Il aborde les sujets suivants :
Cette section répertorie les bogues du logiciel SMS 1.5 et les bogues associés qui ont été corrigés dans les patchs SMS prenant en charge le processeur UltraSPARC IV+.
|
Remarque - Le patch 120648-02 est requis pour assurer la prise en charge du processeur UltraSPARC IV+. |
Le patch 120843-01 améliore le traitement des erreurs et les capacités de récupération d'OpenBoot
PROM en vue d'inclure les processeurs UltraSPARC IV+.
Après l'enfichage à chaud d'une carte dans l'emplacement 1 (c5v0) et le redémarrage du système, prtdiag indiquait la bonne fréquence de bus pour l'emplacement rempli, mais pas pour les emplacements vides. Ce bogue a été corrigé dans le patch n° 120843-01.
Sur les systèmes Sun Fire E25K/E20K sur lesquels sont installées des cartes UltraSPARC IV+ à double noyau, la commande lpost risque d'échouer aux niveaux de diagnostic 64, 96 ou 127. Si ce problème survient, lpost renvoie le message d'erreur suivant :
Le patch 120648-02 corrige ce problème.
La commande hpost du logiciel SMS 1.5 doit être modifiée afin d'assurer la prise en charge des cartes UltraSPARC IV+. Le patch 120648-02 effectue cette modification.
Il se peut que le délai d'attente d'un système Sun Fire E25K/E20K exécutant le SE Solaris 9 4/04 sur une carte UltraSPARC IV+ arrive à expiration suite à la réinitialisation d'un domaine situé sur cette carte. Le système renvoie alors le message d'erreur suivant :
Proccore SB0/P0/C0 timed out on test Domain Advanced Tests id=0x6F. Test Failed.FAIL Proccore SB0/P0/C0: test_seq_cwd(): failed out of config on timeout (Timeout Secs Given: 30) |
Le patch 120648-02 corrige ce problème.
Les premiers processeurs UltraSPARC IV+ conçus pour la clientèle correspondent à la version 2.1.1. Le patch 120648-02 modifie la fonction POST de sorte qu'elle détecte les processeurs antérieurs à la version 2.1, non adaptés à une utilisation commerciale, et les fait échouer au test de configuration.
Sachez qu'il est impossible de différencier les versions 2.1 et 2.1.1 à l'aide de MaskID, qui les interprète toutes deux comme étant classées sous le numéro 2.1. Quant à la fonction POST, elle est capable de différencier les deux versions à partir d'autres informations à caractère électrique.
Ce bogue s'applique uniquement aux cartes UltraSPARC IV+ cadencées à 1 500 MHz. De temps à autre, il peut arriver que la commande marginvoltage exécutée avec l'option -m-1 renvoie une valeur erronée. Si vous exécutez à nouveau cette commande quelques secondes plus tard, elle renvoie alors la valeur correcte. Ce bogue a été corrigé dans le patch n° 120789-01.
Ce bogue s'applique uniquement aux cartes UltraSPARC IV+ cadencées à 1 500 MHz. Lorsque vous utilisez les options -m-1 ou -m+1 avec la commande marginvoltage, le système renvoie un format de sortie incorrect. Par exemple, l'utilisation de la commande -m+1 renvoie une valeur modifiée de Nom (tension) au lieu de Nom+3% (tension) pour les cartes UltraSPARC IV+. Cette commande renvoie toutefois la sortie correcte pour les cartes UltraSPARC IV et UltraSPARC III. Le patch 120789-01 corrige ce problème.
Les processeurs UltraSPARC IV+ comprennent des fonctions de fiabilité, disponibilité et entretien (RAS) et de détection des erreurs supplémentaires par rapport aux modèles UltraSPARC IV et III+. Ce CR a pour objet de décrire une amélioration de la fonctionnalité de disponibilité en vue de diagnostiquer les nouvelles erreurs pouvant être signalées par un processeur UltraSPARC IV+. Grâce à cette amélioration, la fonction de disponibilité est en mesure de diagnostiquer toutes les erreurs fatales relatives à l'ensemble des types de processeurs, de même que les erreurs non fatales survenues sur des domaines Solaris 9. Le patch 120827-01 inclut cette amélioration.
Les puces UltraSPARC IV+ disposent de trois niveaux de cache. Les niveaux 2 et 3 renvoient aux caches de données ; le premier niveau est interne au processeur tandis que le second est externe.
Il arrive qu'une erreur en entraîne une autre, sorte d'effet secondaire. Lorsqu'une erreur survient sur l'un ou l'autre niveau du cache de données, le logiciel de disponibilité diagnostique la cause originelle de l'erreur et écarte l'erreur ou les erreurs secondaires. Cela permet non seulement de favoriser la fiabilité du diagnostic, mais également de garantir qu'un composant victime de l'erreur ne se trouve pas indûment accusé suite à une erreur secondaire. Le patch 120827-01 corrige cette condition.
Sur un système exécutant plusieurs domaines, la commande hwad doit émettre un événement dstop (arrêt de domaine) pour tous les domaines exécutés avant que dsmd puisse récupérer les domaines suite à une condition d'erreur. Étant donné que ces arrêts de domaines sont émis de manière consécutive, un délai sépare le moment de l'émission de l'arrêt de domaine initial du moment où tous les domaines sont récupérés.
Le patch 120789-01 corrige ce problème de manière à émettre les arrêts de domaines en parallèle à l'aide de threads distincts, éliminant ainsi tout délai.
Pour tenir compte du niveau de cache supplémentaire disponible sur les processeurs UltraSPARC IV+, le SERD (Soft Error Rate Discriminator) du SC nécessitait des valeurs de seuil différentes à des fins d'alignement sur les seuils existants sur le domaine Solaris 9. Sans cet ajustement, le domaine met le processeur hors ligne avant l'exécution du diagnostic portant sur le SC et l'état de viabilité du processeur n'est pas mis à jour correctement.
Le patch 120827-01 corrige ce problème en harmonisant les diagnostics entre les deux versions du système d'exploitation et le logiciel SMS 1.5 pour tous les types de processeurs pris en charge.
Cette section recense les principaux bogues affectant le fonctionnement de SMS 1.5.
Si un serveur haut de gamme Sun Fire est exécuté alors que son numéro de série de châssis (CSN, Chassis Serial Number) n'est pas défini sur les contrôleurs système (SC) à l'aide de la commande setcsn, les rapports d'événements FMA (Fault Management Architecture, architecture de gestion des pannes) envoyés à NetConnect suite à l'arrêt d'un domaine (dstop) indiqueront un numéro de série de châssis vide.
Palliatif : exécutez la commande setcsn pour définir le numéro de série du châssis, puis redémarrez SMS. Le numéro de série du châssis ne figure pas dans les rapports d'événements tant que vous ne redémarrez pas SMS.
Pour plus d'informations sur la définition du numéro de série de châssis sur le SC, reportez-vous au Guide d'installation de System Management Services (SMS) 1.5.
Vous pouvez exécuter la commande ndd(1M) en tant que root afin de lire et d'écrire certains paramètres de pilotes de périphérique. scman(7D) (ndd/dev/scman) gère la partie SC des systèmes Sun Fire E25K/E20K du réseau MAN (Management Area Network) et prend en charge la commande ndd(1M).
Si le paramètre man_pathgroups_report de scman(7D) est mal interprété, une erreur d'origine logicielle peut apparaître comme une erreur matérielle grave. De ce fait, on peut faussement conclure qu'il est nécessaire de remplacer le matériel pour corriger ce problème root.
Lorsque le paramètre man_pathgroups_report est spécifié, vous pouvez obtenir une sortie de ce type :
L'astérisque (*) figurant à la dernière ligne indique que « la dernière fois qu'une interface physique hme1 a été utilisée, une erreur a été détectée ». Or, par expérience, nous savons que la majorité des occurrences sont dues à un problème logiciel, pas matériel.
Le logiciel produit une erreur lorsque le pair du réseau MAN ne répond plus aux messages de « pulsation » ou en présence d'une transition d'état dlpi(7P) incorrecte. Il est possible de reproduire à volonté le premier scénario en exécutant la commande suivante en tant que root (en supposant que la sortie exacte présentée ci-dessus a été générée) :
Pour le SC qui exécute la commande (SC0, par exemple), son chemin actif passe de eri0 à hme1. Pendant quelques temps, le contrôleur système SC1 continue à envoyer les paquets à l'interface physique eri0 et le contrôleur système SC0 les transmet à hme1. Après un laps de temps relativement court, les deux contrôleurs sont synchronisés et communiquent alors au moyen de la même interface. Toutefois, un astérisque sera visible (sur chaque SC) pour signaler la dernière interface sur laquelle une erreur est survenue. Dans ce cas, l'erreur est effectivement due à un problème logiciel (autrement dit, l'erreur correspond réellement à une absence de réponse à une séquence de messages de « pulsation »). Il ne s'agit donc pas d'une erreur matérielle fatale.
Un astérisque sera effectivement visible dans la sortie en présence d'une erreur matérielle fatale persistante. Vous ne devez cependant pas supposer que le matériel est la seule origine possible à la présence de cet astérisque.
Cette section résume les erreurs qui figurent dans les pages de manuel et la documentation relatives à SMS 1.5.
Dans la page de manuel marginvoltage, il est écrit :
Les paramètres de marge ne sont pas persistants après les mises sous tension progressives.
Cette affirmation s'applique uniquement aux tensions des noyaux. Tous les autres paramètres sont persistants.
La remarque de la page de manuel rcfgadm(1M) devrait être rectifiée ainsi :
Si la commande rcfgadm échoue, l'état initial d'une carte n'est pas restauré. Un message d'erreur dxs ou dcs est consigné sur le domaine. Si l'erreur est récupérable, vous pouvez tenter à nouveau d'exécuter la commande.
Si le SE Solaris 8 ou Solaris 9 est exécuté sur le domaine, procédez à la vérification suivante :
1. Avant cela, assurez-vous que les entrées dcs suivantes se trouvent dans le fichier de configuration /etc/inetd.conf situé sur le domaine et qu'elles n'ont pas été désactivées.
2. S'il s'agit d'une erreur irrécupérable, redémarrez le domaine pour pouvoir utiliser la carte.
Si le SE Solaris 10 est exécuté sur le domaine, le dcs fait désormais partie du dispositif SMF (Service Management Facility). Effectuez les opérations suivantes :
1. Assurez-vous d'être connecté en tant que superutilisateur (root).
2. Sur le domaine, saisissez la commande suivante à l'invite du système :
3. Si le dcs est désactivé comme illustré dans l'exemple ci-dessus, activez-le en saisissant la commande suivante :
La description de l'option -c figurant dans la page de manuel testemail(1M) devrait être rectifiée ainsi :
Classe de pannes ou liste de classes de pannes séparée par des virgules qu'utilise testemail pour générer un événement.
-c fault_class, fault_class, fault_class
Des exemples de classes de pannes valables sont disponibles dans le fichier intitulé /etc/opt/SUNWSMS/config/SF15000.dict.
La remarque de la section « Description » devrait être rectifiée ainsi :
Lors de l'appel de testemail à l'aide d'une ressource de cache externe, assurez-vous que la carte système comprenant le cache externe est sous tension. À défaut, l'appel de testemail échouera et aucun e-mail ne sera généré.
La description de VCMON devrait être rectifiée ainsi :
Un paramètre de détection des défauts du noyau au niveau de la tension (VCMON) a été ajouté au logiciel SMS. Lorsque VCMON est activé, il contrôle toute modification au niveau de la tension ou de dérives relatives aux processeurs. Si VCMON détecte une hausse de tension (qui indique généralement un problème de connexion de socket), il informe l'utilisateur de ce changement par un événement FMA et signale le statut CHS (Component Health Status, viabilité du composant) du processeur comme étant défaillant.
Dans la description de la commande showboards, l'option -a devrait s'appeler -v.
Dans la description de la commande showenvironment, la catégorie « Device » (Périphérique) aurait dû être supprimée.
Le premier exemple devrait être rectifié ainsi :
showlogs -d indicateur_domaine -p s
Le second exemple devrait être corrigé ainsi :
showlogs -d indicateur_domaine -p c
Les commandes suivantes devraient être ajoutées :
smsinstall : installe le logiciel SMS.
smsupgrade : met à niveau le logiciel SMS existant installé sur un système.
Annexe B (CR 6227544 et 4943474)
Les catégories de messages d'erreur suivantes devraient être ajoutées entre les codes d'erreur 11300 et 50000 :
11500-11699 : Réservés aux messages EFHD
11700-11899 : Réservés aux messages ELAD
11900-12099 : Réservés aux messages ERD
12100-12299 : Réservés aux messages Event Utilities
12300-12499 : Réservés aux messages Wcapp
12500-12699 : Réservés aux messages liés aux ID de FRU
12700-12799 : Réservés aux messages EBD
Le tableau Compatibilité matérielle (Tableau 2-1) devrait recenser Solaris 8 2/02 comme première version du logiciel Solaris 8 prise en charge à la fois par les domaines et les contrôleurs système (SC).
Ce tableau contient une erreur typographique ; il fait référence à un processeur UltraSPARC cadencé à 1,65 MHz. La vitesse correcte est de 1,5 MHz.
Le logiciel SMS 1.5 prend en charge une taille de partition /swap de 2 Go en plus de la taille de 4 Go mentionnée dans le Guide d'installation. Les tailles de partition recommandées pour SMS 1.5 sont les suivantes :
Assurez-vous que SMS est en cours d'exécution avant de désactiver la fonction de basculement.
Pour vérifier que la version 1.2.2 de Java a été installée, exécutez la commande java -version à l'invite du système.
L'étape 3 devrait être rectifiée ainsi :
Exécutez la commande smsupgrade afin de réinstaller SMS.
Assurez-vous que SMS est en cours d'exécution avant d'enregistrer le numéro de série du châssis (CSN).
L'exemple devrait indiquer sc0, pas sc1.
L'exemple de la commande flashupdate ne mentionne pas l'option -f. Il devrait être rectifié ainsi :
-f /opt/SUNWsms/hostobjs/sgcpu.flash
Après l'étape 2, la procédure devrait comprendre une troisième étape. L'étape 3 devrait être rectifiée ainsi :
Mettez à niveau le SE Solaris. Reportez-vous à la section « Installation du SE Solaris sur le SC », page 18 ou « Mise à niveau du SE Solaris sur le SC », page 35.
Une étape 4 devrait figurer après l'étape 3 :
Exécutez smsupgrade afin de réinstaller SMS après une mise à niveau importante du SE (voir page 36). Si tel n'est pas le cas, passez à l'étape suivante et restaurez la configuration SMS.
L'en-tête « Réinstallation du logiciel SMS » devrait être remplacé par « Restauration de la configuration SMS ».
| Notes de version de System Management Services (SMS) 1.5 | 819-3298-11 | |
Copyright © 2005, Sun Microsystems, Inc. Tous droits réservés.