AMD Ryzen 7000デスクトップCPUのECC RAMサポートを確認
(sunshowers.io)- AM5発売時に仕様表から消えていたECC RAMサポートが、Ryzen 7000 “Raphael”とASRockマザーボードの組み合わせで動作する事例として改めて確認された
- テストはRyzen 7950X、ASRock B650E PG Riptide、UEFI 1.28、AGESA 1.0.0.7b、v-color 32GB ECC UDIMM 2枚で行われ、DDR5リンクトレーニング後にLinuxの起動に成功した
dmidecodeの72ビットメモリ幅とMulti-bit ECC表示は有用な手がかりだが、UEFIのSMBIOS情報であるため、ECCの有効化そのものを単独で証明するものではない- AMD UMCをSMNで直接照会すると、
UmcCapHiのbit 30がECCの有効化状態を示し、Linuxのryzen_smuでも2つのメモリチャネルで該当ビットがセットされた値が確認された - 実際のエラー注入は行っていないが、LinuxカーネルのEDACログはUMCのECC有効化ビットを確認した後に出力される経路であるため、ECC動作の有無を判断する強い根拠となる
RyzenデスクトップにおけるECCサポートの変化
- AMD RyzenデスクトップCPUは以前から、ECC RAMの公式サポートが強みの1つだった
- Ryzen 1000〜5000シリーズの大半は、適切なマザーボードと組み合わせれば、より高価なワークステーション級CPUなしでもECC RAMを使用できた
- ASRock B550 Steel Legend仕様ページは、CPU世代ごとのECC RAM互換情報を詳しく示している例である
- Ryzen 7000 “Raphael”とSocket AM5の発売時点では、ECCサポートへの言及が消えた
- 高価なAM5マザーボードであるASRock X670E Taichi仕様ページにも、執筆時点ではECCサポートへの言及がない
- Ryzen 7950Xへのアップグレード後、性能には満足していたが、購入当時にECCがないことは大きな不満として残った
ASRockフォーラムから始まったAM5 ECCテスト
- ASRockフォーラムのトピックで、ApplesOfEpicnessというユーザーがAMDエンジニアとともにAMD AGESAファームウェアでECC RAMを動作させた経験を共有した
- 更新されたUEFIを搭載したASRockマザーボードで、データピンとグラウンドピンをショートさせ、エラーがOSまで報告されることを確認したという
- その後のテストには、ASRock B650E PG Riptideとv-color 32GB ECC UDIMM 2枚が使用された
- マザーボードのUEFIは1.28、AGESAは1.0.0.7bに更新された
- RAM交換後、DDR5リンクトレーニングが長時間行われた後にシステムが起動した
- このシステムで64GB RAMのリンクトレーニングにはほぼ3分かかる
- Ryzen 7000デスクトップでは、RAM交換やタイミング変更後に一度だけ必要で、UEFIが結果をキャッシュして以後の起動で再利用する
Linuxで見えるECC表示と限界
- Linuxで
sudo dmidecode -t memoryを実行すると、ECC関連の値が表示されるError Correction Type: Multi-bit ECCTotal Width: 72 bitsData Width: 64 bits
- Total Width 72 bitsは目立つシグナルである
- 非ECC RAMでは64ビットと表示される
- 64ビットECC RAMはパリティデータ用の追加8ビットを持つ
- LinuxカーネルのEDACも有効化されているように見える
EDAC MC: Ver: 3.0.0EDAC MC0: Giving out device to module amd64_edacEDAC amd64: F19h_M60h detected
dmidecodeだけでは不十分な理由
dmidecodeは、コンピュータのDMIまたはSMBIOSテーブルを人間が読める形で出力するツールである- これらのテーブルには、ハードウェア構成要素、シリアル番号、BIOSリビジョンなどの情報が含まれる
- 実際のハードウェアを直接探索しなくてよいが、表示される情報は信頼できない場合がある
- SMBIOSは、BIOSが生成した管理情報を読み取るためのデータ構造とアクセス方法を定義する
- OSがデバイスを直接探索しなくても済むようにする
- ECC関連の
dmidecode情報は、プロセッサではなくUEFIから来る- メモリ速度のように、一部の情報はメモリコントローラから来る場合がある
- ECC情報はUEFIから来るため、メモリがECC対応であることは示せても、ECCが実際に有効化されていることは保証しない
- ECCが有効かどうかは最終的に、システムのメモリコントローラが決定する
AMD UMCを直接照会する方法
- AMDプロセッサはSystem Management Network、すなわちSMNというバスを公開している
- このバスはAMD Unified Memory Controller、すなわちUMCを照会および構成するために使用できる
- illumosのAMD UMCドキュメントを通じて
UmcCapHiレジスタを照会すると、ECCの有効化有無を確認できる- 関連情報は公開されているAMD Processor Programming Referenceの一部ではなく、オープンソースのLinuxおよびillumosカーネルソースから把握できる
- SMNへの直接アクセスは危険である
- 特に書き込み命令はコンピュータを深刻に損傷させる可能性がある
- SMNに対して書き込み操作を行ってはならない
- illumosではRyzen 7000プロセッサの2つのメモリチャネルをそれぞれ照会する
- チャネル0のアドレス:
0x50df4 - チャネル1のアドレス:
0x150df4 - 戻り値は両チャネルとも
0x40000030
- チャネル0のアドレス:
- 重要なのはbit 30である
- このビットがセットされていれば、メモリコントローラでECCが有効になっている状態である
Linuxでryzen_smuを使ってSMNを照会
- Linuxでも
ryzen_smuドライバでSMNバスにアクセスできる- このシステムでは、インストールにパッチが必要だった
- ドライバは
/sys/kernel/ryzen_smu_drv/smnファイルを提供する- 照会するには、4バイトのアドレスをリトルエンディアン形式で書き込み、4バイトの結果をリトルエンディアン形式で読み取る
- Pythonスクリプトで2つのチャネルを照会した結果は次のとおりである
0x00050df4:0x400000000x00150df4:0x40000000
- 戻り値の最初のニブルの
4はbit 30がセットされていることを意味し、メモリコントローラがECCの有効化を報告している - WindowsでもSMUDebugToolのようなツールで同様の照会が可能かもしれないが、このツールの動作は保証しない
実際のエラー注入とEDACの信頼性
- ECC動作を最も確実に検証する方法は、実際にエラーを注入することである
- ApplesOfEpicnessはマザーボードのデータピンとグラウンドピンをショートさせた
- 別の方法としては、RAMのオーバークロックを不安定な地点まで引き上げるやり方がある
- このテストでは、物理的なピンのショートや反復的なRAMオーバークロックは行っていない
- DDR5リンクトレーニングが毎回数分かかる点も、オーバークロックテストの負担となる
- 現時点まで自然発生したエラーは観測されていない
- LinuxカーネルのEDACメッセージ経路は、AMD UMCのECC有効化ビットに結び付いている
Giving out device to moduleログはedac_mc_add_mc_with_groupsから出る- この関数は
init_one_instance経路で呼び出される init_one_instanceはpvt->ops->ecc_enabledが真のときだけ呼び出される- Ryzen 7000、すなわちZen 4はfamily
0x19であり、この場合はumc_opsのumc_ecc_enabledが使われる
umc_ecc_enabledはumc_cap_hiのUMC_ECC_ENABLEDビットを確認するUMC_ECC_ENABLEDはbit 30- AMDプロセッサで
EDAC MC0: Giving out device to module amd64_edacメッセージは、UMCがECCの有効化を報告したことを示す信頼できる指標である
結論
- Ryzen 7000デスクトップCPUでも、少なくともASRockマザーボードとの組み合わせではECC RAMを比較的容易に動作させることができる
dmidecodeのSMBIOSベース情報だけでは不十分だが、UMCのbit 30とLinux EDAC経路を合わせて見ることで、ECCの有効化状態をより直接的に確認できる
1件のコメント
Hacker News の意見
プロセッサをアップグレードする必要があり、ECC RAM 構成に強い関心がある
/r/AMD で、AMD プロセッサやマザーボードが実際に ECC をサポートするのかについて2人が議論している投稿を見たが、どちらが正しいのか分からない: https://www.reddit.com/r/Amd/comments/lzxqod/list_of_am4_mot...
この記事で、AMD+ASRock の組み合わせが本当に ECC RAM だと確定するのか気になる
通常は「Memory」セクションに「ECC & Non-ECC, Unbuffered Memory」のように書かれている
「On-die ECC」という表現は Non-ECC メモリにもある機能なので、ここで言う ECC とは関係ない点に注意が必要
ECC DDR5 UDIMM を買うべきで、AM5 マザーボードと互換性のない ECC DDR5 RDIMM を誤って買ってはいけない
ECC DDR5 UDIMM は幅が 80 ビットまたは 72 ビットの場合があり、Non-ECC DDR5 UDIMM の 64 ビットでさえなければよい
以前確認したときは ASUS が ECC 対応 AM5 ボードを最も多くそろえており、GPU スロット以外の PCIe 拡張性が良かったので PRIME X670E-PRO WIFI がいちばん気に入っていた
0 はまったくサポートせず ECC RAM を挿すと起動しないレベル、1 は挿すことはできるが ECC 機能を使わないレベル、2 は回路はあるがマザーボードメーカーがエラー検出・訂正を検証していないレベル、3 は ECC 機能がありメーカーが検証済みのレベル
Supermicro のようなサーバー級ボードなら3段階目を期待できる
AMD プロセッサで「ECC supported」と表示されてもどの段階か分かりにくいが、Intel は CPU/チップセットが ECC をサポートすると言っていれば実際にサポートしていると見てよい
わざと不良 ECC DIMM を使って、短時間で訂正可能エラーと訂正不能エラーを発生させることができた
他の構成要素がすべてそろっているのに ASRock が配線していない可能性は低そうだが、カーネルが ECC があると言うなら正しいと見てよい
そうでなければボードを不良品として返品し、別メーカーを使えばよい
ただし mini-ITX/mATX X670E ボードがないのは残念だ。それがあるのは ASUS だけ
dmidecodeは 72 ビットではなく 128 ビットのデータ幅として報告するが、単一ビットだけでなく複数ビット訂正も報告するIntel ボードの UDIMM、たとえば Supermicro+Xeon では 72 ビットに慣れていたが、この情報は実際のハードウェア対応よりもメモリコントローラとマザーボードの報告方法の影響を受けているようだ
それでも EDAC が動作し、正しいドライバが登録され、EDAC/RAS で訂正可能エラーが実際に訂正されたという警告をたまに受けるので、これで結論は出たと思う
少し話題から外れるが、古い AM4 プラットフォームと Zen3 APU コアでも動作する ECC サポートはこのように見え、私のシステムでは確実に存在する
ASRock B550M-ITX/ac と AMD Ryzen 5 PRO 5650G の組み合わせで、以前 Ryzen 5 3600 と専用 GPU を使っていたときも同じように動作していた
最新の GNU/Linux で ECC の動作を検出して記録するには、
rasdaemonサービスを有効にする必要があるこのサービスが MCE やその他のハードウェア関連エラーを解釈してデータベースに保存し、上で照会した出力もその結果である
ただし考え直すと頻度がかなり高いので、メモリモジュールが故障している可能性もある。毎回同じモジュールと同じアドレスである点が特にそうだ
https://www.asus.com/global/support/FAQ/1045186/
dmidecodeは 72 ビット幅を示し、dmesg | grep -i EDACも ECC が有効になっているような情報を多く表示するしかし当該コマンドの出力は空で、「No Memory errors」「No PCIe AER errors」「No Extlog errors」「No MCE errors」だけが出る
エラーが記録されるように何かを有効にする必要があるのか、それとも
dmidecodeとdmesgにだまされているのか気になる良い記事。自分の Threadripper ボードでも ECC RAM を使っている
Blekko の運用チームが Intel ボードで見つけたことの一つは、訂正可能なエラーを実際に報告するよう、ボードに明示的に指示する必要があったという点
デフォルトでは、復旧不能なエラーがあるとマシンチェックを出し、それ以外はそのまま見過ごす形だった
約1600台の192GBシステムで、訂正可能なエラーをおおよそ週1回見ていたと記憶している
6年間で復旧不能なエラーは一度も覚えていないので、かなり良かった
同じくらいの規模の機材と、平均して同程度の RAM 容量があり、復旧不能なエラーもたまにはあった。たぶん年に1、2回くらいだったのでポリシーができた
一度だけ発生したのか様子を見て、すぐに再発しなければ問題なしと見なし、すぐに再発したら RAM を交換した
より良いサーバーボードだと、どの RAM モジュールを交換すべきかを LED で教えてくれることもある
訂正可能なエラーは回数がかなり多くなるまでは交換せず、1日に1、2回エラーが出るシステムも長く問題なく動いていた
逆に、長い間0件だったのに数日間少数発生したあと、大きな数値に跳ね上がるシステムもあった
あるシステムは1時間あたり数千件まで増えて、マシンチェック例外の処理コストのせいで使い物にならないほどだったが、報告周期が1時間だったので次の報告まで原因が分からなかった
現在 Ryzen 3700X と ASUS TUF Gaming X570 マザーボードを使っていて、シングルコア性能 と NVMe/ディスク速度がもっと必要
デュアル GPU、M.2 NVMe 2基、SATA 6基をすでに使っている
年末のアップグレードを検討中で、PCIe レーンのために Threadripper も少し考えたが、Zen4 Threadripper はまだなく、価格も非常に高くなりそう
選択肢は Ryzen 5900X に上げて他は維持するか、もっとお金をかけて AM5 Ryzen と新しいマザーボードに行くか
Intel も見たが、PCIe レーンが20本で終わるのを見て候補から外す方向に傾いた
10Gb アダプターを追加して回転式ディスクの一部を外に出したいので、PCIe レーンがもっと必要
3700X のマルチコア性能は十分で、新しいマザーボードを買うなら速度のために少なくとも NVMe 2基のミラーと SATA ポート6個以上は欲しい
AMD 側は分からないが、Intel ボードはたいてい M.2 スロットの1つだけが CPU に直接つながり、残り3つはチップセット経由なので、10Gb イーサネットカードともボトルネックを共有することになる
結局、PCIe 5.0 対応ボードと十分に大きい単一 SSD を買うほうがずっと速く、総 IOPS とスループットのどちらも以前の RAID 0 アレイより高かった
5900X はそれほど大きなアップグレードではない
参考例として、Hetzner は数か月前から ECC RAM を付けた Ryzen 7000 CPU サーバーを提供している
https://www.hetzner.com/dedicated-rootserver/matrix-ax
AX52 は ECC RAM をオプションアップグレードとして提供し、AX102 は標準で ECC が入っている
実際には動作しない ECC を提供していたとは思えない
だから最初から最後まで ECC 対応 を確実に保証できるはず
立法者たちが目を覚まして ECC 義務化 をしてくれたらいいのに
ほとんどのコンピューティングが脆弱な Non-ECC システムで行われているのは不安
人為的な市場分割の、かなりひどい形だ
そんな人たちに ECC について立法することをどう期待できるのか
でも自分の Intel システムは 64GB の Non-ECC RAM で毎日半日動かし、夜は休止状態にしていて、3D CAD、Photoshop、拡張を大量に入れた VS Code、WSL2 の Docker コンテナ群を動かしても、エラーはほとんど見ない
クラッシュやブルースクリーンもない
ビット反転エラー で正確に何を想定すべきなのか気になる。64GB RAM をほぼ使い切る状況でそんなに頻繁に単一ビット反転が起きるなら、何らかの形で表に出そうなものだけど
物理的にピンをショートさせる勇気はないし、DDR5のリンクトレーニングを毎回何分も待ちながらRAMをゆっくりオーバークロックする忍耐もない
なので、メモリコントローラーがECCが有効だと報告していることで満足している
代わりに、ヘアドライヤーの温風をRAMに当てるのはどうだろう？ 以前、エラーを作るためにそういう手法を使うのを見たことがある
https://hackaday.com/2022/01/29/blast-chips-with-this-bbq-li...
https://hackaday.com/tag/emfi/
実運用には推奨されないが、メモリの限界を探したりエラーを作ったりするときには使える
私のI7-4770Kの非オーバークロックシステムではエラーが現れるが、古いSupermicro X10世代のボードではRowhammerテストを無期限に回してもエラーが検出されないようだ
ただし、最新システムがRowhammer攻撃に脆弱でないよう設計されているなら、この方法は通用しないかもしれない
Raspberry Pi 4BとCM4のRAMはECC RAMを使っているとされるが、ここで言うECCとは違う
これはオンダイECCで、チップ歩留まり改善が目的であり、ECCエラーはハードウェア経由では報告されず修正される
修正不能なECCエラーは、単に誤ったデータとして読み出されそうだ
最新のRAMモジュールもオンダイECC付きのチップを使っているのか気になる
リンクトレーニングはBIOSでオフにできるので、境界付近の帯域幅設定を素早く見つけられる
結果がそれほど再現性の高いものではないだろうが、それは重要ではない
一部、もしかするとすべてのASUS AM5マザーボードには公式のECCサポートがある
さっき確認したモデルのボードマニュアルとBIOSマニュアルの両方に載っていた
関連するBIOS設定の1つはデフォルトがAutoだが、直感に反してこの状態では無効になるので変更が必要
これらのプロセッサのECCレポート機能はLinux 6.5に入ったため、Debian StableユーザーはBackportsに入るのを待つか、正攻法から外れる必要がある
https://www.phoronix.com/news/AMD-EDAC-Ryzen-7000-Series
実際の適用値を見られるならまだましだが、十中八九は明確ではない
古いAGESAバージョンには、チップセットがECC RAMを正しく認識・活用できないようにするバグがあったという噂がある
そのチップセットは本来サポートするはずなのに、という話だ
検討中のマザーボードには、少なくともAGESA 1.0.0.5 patch Cを含むファームウェア更新があるか確認すべき
https://www.reddit.com/r/truenas/comments/10lqofy/
AGESAはAMDシステムファームウェアの一部で、主要なシステムコンポーネントを初期化する: https://en.wikipedia.org/wiki/AGESA
ECC RAMを取り付ける前にAGESA 1.0.0.7bへ更新した
Ryzen 7000シリーズがECCサポートを公式に明記していないとは知らなかった
たとえばASRock Rackラインはサポートしている: https://www.asrockrack.com/general/productdetail.asp?Model=1...
このASUSマザーボードもECCサポートをうたっている: https://www.asus.com/us/motherboards-components/motherboards...
どちらも私が最初にAM5マザーボードを買った当時は出ていなかった。発売直後で、性能数値が非常に良かったので早めに飛びついた
現在販売中のすべてのRyzen 7000シリーズCPUには公式のECCサポートがあるが、マザーボード側のサポートも必要
こうした条件付きECCサポートは、もともとAthlon 64にまで遡るAMDのコンシューマー向けCPUにずっとあったが、Ryzen 7000シリーズでAMDのマーケティング資料に明記されたのは初めて見る気がする
筆者が言っているのは、ASRockのマザーボード文書からECCサポートへの言及が消えたという意味
ASRockは以前のRyzenマザーボードでECCサポートを明記してきたので、目立つ変化だった
Ryzen 5 7600仕様ページの例: https://www.amd.com/en/product/12756#:~:text=ECC%20Support,R...)
そのうえ、すべてのDDR5が使うオンチップECCとも混同される
DDR5は通常動作中に発生するエラーを修正するためにオンチップECCを必要とするが、メモリバスを通じてCPUへ転送されるデータまで保護するECCではない