MAJ 22/04 : quelques compléments d'informations importantes qui se sont concrétisés ou ont émergé entre-temps. Tout d'abord, il faut faire remarquer qu'ASUS a discrètement mis à jour les BIOS de toutes ses cartes mères AM5 (X670, B650 et A620) le 21/04. Il est très difficile d'y voir une simple coïncidence avec les problèmes relevés ces derniers jours. De plus, il n'y a absolument rien de nouveau dans les changelogs de ces BIOS (hormis quelques fautes de frappe avec des mentions de 7000X6D, 7000X8D, 7000X4D ou encore 7000X9D... Calmez-vous, ce n'est pas du leak !). Compte tenu des informations à disposition, tout laisse désormais à penser qu'une ou des tensions trop agressives ont été infligées d'une façon ou d'une autre par la carte mère au CPU, et a priori plus spécifiquement au 3D V-Cache, qui, on le sait bien, est plutôt sensible.
Un bug ? À moins qu'ASUS ait un peu foiré le support des Ryzen 7000X3D avec les BIOS précédents, tout particulièrement avec les mobales X670 ? Par exemple, celui-ci était encore récemment annoncé comme étant validé depuis le BIOS 1101 par exemple pour la X670E HERO, mais l'est désormais seulement à partir du BIOS 1202... Faut-il en déduire que le BIOS 1101 n'était en réalité pas vraiment compatible ? Nous le saurons peut-être prochainement, en attendant que les différentes enquêtes soient menées. Justement, Steve de chez Gamer's Nexus a déjà offert de racheter le 7800X3D et la carte mère cramés de l'une des victimes, une initiative en ce qui nous concerne sans aucun doute largement préférable à un simple RMA discret et facile, et qui arrangerait surtout ASUS...
Il y a quelques jours, depuis le lancement des Ryzen 7000X3D en fait, quelques cas très rares de cramage ont été remontés par plusieurs personnes. Officiant sur YouTube ou Reddit, des utilisateurs ont remonté que leur plateforme AM5 s'est brusquement arrêtée, et n'est plus jamais repartie. Les processeurs incriminés étaient des Ryzen 7000X3D, plus précisément des Ryzen 7 7800X3D et Ryzen 9 7950X3D. Après avoir démonté le socket, il s'avère que les broches et le plastique du socket avaient fondu, et on peut même voir un cas de boursouflure importante sur le 7800X3D. La cause est très difficile à isoler, puisqu'il y a très peu de cas, ce qui ne devrait malgré tout pas se produire quoi qu'il arrive. Où chercher ?
Eh bien le point commun à ces soucis, bien chi.nts si vous êtes touchés compte tenu du fric que ça demande, c'est que ce sont des cartes mères ASUS basées sur le X670E. Il y a la ROG STRIX X670-E, ou la X670E Crosshair. Est-ce une coïncidence, c'est très difficile à dire, mais il semble clair qu'ASUS devrait étudier le cas afin de voir si la cause ne provient pas de leur produit, ou d'un mauvais usage des clients. Certains ont rapporté avoir désactivé un CCD juste avant que ça ne parte en vrille, sans avoir overclocké quoi que ce soit, juste utilisé le profil XMP / EXPO dans le BIOS.
En l'état actuel des choses, il n'y a pas matière à paniquer. Seulement 3 cas, certes trois de trop, ce n'est pas ce qu'on peut appeler un Ryzengate, loin s'en faut. Mais il serait bon d'investiguer, aussi bien chez AMD qu'ASUS, quitte à supprimer la capacité du BIOS de désactiver des CCD (ou ne pas le permettre via Ryzen Master) si d'aventure le souci venait de là. Aucun des deux n'a communiqué sur le sujet pour l'instant.
Ils ont désactivé un CCD sur un 7800X3D? 🧐
Le 7950X3D est concerné aussi et y'a écrit "certains".
On dirait bien que c'est un cas (un bug ?) de tensions trop élevés par défauts... D'ailleurs, ce qui est intéressant, c'est qu'ASUS a visiblement dépublié le BIOS le plus récent de ses cartes mères AM5 pour en publier un nouveau juste hier (le 21/04), toujours avec le même AGESA (dont le déploiement avait commencé début avril chez ASUS). Coincidence ? On dirait aussi qu'ils ont fait ça un peu à la va-vite, vu les fautes "7000X6D", "7000X8D", "7000X4D" etc. dans les changelogs des X670. 😅
Oui, pour le 7950X3D je comprends bien. On aurait par exemple pu imaginer que peut-être le fait d'éteindre un CDD couperait aussi quelques lignes d'alim, et que du coup, plus de courant serait obligé de transiter sur un plus nombre plus restreint de VDD.
Sauf que ça ne marche pas dans le cas d'un 7800X3D. Pour ceux-là, le mode grille-pain n'a pas pus être activé par la désactivation du seul et unique CCD. C'était juste une coïncidence.
L'hypothèse du bug dans le bios tient plus la route. Merci d'avoir relevé ça.
@Titi, je ne vois pas comment imaginer que le fait d'éteindre un CCD (et non CDD), ce qui couperait (conditionnel) des lignes d'alim pourrait entrainer une surcharge de courant sur les lignes d'alim dédiées au CCD restant.
Si chaque CCD est allié à des lignes d'alim dédiées, il n'y a aucune raison que le CCD restant ait besoin de plus de courant et ait pu être dépendant des lignes d'alim d'un autre avant la désactivation.
Compte tenu du timing des nouveaux BIOS chez ASUS et le fait qu'il n'y a pas eu de nouvel AGESA ni de correctifs de sécu pour justifier ces (re)publications, je penche vraiment pour un bug ayant entraîné une ou des tensions trop agressives et qui furent fatales au 3D V-Cache...
Steve de Gamer's Nexus a proposé de racheter le R7 7800X3D et la carte mère cramés d'un des redditeurs, on en saura sûrement plus très prochainement.
@Dark On ne connait aucun détails de comment c'est fichu, donc c'est de pures hypothèses basés sur pas grand choses. Mais on pourrait très bien imaginé que des pins d'alim serait physiquement coupé en même temps qu'un des CCD, mais que dans le même temps, lorsqu'elles sont actives, qu'elles ne soient pas exclusivement dévolue au chiplet converné, mais rajouté au pot communs des nombreuses pins d'alim du socket, participant à la répartition globale de la charge, IODie compris.
Et après, ça serait plus sur de forts pics de courant instantané. Tout aurait été correctement dimensionné pour les plus forts pics attendu et avec la totalité des pins disponibles, mais le cas particulier d'un CCD désactivé par l'utilisateur aurait pu être un peu négligé ou oublié, et où l'extinction d'un chiplet diminuerait certes les pics maximaux atteint, mais pas de manière proportionnelle au nombre de pins retiré, et que les pinoches restantes se coltineraient du coup peut-être une plus grosse charge de travail individuelle (même si la charge global a elle diminué avec le ccd en moins, ça on est d'accord). Et peut-être que là, on dépasserait leur specs et provoquerait de la surchauffe.
Mais bon, c'est pas lié à la désactivation du ccd. Donc fausse piste.
Jamais encore trouvé le mapping du socket AM5, malgré la fuite massive de Gigabytes qui en avait quasiment tout révélé. Mais pour AM4 on a ça:
https://en.wikichip.org/wiki/amd/packages/socket_am4#Pin_Map
On voit qu'il n'y a pas 36 tensions différentes. De très nombreuses pins sont dédié à ça, mais aucune dévolue à un chiplet en particulier. Par contre, je ne serais pas foncièrement choqué si j'apprenais un jour que certaine pin s'activait ou se désactivait dynamiquement en fonction de la charge, ou du CPU installé, si ils y avaient trouvé un intérêt particulier à faire ça (réduction de conso?)
Je ne connais pas les tenants et les aboutissants mais Asus est assez coutumier de foutre des boost de m... sur les tensions du proco.
Oui, comme d'autres. Tout ça pour faire croire, lors de tests comparatifs, que leur carte mère permet à un pc d'être x % plus performant qu'un pc avec la carte mère d'un concurrent. Ce n'est pas nouveau, et si ça leur pète à la gueule, ben tant mieux.
@Titi, je n'imagine pas, je fais preuve de logique. Si ton hypothèse était la bonne, et qu'AMD avait merdé en concevant son socket de manière aussi moche, on aurait une tripotée de gens qui se sont amusés à désactiver des CCD qui auraient eu le souci. Et pas seulement sur ce CPU.
Et je me permets de croire qu'un CCD ne se désactive pas en coupant simplement le courant au niveau de l'alimentation du socket et que dans ce cas, les pins sont certainement dédiés ou bien tout simplement toujours alimentés s'ils sont partagés. Un peu comme quand tu éteins ta cafetière mais que la prise fournit toujours une tension, et que le frigo raccordé à la même prise continue d'être alimenté lui.