SGI Octane
Silicon Graphics, Inc., ou SGI. Quelle entreprise technologique évoque autant de nostalgie à la simple prononciation de son nom ?
Ce constructeur malheureusement défunt est tout simplement légendaire pour les personnes nées dans les années 80 et 90 un tant soit peu amateures de cinéma et d’informatique. Tous les films à effets spéciaux de ces années sont liés de près ou de loin à cette marque : Terminator 2 et son T1000 qui se liquéfie, Jurassic Park, Toy Story, Titanic… pour n’en citer que quelques-uns, sont tous liés à SGI.
Je recommande d’ailleurs cet article pour comprendre pourquoi Jurassic Park fut une révolution d’un point de vue des effets spéciaux, et est encore aujourd’hui absolument incroyable pour tout passionné d’informatique de ces années.
C’est aussi à SGI que l’on doit le jeu sur Super Nintendo Killer Instinct, qui a clairement donné une nouvelle jeunesse à cette console, avant de collaborer plus étroitement avec Nintendo pour créer la console Nintendo 64.
Maintenant, attaquons les choses sérieuses. Dans cet article, je m’attaque à du lourd : ma station Silicon Graphics Octane. Le sommet de ma collection. Mais aussi celle qui m’aura donné le plus de fil à retordre dans cette suite d’articles où je remets en route mes vieilleries. Je vous laisse découvrir pourquoi dans la suite, mais j’en aurai eu avec elle, des frayeurs et des bizarreries.
Il y a 20 ans, vers 2006, peu après avoir acheté mon Octane, j’ai assez rapidement upgradé la machine : ajout de mémoire à 1.5Go, upgrade de processeur : d’un simple R12000 à 300MHz j’étais passé à un module Dual R12000/300. Mais aussi disque dur supplémentaire, et finalement, remplacement de la carte graphique d’origine ESI (SE) par les plus récentes et beaucoup plus puissantes VPro V6. Les cartes de la gamme VPro, nom de code Odyssey, implémentent en hardware OpenGL 1.2 (norme dont on doit d’ailleurs l’existence à SGI eux-mêmes). C’est dire à l’époque, le monstre de puissance qu’elle représentait.
Mais assez rapidement, j’ai commencé à avoir des kernel panic étranges… La machine était parfaitement stable 99% du temps
mais sur des tâches très particulières, comme lire un gros film DivX avec MPlayer, plantage.
Je jouais à Quake III Arena, aucun problème, Photoshop, navigation sur Internet avec Firefox (qui était encore à peu près léger à l’époque…) aucun problème, sauf MPlayer qui déclenchait ce fameux bug lorsque je lisais un gros fichier.
A l’époque je n’y faisais pas trop attention, j’installais et mettais à jour pas mal de Nekoware (communauté SGI aujourd’hui disparue, proposant quantité de packages de logiciels libres précompilés pour IRIX), je me disais que ça devait être MPlayer qui était compilé avec une mauvaise option, ou ce genre de problème logiciel/système, car après tout… je n’avais aucun autre problème avec le reste.
Et puis… en rallumant ma brave Octane, 20 ans après les premiers plantages, malheureusement rien n’a changé. Toujours les mêmes kernel panic.
PANIC: CPU 0: Cache Error ([...] Multiple cache errors in same unit detected) Eframe = [...]Alors après avoir écumé les forums des communautés SGI, et demandé conseil à mon nouveau copain Gemini, avec le message exact du kernel panic… tout semble pointer un module SRAM du processeur qui serait HS : peut-être des soudures au niveau de ce module qui ont travaillées, un peu faiblardes avec le temps… et certaines tâches bien particulières feraient chauffer ces contacts plus qu’à l’habitude, et déclencheraient les erreurs de cache.
On peut notamment pointer ce thread extrêmement détaillé avec une tentative veine de réparation ou ce second problème.
Et puis chose que je n’avais pas faite à l’époque, IRIX possède une commande qui permet de faire tourner les process sur un CPU en particulier, au lieu de laisser le scheduler choisir. Exemple pour faire fonctionner MPlayer sur le CPU 1 :
runon 1 mplayerEt en effet, le verdict est sans appel : MPlayer sur le CPU 0 : kernel panic au bout de quelques secondes. MPlayer sur le CPU 1 : aucun souci. Non seulement j’ai un problème avec mon module CPU, mais c’est le 0 qui pose problème.
Note : la documentation SGI fait aussi référence à la commande PROM enable/disable n (où n est le CPU que l’on souhaite activer ou désactiver. Mais l’Octane refuse de booter sans le CPU 0. J’imagine que l’on peut tout de même désactiver le CPU 1, mais cette fonctionnalité semble surtout avoir été développée pour les machines très haut de gamme avec de nombreux CPU.
Alors maintenant, la grande question, comment trouver en 2026 un nouveau module CPU SGI pour Octane, de puissance correcte et sans vendre un organe… Je parcours rapidement les sites d’annonces (eBay était une vraie mine d’or dans les années 2000-2010), mais sans grand succès. Alors la carte Joker, je décide de contacter la légende du matériel SGI depuis au moins 30, l’homme dont la réputation n’est plus à faire, Ian Mapleson et son SGI Depot, en Ecosse.
Miraculeusement, il restait à Ian un module Single R12K/400 à très bon prix. Par rapport à mon module Dual R12K/300, plus de puissance brute sur les tâches monothread (l’essentiel de mon utilisation à vrai dire) et moins de puissance sur les tâches parallélisées. Un bon compromis, et surtout une solution pour voir le bout du tunnel avec cette machine !
Donc je commande, expédition super rapide, Ian est quelqu’un d’extrêmement sympathique et je comprends pourquoi il est si apprécié dans la communauté SGI. Au bout de quelques jours, le processeur est dans ma boîte aux lettres.
Je teste, et voilà qu’un bug de 20 ans est enfin résolu ! Plus aucun plantage. Je m’en veux, parce que si j’avais fait plus attention, peut-être en testant plus intensément le processeur lorsque je l’ai acheté… j’aurais constaté le problème, et j’aurais pu le renvoyer au vendeur ! C’était peut-être même pour ça qu’il s’en débarrassait !
Et là vous vous dites, c’est la fin de l’article, voilà, l’Octane est repartie, tout fini bien ! Et bien pas tout à fait… j’ai une histoire supplémentaire incroyable !
En fouillant dans mon bor…bazar dans mon grenier, bazar qui s’était entassé suite à mon dernier déménagement… je retrouve les jours-ci deux gros disques 15k tr/min de 146GB, dont je ne me rappelais même plus l’existence.
Je me dis donc, aller, je les installe dans l’Octane. Elle a un nouveau processeur qui fonctionne au top, on va lui offrir deux gros disques rapides, avec une fresh install d’IRIX 6.5.30, ça va pulser !
Et puis pour faire les choses bien, j’ai des plaques métalliques de refroidissement, qui se vissent sous les disques, récupérées sur des disques durs Sun. Je les installe donc sur mes « nouveaux » disques, parce que 15k tr/min, ça va chauffer… déjà que l’Octane chauffe pas mal de base. Et pour aller au bout des choses, je ne superpose pas les disques, je laisse le disque système à l’emplacement 1, tout en bas, et le second disque à l’emplacement 3, tout en haut.
Bref, j’installe IRIX 6.5.30, dernière version, cutting edge de 2006… et avec des disques aussi gros, je stocke l’ensemble de l’archive des Nekowares, et je commence à installer tout ce donc j’ai besoin : MPlayer (le fameux), Quake 3, zsh, sudo, OpenSSH… et quelques bricoles.
Et là, heureux d’avoir une conf stable, enfin, plus de kernel panic… la joie est de courte durée, parce que je commence à avoir plein de flickering à l’écran. Je n’ai pas pris de photo, mais en gros, très fréquemment, et surtout quand je lance des applis graphiques, OpenGL… comme… mplayer… ou Quake 3, apparaissent à l’écran le genre des parasites du style de la photo ci-contre.
Maintenant que le processeur est OK, ce n’est quand même pas la carte graphique qui est HS !!! Alors je teste tout, je change d’écran, pareil, le câble, pareil, je teste différentes résolutions, fréquences, nombre de couleurs, etc. En 1024×768 tout semple plutôt stable, par contre en 1280×1024, une calamité, quasiment inutilisable.
Et là, je commence à douter. Le matin après avoir installé le nouveau processeur, étant donné que j’allais réinstaller IRIX, j’ai voulu faire un test. J’ai essayé de passer la machie en dual head, en ajoutant à la VPro V6, l’ancienne carte graphique ESI d’origine. Car certains parlent de cette possibilité sur Octane… qui n’est pas supportée officiellement, mais ça fonctionnerait. Mais hélas, les différentes pistes trouvées sur internet ne mènent nulle part :
– à l’installation d’IRIX, uniquement les pilotes correspondant à la carte graphique installée dans la machine sont installés (la V6),
– puis, si on installe la seconde carte ESI, c’est celle-ci qui est préférée pour l’affichage du démarrage. Donc quand IRIX boot, il n’a pas les pilotes pour cette carte, et ne lance pas l’affichage.
Sur différents forums ou sites spécialisés, certains parlent de la possibilité de réinstaller manuellement les autres pilotes, mais « Inst », l’outil de gestion de paquets d’IRIX semble filtrer les pilotes pour la carte graphique présente, et rien d’autre. Donc il y aurait éventuellement deux pistes :
– démarrer la machine avec les deux cartes présentes sans clavier/souris pour basculer sur le port série. Et installer les pilotes qui manquent, en espérant qu’IRIX installe les deux.
– Faire une fresh install d’IRIX sur la carte ESI, en espérant aussi qu’IRIX installe les deux pilotes.
Mais tout ceci n’ayant jamais été supporté par SGI, je me suis dis que ce n’était peut-être pas l’idée du siècle que de faire ces expérimentations et chercher les problèmes.
Donc après cette petite parenthèse, maintenant que j’ai mes soucis de flickering à l’affichage, je m’inquiète d’avoir abîmé quelque chose sur ce fragile matériel. Notamment les connecteurs de compression à l’arrière des cartes sont extrêmement fragiles. Ces connecteurs dorés, sans « pins », relient les différentes cartes au XIO, qui est le bus au fond du boîtier.
Alors là, gros moments de doutes, je ne comprends plus rien. L’affichage est totalement instable, alors qu’il fonctionnait encore correctement quelques heures avant. Donc je démonte les disques, et je remets celui d’origine, avec ma vieille installation, pour voir si le problème est toujours là.
Et là, miracle : plus de problème !
Premièrement je suis rassuré, la carte graphique n’est pas HS (parce que c’est absolument introuvable aujourd’hui si on est pas prêt à vendre un rein).
Et puis on progresse : avec l’ancien disque, tout fonctionne parfaitement. Donc, essayons juste un seul « nouveau » disque de 15k tr/min. Peut-être que les deux en même temps pompent trop de courant et déstabilisent l’alimentation. Chose qui visiblement se produit fréquemment (si vous connaissez les forums Doctissimo, on peut aussi vite se faire peur sur les forums SGI…).
Mais… j’avais remarqué que la plaque de refroidissement passait juste juste sur le disque système qui est dans la position 1, en bas… et que cette plaque frottait à l’insertion du disque contre le châssis. Dans le doute, je l’enlève, je remets juste le disque dur système, et je redémarre.
Bingo, plus de problème.
Du coup, soyons fous, remettons les deux disques 15k tr/min (en enlevant aussi la plaque thermique du second disque)… et ça continue de fonctionner parfaitement !!!
Donc quoi penser ?
– soit la plaque touchait le châssis et me générait un souci électrique : masse, court-circuit… fort probable…
– ou alors, autre éventualité, la plaque faisait « antenne » et amplifiait ce que le disque produisait comme signaux électro-magnétiques, et venait perturber la CG…
Dans l’un ou l’autre cas, NE METTEZ PAS DE PLAQUES DE REFROIDISSEMENT SUR VOS DISQUES DANS UNE OCTANE !
Quelle histoire, je n’arrive toujours pas à y croire. Durant des heures on peut chercher un problème en étant persuadé qu’il est logiciel ou système. Alors qu’il est purement matériel.
Ce sera la morale de cet article un peu long, mais fort enrichissant. Je suis tout de même sacrément content, parce que mon Octane aura passé 6 ans au grenier avec des hivers à -10°… et au final elle n’a pas plus de dégât qu’à l’époque.
Et mieux, 20 ans plus tard, tout est résolu.
La suite des aventures du musée au prochain épisode 🙂