CPU AMD EPYC Rome (Zen 2) : un bug arrive après plus de 1 000 jours sans aucun redémarrage
Le 06 juin 2023 à 05h16
1 min
Sciences et espace
Sciences
Le problème vient du fait que le processeur n’arrive alors plus à quitter l’état de veille CC6, comme le rapporte Tomshardware.com. AMD parle de 1 044 jours d’utilisation non-stop (soit près de trois ans), mais précise que le délai peut un peu varier en fonction de certains paramètres.
AMD ne prévoit pas d’apporter de correctif. Deux solutions de contournement : désactiver le mode de veille CC6 ou redémarrer la machine avant que le bug survienne, le compteur repart alors à zéro.
Le 06 juin 2023 à 05h16
Commentaires (43)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 06/06/2023 à 06h44
Juste pour bien comprendre. Le bogue serait corrigeable logiciellement ? Au niveau du pilote ? Si AMD ne veut pas corriger, est ce que les dév’ des systèmes d’exploitation peuvent corriger le problème de leur côté ?
Le 06/06/2023 à 07h46
Des failles spectre/meltdown, il me semble avoir compris que les OS peuvent incorporer des maj du cpu qu’ils chargent au démarrage (ils passent au cpu la maj qui l’applique jusqu’au prochain redémarrage)
Le 06/06/2023 à 08h05
Les patchs du micro-code, ce n’est pas plutôt le BIOS/UEFI qui le charge au démarrage ? UEFI qui est mis à jour depuis l’OS.
Le 06/06/2023 à 08h36
Possible, je suis pas expert. Peut-être que l’OS passe la modif a l’UEFI qui cole ça au cpu au démarrage.
Le 06/06/2023 à 09h04
Il y a les deux, Microsoft publie régulièrement des mises à jour du microcode pour les CPU Intel. Une comparaison de la révision entre le microcode chargé par l’UEFI et le microcode présent dans System32 est faite au chargement de l’OS, et si la révision dans l’OS est plus récente, le microcode est patché à chaud.
Les différents moments ou un remplacement du microcode est possible sont détaillés ici :
Intel
Pour les OS Windows 10 21H2/22H2, la dernière mise à jour disponible du microcode fournie par Microsoft est consultable ici (mars 2023) :
Microsoft
Le 06/06/2023 à 10h04
Le 06/06/2023 à 07h17
C’est un jour d’Ark qui a découvert le bug?
Le 06/06/2023 à 07h18
Le 06/06/2023 à 07h36
Il se trouve que j’ai une instance Infomaniak public cloud avec précisément un CPU de cette famille.
Elle a planté dimanche dernier avec un message “kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 23s!”
A mon avis il y a un rapport…
Le 06/06/2023 à 07h44
Le 06/06/2023 à 09h02
N’empêche, il faudra attendre trois ans avant de savoir si le patch est bien effectif :smile: Sysadmins, n’oubliez pas de bien documenter cette info
Le 06/06/2023 à 11h23
“Le problème vient du fait que le processeur n’arrive alors plus à quitter l’état de veille CC6”
Mais comment entre-t-il dans cet état CC6 ???
Le 06/06/2023 à 11h41
Inutile d’attendre… y’aura PAS de patch, c’est marqué dans l’article.
Le 06/06/2023 à 12h40
Oh… Euh ?! Oups? Pourtant je n’ai pas d’excuse; ce n’était pas un long texte ;)
Le 06/06/2023 à 11h42
Quand il est en idle probablement, vu que c’est un état de basse consommation.
Le 06/06/2023 à 11h44
C’est là où on se rend compte des énormes progrès de l’informatique.
Windows 95 et Windows 98 plantaient automatiquement au bout de 49.7 jours car un des compteurs qui mesurait le temps était en secondes et était en 32 bits…. (bug logiciel ici)
Le 06/06/2023 à 12h43
Euh sur un int32 signé qui compte les secondes, tu met 68ans et des brouettes hein ;)
Voir le bug de l’an 2038
Le 06/06/2023 à 12h55
2^32-1 ms, ce qui correspond bien à 49.7 jours
Le 06/06/2023 à 13h08
Je me doutais que ça devait être de ms mais :
Autant pour moi autant pour toi autant pour lui :p
Le 06/06/2023 à 13h16
Tu parlais d’int32 signé, ce qui n’est pas le cas non plus
Egalité, balles neuves
Le 06/06/2023 à 13h34
Je viens de faire le calcul, que je n’avais jamais fait auparavant, ayant lu ça dans une vieille vielle news, mais ma calculatrice Xiaomi qui convertit pas mal de trucs m’affirme que
4294967296 secondes (2^32) = 49,71 jours…
Le 06/06/2023 à 13h47
Edit : Oups je refais mon calcul
Le 06/06/2023 à 13h53
4294967296s /60 = 71582788min
/60 = 1193046h
/24 = 49710jours
/365 = 136ans
Ok je le suis permis de faire sauter les décimales, mais je crois que tu peux changer de calculatrice
Le 06/06/2023 à 14h21
86400 secondes par jour.
Multiplié par 49 ça donne 4 millions et des brouettes au doigt mouillé.
2^32 c’est de l’ordre de 4 milliards (4 teras), soit 1000 fois plus, c’est donc des millisecondes.
Le 06/06/2023 à 14h25
Ma calculatrice sous Android est en mode US, et elle m’avait affiché 49,710 mais bêtement sur ce coup là j’avais oublié que c’était en mode US cad 49 710 …
Le 06/06/2023 à 14h58
Euureur de débutant
Pour l’anecdote il existe aussi un système de date qui compte le nombre de nanosecondes depuis le 1er janvier 1600, c’est une horreur ^^
Le 06/06/2023 à 16h46
On parlerait de…. Windows par hasard ?
“Les systèmes Windows NT, jusqu’à et y compris Windows 11 et Windows Server 2022, mesurent le temps comme le nombre d’intervalles de 100 nanosecondes qui se sont écoulés depuis le 1er janvier 1601 à 00:00:00 UTC, faisant de ce moment l’époque de ces systèmes.”
(Source: Wiki)
Le 06/06/2023 à 21h14
Oui en effet mea culpa, des centaines de nanosecondes depuis le 1er janvier 1601. À la base je suis tombé là dessus dans les timestamp des bdd de PCVue et à l’époque j’ai codé un convertisseur en rageant après l’éditeur contre cette unité de
avant de me rendre compte que c’était un “standard”.
Par contre jsuis choqué d’apprendre que Windows utilise pas le temps POSIX, je croyais que les 100ns étaient juste utilisées dans des vieux systèmes de fichiers de windows mais ma mémoire a du me jouer un tour..
Le 07/06/2023 à 05h05
Heureusement que maintenant les IBM-PC Compatibles XT et AT ont un peu plus que 640Ko de mémoire pour pouvoir compter tout ça.
Mais L’an 1601, sérieusement ?? Il s’est passé un truc important juste après cette date ??
Des fichiers NTFS créés au 17e siècle, ça doit pas courir les rues… 😜
Le 07/06/2023 à 08h05
Ce doit être pour pouvoir dater tous les événements de l’histoire des USA. Dans mes souvenirs les Pilgrims fathers datent de cette époque (début XVIIe je crois).
Le 07/06/2023 à 10h34
)
Le 07/06/2023 à 10h55
D’après l’ami wiki :
Le 07/06/2023 à 13h22
Le 06/06/2023 à 13h41
Autant pour moi, confusion entre le point et la virgule.
Le 06/06/2023 à 13h43
Et oui, malheureusement le temps écoulé ne va que dans un seul sens….
Le 06/06/2023 à 13h56
Certes ^^
Après quand tu sais que le bug de 2038 sera provoqué par les système qui codent leur timestamp sur des signés… Retour vers le passé!! X)
Le 06/06/2023 à 14h34
Ha oui en effet, je viens de lire la page Wiki sur Y2038 bug avec des entiers signés.
Pour info dans Excel, toutes les dates sont systématiquement convertis en secondes en partant du 1 Janvier 1900 pour ensuite être manipulées.
Le 06/06/2023 à 12h23
De la part d’AMD. Rien ne dit qu’aucun éditeur logiciel ne va pas s’y atteler.
Le 06/06/2023 à 15h22
https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf
Voir errata 1474 tout à fait à la fin du doc. Le pb semble lié à la reference clock (et le délai réel doit donc pouvoir varier un peu), peut-être lié à des tailles de compteur de perf ou autre dont on ne sait gérer un rebouclage quand on est dans un état de veille profond, donc a priori pb matériel et sans correctif via un firmware quelconque lié au power management par exemple: Juste désactiver l’état de veille qui pose pb si on veut faire des records d’uptime!
Le 06/06/2023 à 21h25
Bon ben du coup je me réponds à moi même : le vieux système de fichier qui utilise cette notation de temps n’est autre que… NTFS
Le 07/06/2023 à 05h17
Et je suppose que l’ironie sous jacente de ta phrase n’était pas du au hasard…
“Vieux système” & “NTFS”
Le 07/06/2023 à 07h25
Bah c’est comme ce qu’on appelle l’époque contemporaine qui date pourtant du 18ème au 20ème siècle, alors que par définition quelque chose de contemporain ne peut pas être passé.
C’est toujours le problème quand on utilise des qualificatifs temporels pour nommer les choses, passé un certain temps ça ne veut plus rien dire.
Le 07/06/2023 à 10h35