- La prise en charge de la RAM ECC, disparue des fiches techniques au lancement d’AM5, a de nouveau été confirmée par un cas de fonctionnement avec un Ryzen 7000 « Raphael » associé à une carte mère ASRock
- Le test a été réalisé avec un Ryzen 7950X, une ASRock B650E PG Riptide, l’UEFI 1.28, AGESA 1.0.0.7b et deux barrettes v-color ECC UDIMM de 32 Go, avec un démarrage Linux réussi après l’entraînement du lien DDR5
- La largeur mémoire de 72 bits et l’indication
Multi-bit ECCdansdmidecodesont des indices utiles, mais comme ces informations SMBIOS proviennent de l’UEFI, elles ne prouvent pas à elles seules que l’ECC est effectivement activé - En interrogeant directement l’UMC d’AMD via le SMN, on constate que le bit 30 de
UmcCapHiindique l’état d’activation de l’ECC, et Linuxryzen_smua également confirmé que ce bit était défini sur les deux canaux mémoire - Même sans injection réelle d’erreurs, les logs EDAC du noyau Linux constituent un indice fort pour juger du fonctionnement de l’ECC, car ils ne sont émis qu’après vérification par l’UMC du bit d’activation ECC
Évolution de la prise en charge ECC sur les Ryzen de bureau
- Les CPU AMD Ryzen de bureau avaient depuis longtemps pour atout la prise en charge officielle de la RAM ECC
- La plupart des séries Ryzen 1000 à 5000 pouvaient utiliser de la RAM ECC avec une carte mère adaptée, sans devoir passer à un CPU de station de travail plus coûteux
- La page de spécifications de l’ASRock B550 Steel Legend montre bien en exemple la compatibilité ECC RAM détaillée selon la génération de CPU
- Lors du lancement de Ryzen 7000 « Raphael » et du Socket AM5, toute mention de la prise en charge ECC a disparu
- Même la page de spécifications de l’ASRock X670E Taichi, pourtant une carte mère AM5 haut de gamme, ne mentionne pas la prise en charge ECC au moment de la rédaction
- Après la mise à niveau vers un Ryzen 7950X, les performances étaient satisfaisantes, mais l’absence d’ECC à l’achat restait un regret important
Des tests ECC sur AM5 lancés depuis le forum ASRock
- Dans un sujet du forum ASRock, un utilisateur nommé ApplesOfEpicness explique avoir réussi à faire fonctionner de la RAM ECC avec le firmware AMD AGESA, avec l’aide d’un ingénieur AMD
- Il indique avoir confirmé, sur une carte mère ASRock dotée d’un UEFI mis à jour, que des erreurs remontaient jusqu’à l’OS en court-circuitant une broche de données et une broche de masse
- Le test suivant a utilisé une ASRock B650E PG Riptide et deux modules v-color ECC UDIMM de 32 Go
- L’UEFI de la carte mère a été mis à jour en 1.28, avec AGESA 1.0.0.7b
- Après le remplacement de la RAM, le système a démarré après une longue phase d’entraînement du lien DDR5
- Sur cette machine, l’entraînement du lien pour 64 Go de RAM a pris presque 3 minutes
- Sur les Ryzen 7000 de bureau, cela n’est nécessaire qu’une seule fois après un changement de RAM ou de timings, l’UEFI mettant ensuite les résultats en cache pour les réutiliser aux démarrages suivants
Les indications ECC visibles sous Linux et leurs limites
- Sous Linux,
sudo dmidecode -t memoryaffiche des valeurs liées à l’ECCError Correction Type: Multi-bit ECCTotal Width: 72 bitsData Width: 64 bits
- La largeur totale de 72 bits est le signal le plus notable
- Avec de la RAM non-ECC, la valeur affichée est de 64 bits
- Une RAM ECC 64 bits dispose de 8 bits supplémentaires pour les données de parité
- Le EDAC du noyau Linux apparaît lui aussi comme activé
EDAC MC: Ver: 3.0.0EDAC MC0: Giving out device to module amd64_edacEDAC amd64: F19h_M60h detected
Pourquoi dmidecode ne suffit pas
dmidecodeest un outil qui affiche sous une forme lisible les tables DMI ou SMBIOS d’un ordinateur- Ces tables contiennent des informations comme les composants matériels, les numéros de série ou la révision du BIOS
- Cela évite de sonder directement le matériel, mais les informations affichées peuvent être peu fiables
- SMBIOS définit des structures de données et une méthode d’accès pour lire les informations de gestion générées par le BIOS
- Cela permet au système d’exploitation de ne pas devoir sonder directement les périphériques
- Les informations ECC de
dmidecodeviennent non pas du processeur, mais de l’UEFI- Certaines informations, comme la vitesse mémoire, peuvent provenir du contrôleur mémoire
- Mais les informations ECC venant de l’UEFI, elles peuvent indiquer que la mémoire est compatible ECC sans garantir que l’ECC est réellement activé
- L’activation de l’ECC est au final décidée par le contrôleur mémoire du système
Comment interroger directement l’UMC d’AMD
- Les processeurs AMD exposent un bus appelé SMN, pour System Management Network
- Ce bus peut être utilisé pour interroger et configurer l’UMC d’AMD, l’Unified Memory Controller
- La documentation illumos sur l’UMC d’AMD indique qu’en interrogeant le registre
UmcCapHi, on peut vérifier si l’ECC est activé- Les informations concernées ne font pas partie de la documentation publique AMD Processor Programming Reference, mais peuvent être retrouvées dans les sources open source des noyaux Linux et illumos
- L’accès direct au SMN est risqué
- En particulier, des commandes d’écriture peuvent gravement endommager l’ordinateur
- Il ne faut pas effectuer d’écritures sur le SMN
- Sous illumos, les deux canaux mémoire d’un Ryzen 7000 sont interrogés séparément
- Adresse du canal 0 :
0x50df4 - Adresse du canal 1 :
0x150df4 - La valeur renvoyée est
0x40000030pour les deux canaux
- Adresse du canal 0 :
- Le point clé est le bit 30
- Si ce bit est défini, alors l’ECC est activé dans le contrôleur mémoire
Interroger le SMN sous Linux avec ryzen_smu
- Sous Linux, il est aussi possible d’accéder au bus SMN via le pilote
ryzen_smu- Sur cette machine, un correctif a été nécessaire pour l’installation
- Le pilote fournit le fichier
/sys/kernel/ryzen_smu_drv/smn- Pour interroger une adresse, il faut écrire une adresse sur 4 octets en little-endian, puis lire le résultat sur 4 octets également en little-endian
- Le résultat de l’interrogation des deux canaux par un script Python est le suivant
0x00050df4:0x400000000x00150df4:0x40000000
- Dans les valeurs renvoyées, le
4du premier nibble signifie que le bit 30 est défini, et que le contrôleur mémoire signale bien l’activation de l’ECC - Sous Windows, des outils comme SMUDebugTool permettent peut-être une requête similaire, mais le fonctionnement de cet outil n’est pas garanti ici
Injection réelle d’erreurs et fiabilité d’EDAC
- La méthode la plus sûre pour vérifier le fonctionnement de l’ECC consiste à injecter de vraies erreurs
- ApplesOfEpicness a court-circuité une broche de données et une broche de masse sur la carte mère
- Une autre méthode consiste à pousser l’overclocking de la RAM jusqu’à un point d’instabilité
- Ce test n’a pas inclus de court-circuit physique des broches ni d’overclocking répété de la RAM
- Le fait que l’entraînement du lien DDR5 prenne plusieurs minutes à chaque fois rend aussi les tests d’overclocking plus contraignants
- Aucune erreur naturelle n’a été observée jusqu’à présent
- Le chemin d’émission des messages EDAC du noyau Linux est lié au bit d’activation ECC de l’UMC d’AMD
- Le log
Giving out device to moduleprovient deedac_mc_add_mc_with_groups - Cette fonction est appelée depuis le chemin
init_one_instance init_one_instancen’est appelé que sipvt->ops->ecc_enabledest vrai- Ryzen 7000, c’est-à-dire Zen 4, correspond à la famille
0x19, et dans ce casumc_opsutiliseumc_ecc_enabled
- Le log
umc_ecc_enabledvérifie le bitUMC_ECC_ENABLEDdeumc_cap_hiUMC_ECC_ENABLEDcorrespond au bit 30- Sur les processeurs AMD, le message
EDAC MC0: Giving out device to module amd64_edacest donc un indicateur fiable que l’UMC signale l’activation de l’ECC
Conclusion
- Sur les CPU de bureau Ryzen 7000, il semble possible de faire fonctionner assez facilement de la RAM ECC, du moins avec des cartes mères ASRock
- Les informations SMBIOS de
dmidecodene suffisent pas à elles seules, mais combinées au bit 30 de l’UMC et au chemin EDAC de Linux, elles permettent de confirmer plus directement que l’ECC est activé
1 commentaires
Avis sur Hacker News
J’ai besoin de mettre à niveau mon processeur et je m’intéresse beaucoup à une configuration avec RAM ECC
J’ai vu sur /r/AMD un fil où deux personnes débattaient pour savoir si les processeurs ou cartes mères AMD prennent réellement en charge l’ECC, mais je ne sais pas qui a raison : https://www.reddit.com/r/Amd/comments/lzxqod/list_of_am4_mot...
Je me demande si cet article confirme vraiment que la combinaison AMD+ASRock utilise bien de la RAM ECC
En général, c’est écrit dans la section « Memory » sous une forme du type « ECC & Non-ECC, Unbuffered Memory »
Attention : l’expression « On-die ECC » désigne une fonction également présente sur la mémoire non-ECC, et n’a donc rien à voir avec l’ECC dont il est question ici
Il faut acheter de la DDR5 UDIMM ECC, et ne pas se tromper en achetant de la DDR5 RDIMM ECC, qui n’est pas compatible avec les cartes mères AM5
Les UDIMM DDR5 ECC peuvent avoir une largeur de 80 bits ou 72 bits ; il faut simplement éviter les UDIMM DDR5 non-ECC limitées à 64 bits
Quand j’avais vérifié, ASUS proposait le plus grand nombre de cartes AM5 avec prise en charge de l’ECC, et la PRIME X670E-PRO WIFI était celle qui me plaisait le plus, car elle offrait une bonne extensibilité PCIe en dehors du slot GPU
Le niveau 0 signifie aucune prise en charge, au point que la machine ne démarre pas si l’on installe de la RAM ECC ; le niveau 1 signifie qu’on peut l’installer, mais que la fonction ECC n’est pas utilisée ; le niveau 2 signifie que les circuits existent, mais que le fabricant de la carte mère n’a pas validé la détection et la correction d’erreurs ; le niveau 3 signifie que l’ECC fonctionne et a été validé par le fabricant
Sur une carte de classe serveur comme Supermicro, on peut s’attendre au niveau 3
Quand on voit « ECC supported » pour un processeur AMD, il est difficile de savoir de quel niveau il s’agit, alors que chez Intel, si le CPU/chipset est annoncé comme prenant en charge l’ECC, on peut considérer que c’est réellement le cas
En utilisant volontairement une DIMM ECC défectueuse, j’ai pu provoquer en peu de temps des erreurs corrigibles et non corrigibles
Si tous les autres composants nécessaires sont présents, il paraît peu probable qu’ASRock n’ait pas câblé ce qu’il faut ; si le noyau indique qu’il y a de l’ECC, je le tiendrais pour vrai
Sinon, il suffit de renvoyer la carte comme défectueuse et de passer à un autre fabricant
Dommage en revanche qu’il n’y ait pas de cartes mini-ITX/mATX X670E. Seul ASUS en propose
dmidecodeindique une largeur de données de 128 bits au lieu de 72 bits, mais signale aussi la correction de plusieurs bits, pas seulement d’un seul bitSur les cartes Intel avec UDIMM, par exemple Supermicro+Xeon, j’étais habitué aux 72 bits, mais cette information semble dépendre davantage du contrôleur mémoire et de la façon dont la carte mère la rapporte que de la prise en charge matérielle réelle
Quoi qu’il en soit, EDAC fonctionne, le bon pilote est enregistré, et je reçois parfois des alertes EDAC/RAS indiquant que des erreurs corrigibles ont effectivement été corrigées ; à mon avis, cela règle la question
C’est un peu hors sujet, mais la prise en charge de l’ECC qui fonctionne aussi sur l’ancienne plateforme AM4 et les cœurs d’APU Zen3 ressemble à ceci, et elle existe clairement sur mon système
Il s’agit d’une combinaison ASRock B550M-ITX/ac et AMD Ryzen 5 PRO 5650G, et cela fonctionnait de la même manière auparavant avec un Ryzen 5 3600 et un GPU dédié
Sur un GNU/Linux récent, il faut activer le service
rasdaemonpour détecter et journaliser l’activité ECCCe service interprète les MCE et autres erreurs liées au matériel, les stocke dans une base de données, et la sortie consultée ci-dessus en est le résultat
Cela dit, en y repensant, la fréquence est assez élevée et il est possible qu’un module mémoire soit défectueux. Le fait que ce soit toujours le même module et la même adresse va particulièrement dans ce sens
https://www.asus.com/global/support/FAQ/1045186/
dmidecodeaffiche une largeur de 72 bits, etdmesg | grep -i EDACmontre beaucoup d’informations qui donnent l’impression que l’ECC est activéMais la sortie de cette commande est vide et n’affiche que « No Memory errors », « No PCIe AER errors », « No Extlog errors », « No MCE errors »
Je me demande s’il faut activer quelque chose pour que les erreurs soient enregistrées, ou si je me suis fait avoir par
dmidecodeetdmesgBon article. J’utilise aussi de la RAM ECC sur ma carte Threadripper
L’une des choses que l’équipe d’exploitation de Blekko avait découvertes sur les cartes Intel, c’est qu’il fallait explicitement indiquer à la carte de signaler effectivement les erreurs corrigeables
Par défaut, elle émettait un machine check en cas d’erreur irrécupérable, et ignorait simplement le reste
Sur environ 1 600 systèmes de 192 Go, il me semble qu’on voyait une erreur corrigeable à peu près une fois par semaine
En six ans, je ne me souviens d’aucune erreur irrécupérable, donc c’était plutôt bon
Nous avions un parc d’une taille comparable, avec en moyenne une quantité de RAM similaire, et nous avions aussi parfois des erreurs irrécupérables. Probablement une ou deux par an, ce qui nous avait amenés à établir une politique
On observait si cela ne se produisait qu’une seule fois ; si ça ne retombait pas en panne rapidement, on considérait que c’était acceptable, et si ça retombait en panne rapidement, on remplaçait la RAM
Les meilleures cartes serveur indiquent même par LED quel module de RAM remplacer
Pour les erreurs corrigeables, on ne remplaçait pas avant que le nombre devienne assez élevé, et certains systèmes avec une ou deux erreurs par jour ont tourné longtemps sans problème
À l’inverse, il y avait aussi des systèmes restés longtemps à zéro, puis avec quelques occurrences sur quelques jours, avant de grimper brusquement à des valeurs élevées
Un système est monté à plusieurs milliers par heure, au point d’être inutilisable à cause du coût de traitement des exceptions machine check, mais comme la période de reporting était d’une heure, on ne savait pas d’où venait le problème avant le rapport suivant
J’utilise actuellement un Ryzen 3700X avec une carte mère ASUS TUF Gaming X570, et j’ai besoin de davantage de performances monocœur et de vitesse NVMe/disque
J’utilise déjà deux GPU, deux M.2 NVMe et six SATA
J’envisage une mise à niveau en fin d’année ; à cause des lignes PCIe, j’ai brièvement pensé à Threadripper, mais il n’y a pas encore de Threadripper Zen4 et les prix risquent d’être très élevés
Les options sont de passer à un Ryzen 5900X en gardant le reste, ou de dépenser plus pour passer à un Ryzen AM5 et une nouvelle carte mère
J’ai aussi regardé Intel, mais le fait que ça s’arrête à 20 lignes PCIe me fait plutôt l’écarter
J’ai besoin de plus de lignes PCIe, car je veux ajouter un adaptateur 10 Gb pour externaliser une partie des disques rotatifs
Les performances multicœurs du 3700X me suffisent, et si j’achète une nouvelle carte mère, je veux au minimum un miroir de deux NVMe pour la vitesse et au moins six ports SATA
Je ne sais pas pour AMD, mais sur les cartes Intel, en général un seul slot M.2 est directement relié au CPU et les trois autres passent par le chipset, donc ils partagent aussi le goulet d’étranglement avec la carte Ethernet 10 Gb
Au final, acheter une carte compatible PCIe 5.0 et un SSD unique suffisamment grand s’est avéré bien plus rapide, avec des IOPS totales et un débit supérieurs à mon ancienne grappe RAID 0
Le 5900X n’est pas une si grosse mise à niveau
À titre d’exemple, Hetzner propose depuis quelques mois des serveurs avec CPU Ryzen 7000 et RAM ECC
https://www.hetzner.com/dedicated-rootserver/matrix-ax
L’AX52 propose la RAM ECC en option de mise à niveau, et l’AX102 inclut l’ECC par défaut
Je doute qu’ils aient proposé de l’ECC qui ne fonctionne pas réellement
Ils peuvent donc probablement garantir la prise en charge de l’ECC de bout en bout
J’aimerais que les législateurs se réveillent et rendent l’ECC obligatoire
C’est inquiétant que la majorité du calcul se fasse sur des systèmes Non-ECC vulnérables
C’est une forme vraiment désastreuse de segmentation artificielle du marché
Comment veux-tu attendre de ces gens qu’ils légifèrent sur l’ECC ?
Pourtant, mon système Intel tourne une demi-journée chaque jour avec 64 Go de RAM Non-ECC, puis hiberne la nuit, et même avec de la CAO 3D, Photoshop, VS Code chargé d’extensions et des conteneurs Docker WSL2, je ne vois presque jamais d’erreurs
Pas de plantages ni d’écrans bleus non plus
Je me demande ce qu’il faut exactement attendre d’une erreur de bit flip. Si des inversions d’un seul bit se produisaient aussi souvent alors que les 64 Go de RAM sont presque entièrement utilisés, j’ai l’impression que ça se verrait d’une manière ou d’une autre
Je n’ai pas le courage de court-circuiter physiquement des broches, ni la patience d’overclocker lentement la RAM en attendant plusieurs minutes à chaque fois le link training DDR5.
Je me contente donc du fait que le contrôleur mémoire indique que l’ECC est activé.
À la place, que diriez-vous de souffler de l’air chaud d’un sèche-cheveux sur la RAM ? J’ai déjà vu cette technique utilisée pour provoquer des erreurs.
https://hackaday.com/2022/01/29/blast-chips-with-this-bbq-li...
https://hackaday.com/tag/emfi/
Ce n’est pas recommandé pour un usage réel, mais cela peut servir à trouver les limites de la mémoire ou à provoquer des erreurs.
Sur mon système I7-4770K non overclocké, des erreurs apparaissent, mais une vieille carte Supermicro de génération X10 ne semble détecter aucune erreur même en faisant tourner un test Rowhammer indéfiniment.
Cela dit, si les systèmes récents sont conçus pour ne pas être vulnérables aux attaques Rowhammer, cette méthode peut ne pas fonctionner.
La RAM des Raspberry Pi 4B et CM4 est réputée utiliser de la RAM ECC, mais ce n’est pas le même ECC que celui dont il est question ici.
Il s’agit d’ECC on-die, destiné à améliorer le rendement des puces, et les erreurs ECC sont corrigées sans être signalées via le matériel.
Les erreurs ECC non corrigibles seraient probablement simplement lues comme des données erronées.
Je me demande si les modules RAM récents utilisent eux aussi des puces avec ECC on-die.
Le link training peut être désactivé dans le BIOS, ce qui permet de trouver rapidement des réglages de bande passante à la limite.
Les résultats ne seront pas très reproductibles, mais ce n’est pas important.
Certaines, peut-être toutes les cartes mères ASUS AM5, prennent officiellement en charge l’ECC.
Cela figure à la fois dans le manuel de la carte et dans le manuel du BIOS du modèle que je viens de vérifier.
L’un des réglages BIOS concernés est sur Auto par défaut, mais, contrairement à ce qu’on pourrait penser, il est désactivé dans cet état et il faut donc le modifier.
La prise en charge du reporting ECC pour ces processeurs est arrivée dans Linux 6.5 ; les utilisateurs de Debian Stable devront donc attendre qu’elle arrive dans Backports ou sortir du chemin classique.
https://www.phoronix.com/news/AMD-EDAC-Ryzen-7000-Series
Ce serait encore acceptable si l’on pouvait voir la valeur effectivement appliquée, mais neuf fois sur dix ce n’est pas clair.
Il se murmure qu’une ancienne version d’AGESA contenait un bug empêchant le chipset de reconnaître et d’utiliser correctement la RAM ECC.
Et ce, même si le chipset était censé la prendre en charge.
Pour toute carte mère envisagée, il faut vérifier qu’il existe une mise à jour du firmware contenant au minimum AGESA 1.0.0.5 patch C.
https://www.reddit.com/r/truenas/comments/10lqofy/
AGESA fait partie du firmware des systèmes AMD et initialise les composants essentiels du système : https://en.wikipedia.org/wiki/AGESA
J’ai fait la mise à jour vers AGESA 1.0.0.7b avant d’installer la RAM ECC.
Je ne savais pas que la série Ryzen 7000 n’indiquait pas officiellement la prise en charge de l’ECC.
Par exemple, la gamme ASRock Rack le prend en charge : https://www.asrockrack.com/general/productdetail.asp?Model=1...
Cette carte mère ASUS revendique aussi la prise en charge de l’ECC : https://www.asus.com/us/motherboards-components/motherboards...
Aucune des deux n’existait quand j’ai acheté ma première carte mère AM5. C’était juste après le lancement et les chiffres de performance étaient tellement bons que j’ai craqué tôt.
Tous les CPU Ryzen 7000 actuellement en vente prennent officiellement en charge l’ECC, mais il faut aussi une prise en charge par la carte mère.
Ce type de prise en charge conditionnelle de l’ECC existe depuis longtemps sur les CPU grand public AMD, en remontant jusqu’à l’Athlon 64, mais il me semble que c’est la première fois que je le vois mentionné dans les documents marketing d’AMD pour la série Ryzen 7000.
Ce que l’auteur voulait dire, c’est que la mention de la prise en charge de l’ECC avait disparu de la documentation des cartes mères ASRock.
ASRock mentionnait jusque-là la prise en charge de l’ECC sur ses anciennes cartes mères Ryzen, ce qui rendait le changement notable.
Exemple de page de caractéristiques du Ryzen 5 7600 : https://www.amd.com/en/product/12756#:~:text=ECC%20Support,R...)
En plus, cela prête à confusion avec l’ECC on-chip utilisé par toute la DDR5.
La DDR5 a besoin d’un ECC on-chip pour corriger les erreurs survenant en fonctionnement normal, mais ce n’est pas un ECC qui protège aussi les données transmises au CPU via le bus mémoire.