同じメモリ位置に対してDRAMECCエラー通知を繰り返すことに応答して何をしますか？
私は今朝、私にとって初めてのことに目覚めました。私のシステムの1つがDRAM ECC error通知をログに記録していました。実際、それらのうちの3つは、まったく同じメモリ位置を知ることができる限り（明らかに、システムは実際にはlocalhostという名前ではありません）：
Aug 31 05:00:46 localhost kernel: [719099.816034] [Hardware Error]: CPU:0 MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c6c40006b080a13
Aug 31 05:00:46 localhost kernel: [719099.816046] [Hardware Error]: MC4_ADDR: 0x0000000641f49d20
Aug 31 05:00:46 localhost kernel: [719099.816051] [Hardware Error]: Northbridge Error (node 0): DRAM ECC error detected on the NB.
Aug 31 05:00:46 localhost kernel: [719099.816059] EDAC AMD64 MC0: CE ERROR_ADDRESS= 0x641f49d20
Aug 31 05:00:46 localhost kernel: [719099.816070] EDAC MC0: CE page 0x641f49, offset 0xd20, grain 0, syndrome 0x6bd8, row 2, channel 0, label "": AMD64_edac
Aug 31 05:00:46 localhost kernel: [719099.816075] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)
上記の後に、システム時刻05:10:46（719699.8160）で同じ通知が続き、次に05:20:46（720299.8160）でもう1つ通知があり、CPU:0 MC4_STATUS行にOverがありました（ステータス0xdc6c40006b080813）。これまでのところ、システムは安定しており、それ以上のエラーは記録されていません。システムアクティビティは正常であり、問題のシステムは2014年からECC RAMで実行されていますが、ECCエラーをログに記録することはありません。
修正可能な単一のECCエラーについてはあまり心配しません。 ログに記録されるエラーの間のほぼ正確に10分（実際には数マイクロ秒まで）である可能性があります。 RAMスクラブは10分ごとに発生します。残念ながら、この特定のシステムでは、スクラブ間隔は設定として公開されていません。ただし、3つの連続したエラー同じメモリ位置（CE ERROR_ADDRESSの同じ値）には少し心配があります。
更新：この質問を最初に投稿してから、問題のホストはさらにいくつかログを記録しました。すべてCE ERROR_ADDRESSの値は同じです。
これをどれだけ真剣に受け止めるべきですか？良い反応は何ですか;交換を注文するRAMすぐにインストールし、これを一時的な不具合として扱うか、交換する予定です= RAM再発したが、現在特定のアクションがない場合は？
ECC RAMは重要なサーバーで使用される傾向があります。システムはハードウェア障害を報告しています。重要なシステムではなく、すべてが破損する可能性があることを気にしない場合は、しばらくお待ちください。何が起こりますが、RAMのコストよりもデータに関心がある場合は、障害のあるRAMできるだけ早く交換してください。
私は今朝、私にとって初めてのことに目覚めました。私のシステムの1つがDRAMECCエラー通知をログに記録していました。 そのうちの3つは、実際には...単一の修正可能なECCエラーについてはあまり心配していません。ログに記録されるエラー間のほぼ正確に10分（実際には数マイクロ秒まで）は、単にRAMスクラブが発生しているためである可能性があります10分ごと。残念ながら、この特定のシステムでは、スクラブ間隔は設定として公開されていません。
メモリスクラビング に関するウィキペディアのウェブページは次のように述べています。
「DIMMモジュールの8％以上で、1年に少なくとも1つの修正可能なエラーが発生します。これは、DRAMおよびSRAMベースのメモリで問題になる可能性があります。個々のメモリビットでのソフトエラーの可能性は非常に小さいです。」.
「CPUからの通常のメモリ要求を妨げず、パフォーマンスの低下を防ぐために、スクラブは通常はアイドル期間にのみ実行されます。通常の読み取りおよび書き込み操作では、非スクラブ操作と比較してメモリの消費電力が増加する可能性があります。したがって、スクラビングは継続的にではなく定期的に実行されます。多くのサーバーでは、スクラブ期間はBIOSセットアッププログラムで構成できます。
そのウェブページには、スクラブ間隔を説明するSuperMicroX9SRAマザーボードマニュアルへのリンクが含まれています。
"パトロールスクラブ
パトロールスクラビングは、CPUがメモリモジュールで検出された修正可能なメモリエラーを修正し、その修正をリクエスター（元のソース）に送信できるようにするプロセスです。この項目が有効に設定されている場合、内部処理による遅延がない場合、ノースブリッジは16Kサイクルごとに1つのキャッシュラインを読み書きします 。この方法を使用すると、ノースブリッジの背後にある約64 GBのメモリが日ごとにスクラブされます。オプションは有効と無効です。」.
したがって、原因はスクラブによるものではありません。障害のあるビットがある可能性があります。障害が突然発生する可能性がありますが、特に頻繁に発生する場合は、障害が消えて戻ってくるのは奇妙に思えます。
「これをどれだけ真剣に受け止めるべきですか？良い対応は何ですか。すぐに交換RAMを注文し、できるだけ早くインストールするようにスケジュールするか、これを一時的な不具合として扱うか、RAMを交換する場合はすぐに交換してください。再び起こりますが、今のところ具体的な行動はありませんか？」
nohammer カーネルモジュールを発明したPavel Machekは、次のように述べています。
「偶然にロウハンマーをするのはかなり難しいので、叩いたら誰かが故意にやっているのだろう。……まあ、宇宙線とロウハンマーの間には3桁以上の違いがある。IIRC宇宙線が予想される1年に2ビットフリップを発生させる... rowhammer10分でビットフリップを実行できます。これは古いバージョンであり、最適化されたものの1つ。」.
RAMモジュールを交換して、エラーレポートがチップに続くのか、メモリの場所に固執するのか、それとも他の場所で発生するのかを確認できます。
HPE推奨 （障害のあるメモリモジュールの場合）：
「症状：OSログに次のエラーメッセージが表示されます。
Host1 kernel: Northbridge Error (node X): DRAM ECC error detected on the NB.
修正：
1。失敗したメモリモジュール番号を特定します（エラーに記載されている場合）
2。 IMLでメモリモジュールに関連するエラーを確認してください。 Ex Procxスロットx
3。システムのBIOSを更新する
4。エラーが見つからない場合は、診断を実行し、メモリモジュールを交換します（メモリモジュールを分離するためのメモリ診断の5〜6ループ）」
推奨される行動方針：
ソケットのRAMを切り替えると、それが特定のRAMモジュールであるか、他の回路に障害があるかがわかります。
数日ごとに1ビット以上のエラーが発生しない限り、パニックは発生しません（ラッシュ）。
10分ごとに攻撃を受けている場合は、可能性があります打撃を受けています。
参照： " カーネル内のRowHammerに対する防御 "および " ECCploit：結局のところRowhammer攻撃に対して脆弱なECCメモリ "。 ARMプロセッサの場合： " ARMに対するDMAベースのRowhammer攻撃を軽減するAndroid GuardIONパッチ "。
Memtest86 +を実行することをお勧めします
また、一部のディストリビューションには標準パッケージとして含まれています。
メモリモジュールの故障の疑いを確認する場合があります。