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.
Commentaires (43)
#1
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é ?
#1.1
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)
#1.2
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.
#1.3
Possible, je suis pas expert. Peut-être que l’OS passe la modif a l’UEFI qui cole ça au cpu au démarrage.
#1.4
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 : https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html
Pour les OS Windows 10 21H2/22H2, la dernière mise à jour disponible du microcode fournie par Microsoft est consultable ici (mars 2023) : https://answers.microsoft.com/en-us/windows/forum/all/microsoft-released-intel-processors-microcode/b28f39bb-f3be-4717-996d-9d1e39dc54ab
#1.5
#2
C’est un jour d’Ark qui a découvert le bug?
#3
#4
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…
#5
#6
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
#7
“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 ???
#8
Inutile d’attendre… y’aura PAS de patch, c’est marqué dans l’article.
#8.1
Oh… Euh ?! Oups? Pourtant je n’ai pas d’excuse; ce n’était pas un long texte ;)
#9
Quand il est en idle probablement, vu que c’est un état de basse consommation.
#10
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)
#10.1
Euh sur un int32 signé qui compte les secondes, tu met 68ans et des brouettes hein ;)
Voir le bug de l’an 2038
#10.2
2^32-1 ms, ce qui correspond bien à 49.7 jours
#10.3
Je me doutais que ça devait être de ms mais :
Autant pour moi autant pour toi autant pour lui :p
#10.4
Tu parlais d’int32 signé, ce qui n’est pas le cas non plus
Egalité, balles neuves
#10.5
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…
#10.8
Edit : Oups je refais mon calcul
#10.9
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
#10.11
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.
#10.12
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 …
#10.14
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 ^^
#10.15
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)
#10.16
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..
#10.17
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… 😜
#10.18
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).
#10.19
)
#10.20
D’après l’ami wiki :
#10.21
#10.6
Autant pour moi, confusion entre le point et la virgule.
#10.7
Et oui, malheureusement le temps écoulé ne va que dans un seul sens….
#10.10
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)
#10.13
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.
#11
De la part d’AMD. Rien ne dit qu’aucun éditeur logiciel ne va pas s’y atteler.
#12
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!
#13
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
#13.1
Et je suppose que l’ironie sous jacente de ta phrase n’était pas du au hasard…
“Vieux système” & “NTFS”
#14
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.
#14.1