Le dernier guide de révision du processeur d’AMD pour les puces de serveur EPYC 7002 « Rome » révèle un nouveau bogue intéressant (errata) qui peut provoquer le blocage d’un cœur de la puce après 1 044 jours de disponibilité (~ 2,93 ans), après quoi vous devrez réinitialiser le serveur pour que la puce fonctionne correctement. AMD dit qu’il ne résoudra pas le problème.
La description par AMD du problème, qui affecte ses processeurs EPYC de deuxième génération (les puces Genoa de quatrième génération d’AMD sont les plus récentes), est succincte, mais il y a beaucoup à déballer.
Le problème provient du fait que le cœur ne parvient pas à quitter l’état de veille CC6, mais AMD indique que le moment de l’échec peut varier en fonction du spectre étalé et de la fréquence REFCLK, cette dernière étant l’horloge de référence qui aide la puce à suivre le temps.
L’utilisateur de Reddit, acid_migrain, a une théorie plausible sur le moment exact où le noyau se bloque, en disant : « Malgré ce qu’ils disent, le problème se manifeste en fait à 1042 jours et environ 12 heures. Le TSC fonctionne à 2800 MHz et 2800 * 10 * 1042,5 jours équivaut presque à 0x380000000000000, ce qui contient trop de zéros pour ne pas être une coïncidence. »
La solution de contournement est simple : soit redémarrer avant 1 044 jours de disponibilité, ce qui réinitialise le processeur pour redémarrer votre « minuterie » de 1 044 jours, soit désactiver l’état de veille CC6.
Maintenant, bien que ce bogue de plantage de base de 2,93 ans soit intéressant, la question est de savoir s’il est vraiment important. Bien sûr, c’est important, malgré le fait que les mises à jour de sécurité et la maintenance doivent être effectuées en grande partie, beaucoup intervalles plus courts.
Le scénario le plus réaliste serait simplement ceux qui utilisent la fonctionnalité de correctifs en direct de Linux ou kexec pour mettre à jour sans redémarrer – cela pourrait certainement conduire au type de disponibilité prolongée qui déclencherait le bogue. De plus, les serveurs pour les applications critiques connaissent souvent une disponibilité prolongée.
Bien que ce bogue soit intéressant, ce n’est pas un obstacle pour la majorité des utilisateurs, et les errata dans les puces ne sont certainement pas inhabituels. Les processeurs modernes sont les appareils les plus complexes construits par l’humanité, et ils arrivent presque toujours sur le marché avec de nombreux errata/bugs découverts pendant ou après que les puces aient atteint leur révision d’expédition finale (stepping). Voici un peu plus à ce sujet.
Chip Errata est commun, mais pas génial
Avec des milliards de transistors en jeu, les problèmes sont inévitables : il n’est pas rare qu’une puce ait un millier d’errata/bogues ou plus qui sont corrigés dans les nouvelles étapes de la puce ou avec des ajustements du micrologiciel avant le lancement. Ces errata peuvent englober tous les types de bogues, des failles de sécurité aux drapeaux défectueux et aux balises de cache qui ne fonctionnent pas correctement, et les fabricants de puces font de leur mieux pour les éliminer avant le lancement.
Cependant, certains errata subsistent toujours, même dans l’expédition des puces. Par exemple, la 8e génération d’Intel a plus de 150 errata répertoriés qui restent, et ces puces ont été lancées en 2017. Nous ne savons pas combien d’errata les puces Rome ont eu parce qu’AMD a supprimé les listes d’errata qui ont été résolus. . Cependant, nous savons qu’il reste 39 errata, ce qui ne semble pas trop mal dans le contexte d’Intel.
Certains errata ne sont pas réparés simplement parce qu’ils ne causent aucun dommage, mais à part les errata critiques qui pourraient laisser un vecteur d’attaque ouvert, certains errata liés à la fonctionnalité ne sont tout simplement jamais corrigés. Le fabricant de puces évalue des facteurs tels que la gravité de l’errata, la facilité de résolution du problème et s’il existe même un nombre suffisamment important d’errata pour justifier une autre étape – ce n’est pas une tâche anodine. D’autres bogues peuvent être corrigés avec des correctifs logiciels ou micrologiciels, mais encore une fois, cela n’en vaut pas toujours la peine, ou pire, le correctif pourrait entraîner une perte de performances, donnant aux fabricants de puces un autre facteur à peser.
Pourquoi AMD ne l’a-t-il pas trouvé plus tôt ? Eh bien, 2,93 ans, c’est plus long que les cycles de validation et de qualité, et il n’est pas clair si les tests de vieillissement accéléré, qui impliquent souvent de tester l’équipement à des températures plus élevées que d’habitude sur de longues périodes pour simuler le processus de vieillissement, pourraient attraper le bogue non plus. Les puces AMD EPYC Rome ont été lancées fin 2018, alors peut-être que certains clients d’AMD ont déjà rencontré le problème à la dure – lors du déploiement.
EPYC Rome expulsé du Uptime Club
Et puis il y a les gens qui veulent juste rejoindre le club de disponibilité et établir un record. Pour ce faire, vous devez battre l’ordinateur à bord du vaisseau spatial Voyager 2. Ouais, celui qui a été le deuxième à entrer dans l’espace interstellaire. Cet ordinateur fonctionne depuis 16 735 jours (plus de 48 ans) et ça continue.
Pour les records terrestres, 6 014 jours (16 ans) semble être le record pour un serveur, mais j’ai vu beaucoup de débats sur d’autres prétendants à la couronne. (La petite communauté /r/uptimeporn/Reddit a de nombreux exemples de disponibilités prolongées.)
Dans les deux cas, vous ne pourrez battre ce type de record avec aucune des puces EPYC Rome – cet errata ne sera pas corrigé, donc tous vos cœurs ne dépasseront pas de beaucoup le seuil de 1 044 jours en aucune circonstance. La note d’AMD indique que cela ne résoudra pas le problème – peut-être que la société a décidé que le problème était trop coûteux à résoudre dans le silicium, ou qu’un correctif de microcode/firmware a trop de surcharge de performances, ou peut-être qu’il n’y a tout simplement pas assez de clients impactés pour faire le fixer utile.
Dans les deux cas, la désactivation de l’état de veille CC6 du serveur aidera toi dormir la nuit, ou vous pouvez simplement vous assurer de redémarrer tous les 1 000 jours environ.