Un bug dans un CPU AMD le fait planter après 1 044 jours

Pierre Dandumont |

Vous ne le savez peut-être pas, mais les CPU ont des bugs. Ils sont généralement documentés par les fabricants — du moins ceux qui vendent leurs CPU, comme Intel ou AMD — et parfois corrigés. Et AMD a un bug particulier dans ses processeurs EPYC 7002 (l'équivalent serveur des Ryzen 3000) : le CPU peut ne plus répondre après 1 044 jours (un peu moins de 3 ans).

Un EPYC Rome (Fritzchens Fritz, CC0)

Les bugs sont courants

Les CPU contiennent des milliards de transistors et peuvent donc avoir des bugs. Pour les corrections, les fabricants ont trois choix : corriger matériellement le CPU avec une nouvelle révision, corriger de façon logicielle le problème avec du microcode ou ne rien faire. Le bug le plus célèbre est évidemment celui du Pentium, dans les années 90 : l'image d'Intel avait été sérieusement écornée à l'époque et avait remplacé les CPU défectueux par une nouvelle révision. Dans certains cas particuliers, les premiers Pentium pouvaient en effet donner une réponse inadéquate à un type de calcul précis, ce qui est évidemment un problème.

Un Pentium touché par le fameux bug (Konstantin Lanzet, CC BY-SA 3.0)

La correction par microcode, plus courante, consiste à passer par du code intégré dans le firmware (BIOS, UEFI, etc.) qui va prendre en charge les bugs. C'est une solution efficace si le bug est rare et n'arrive que dans des conditions extrêmement précises, étant donné qu'il peut y avoir une perte de performances.

Dans le cas du bug d'AMD, la marque indique que le problème ne va pas être corrigé, car le bug reste assez peu probable : même dans les serveurs, un uptime de pratiquement 3 ans demeure finalement assez rare (mais pas improbable). Qui plus est, un redémarrage reste nécessaire de temps en temps pour appliquer les corrections de bugs par microcode.

Pas de correction attendue.

Un problème de temps

Maintenant, d'où vient cette valeur de 1 044 jours ? Probablement de la fréquence du CPU et d'un compteur, selon ce message sur Reddit. En effet, en prenant comme base la fréquence du TSC — Time Stamp Counter, le composant qui compte le nombre de cycles — et en supposant qu'il stocke le nombre de cycles dans une variable flottante en double précision, le nombre de jours est proche de la limite de la variable.

Vous n'avez rien compris ? Expliquons. Le compteur de cycle dépend généralement d'une fréquence de base, qui est souvent de 100 MHz dans un CPU moderne. Chaque cent-millionième de seconde, c'est-à-dire toutes les 10 ns, un compteur est incrémenté. Une variable flottante en double précision contient 64 bits, mais avec une structure particulière : 1 bit pour le signe (+ ou -), 11 bits pour l'exposant et 53 bits pour les données. Avec un compteur de ce type, il est donc possible de compter jusqu'à 9 007 199 254 740 989 (253). Maintenant, prenons ce nombre et faisons le calcul : avec un compteur incrémenté toutes les 10 ns, la valeur maximale est de 1 042 jours et 12 heures environ, un nombre très proche de celui annoncé par AMD. Une fois la valeur dépassée, le compteur repart probablement à 0, ce qui provoque une erreur.

Pourquoi est-ce qu'AMD parle de 1 044 jours et pas 1 042 ? Parce que comme l'explique le document de la marque, la valeur de référence (REFCLK) peut varier légèrement en fonction des cartes mères. Si la fréquence de base attendue est de 100 MHz, elle peut être légèrement plus élevée1 ou plus faible pour des raisons matérielles et donc induire un léger décalage.

Notons enfin qu'Apple a probablement des bugs de ce type dans ses CPU, mais que la documentation n'est pas publique : ce qui se passe chez Apple reste chez Apple.


  1. C'est une astuce assez courante pour grappiller une première place dans des benchmarks, en fournissant une fréquence un rien plus élevée que celle prévue.  ↩︎

Tags
#AMD #CPU #Bug
avatar koko256 | 

"Une fois la valeur dépassée, le compteur repart probablement à 0, ce qui provoque une erreur."
Pas en virgule flottante. La valeur reste constante puisque 1 devient négligeable devant la valeur de la variable.

avatar ech1965 | 

comprends pas l'utilisé du flotttant, le temps élastique ? plus on avance dans le uptime moins on n'aurait besoin de précision ??? ça a peu de sens

avatar R-APPLE-R | 

Obsolescence programmée 😈

avatar Bicus | 

Ah oui, c'est trois ans sans redémarrage...
Bon, ça va, le bug est évitable en redémarrant le serveur tous les deux ans et demi, ça devrait aller ;-)

avatar DG33 | 

Grâce à ce bug on apprend ceci : 1000 et le sens de la vie…

avatar ian38 | 

Article super intéressant… très technique et facile a comprendre en même temps, merci !

avatar Tibimac | 

Et c'est quoi ce(s) cycle(s) qu'un compteur compte ???

avatar Pierre Dandumont | 

C'est juste un compteur pour avoir une base de temps précise. C'est comme ça que l'ordinateur gère l'heure aussi, d'ailleurs.

avatar Tibimac | 

@Pierre Dandumont

L'heure n'est pas gérée par synchro avec des serveur NTP ?

avatar Lightman | 

@Tibimac

Bah non, sinon l'heure de l'ordi serait bonne uniquement au moment de la requête, et figée jusqu'à la suivante.

avatar raoolito | 

chez apple c’est moins grave vu qu’elle vend très peu de serveurs like et que même dans ce cas là au pire c’est un redémarrage inopiné
sur les serveurs de datacenters c.est tout de suite plus gênant

CONNEXION UTILISATEUR