Accueil Astuces et Informations Les processeurs AMD EPYC 7002 gelaient après 1044 jours de fonctionnement en...

Les processeurs AMD EPYC 7002 gelaient après 1044 jours de fonctionnement en raison d’un bogue

4
3
Error AMD Epyc

Le problème est lié au fait que le noyau ne sort pas du mode économie d’énergie

Récemment des informations ont été publiées sur un bogue btout à fait particulier dans la série des processeurs pour serveurs AMD EPYC 7002 (« Rome ») basé sur la microarchitecture « Zen 2 » distribuée depuis 2018.

Et c’est qu’il s’agit de l’arrêt provoque le blocage du processeur après 1044 jours de fonctionnement continue (une situation assez particulière et qui est assez rare.

Un court message de AMD indique que les processeurs de serveur de 2e génération rencontrent un problème Quoi empêche les cœurs de quitter le mode d’économie d’énergie Core C6 State (ou CC6) après un long cycle de fonctionnement. Dans le même temps, le fabricant a affirmé que 1044 jours n’est pas une valeur absolue, car la panne peut survenir plus tôt ou plus tard, car tout dépend de la fréquence de REFCLK, qui permet aux processeurs de suivre le paramètre de temps et certains autres facteurs. Mais le fabricant ne fournit aucune information exacte sur la raison de la panne, de sorte que personne ne comprend exactement quelle est la cause de la panne jusqu’à présent.

Échec en tant que tel, il met le processeur en mode “zombie”dans lequel il n’accepte aucune commande ou demande d’interruption externe et reste dans cet état jusqu’à ce qu’il soit redémarré.

Ces modes d’état C commencent à C0, qui est le mode de fonctionnement normal de la CPU. Plus le nombre C est élevé, plus le processeur passe en mode veille et plus les signaux sont désactivés. Plus l’état de veille est profond, plus il faut de temps au processeur pour se réveiller complètement.

Avec ce bogue, une fois qu’un processeur entre dans C6 après la marque des 1044 jours, il reste bloqué et nécessite un redémarrage. La solution consiste à redémarrer le serveur avant trois ans ou à désactiver l’état de veille à l’origine de l’erreur.

AMD ne fournit pas d’explication plus détaillée de la cause de la panne. À en juger par la supposition publiée sur Reddit :

Le blocage se produit lorsque le compteur dans le registre TSC (Time Stamp Counter), qui compte le nombre de cycles de travail après la réinitialisation, à une fréquence de 2800 MHz atteint la valeur 0x380000000000000 (2800 MHz * 10 * * 6 * 1042, 5, c’est-à-dire après 1042 jours et 12 heures).

En plus de ça, AMD a mentionné que le correctif de bogue ne sera pas publiécar le problème est passé inaperçu pendant longtemps car les temps de disponibilité pluriannuels ne sont pas typiques pour les serveurs qui doivent être périodiquement redémarrés pour installer les mises à jour du noyau ou migrer vers une nouvelle version du système d’exploitation pour rester à jour.

Cependant, les méthodes de mise à niveau du noyau sans redémarrage des distributions Linux et les longs cycles de maintenance (Ubuntu, RHEL et SUSE sont sauvegardés pendant 10 ans) peuvent entraîner de longs temps d’attente pour les serveurs sans redémarrage.

Les représentants de l’entreprise ont déclaré qu’actuellement Il y a deux options pour résoudre le problème : lLes propriétaires de serveurs sur ces processeurs doivent redémarrer le système pour réinitialiser la minuterie à 1044 joursDésactivez donc complètement le mode d’économie d’énergie de Core C6 State. Probablement, les deux options sont très inadaptées aux propriétaires de processeurs de serveur – le mode d’économie d’énergie, car il permet d’économiser beaucoup d’argent sur la consommation d’énergie, donc évidemment personne ne l’éteindra et attendra qu’une erreur se produise et qu’il se fige, puis redémarre le système n’est pas non plus une solution très pratique. Surtout quand il s’agit de composants d’infrastructure vraiment importants.

Il est important de mentionner que ce type d’erreurs n’est pas rare dans le segment des processeurs (peu importe s’ils sont destinés aux serveurs ou aux ordinateurs de bureau), car les modèles commerciaux contiennent souvent de nombreux bogues, mais ils essaient ensuite de les corriger avec une nouvelle révision ou avec des correctifs basés sur des logiciels et des micrologiciels.

Finalement Si vous souhaitez en savoir plus, Je vous invite à consulter les informations publiées par AMD.