環境：Linux [ホスト名] 3.2.0-4-amd64＃1 SMP Debian 3.2.96-2 x86_64 GNU / Linuxハードウェア：AMD Opteron（tm）プロセッサ6344、6x2MiB L2、2x8MiB L3、6コアht（論理コア12）犬））））
今日のシステムログに次の警告が表示されました。
Feb 28 09:58:53 amalthea kernel: [4367033.060016] INFO: rcu_bh detected stall on CPU 10 (t=0 jiffies)
Feb 28 09:58:53 amalthea kernel: [4367033.060018] sending NMI to all CPUs:
以下はCPUステータスダンプです。ログには、この問題を引き起こす「悪い」内容がないようです。
サーバーはまだ実行中であり（明らかに）停止したプロセスなどがなく、警告が発生してから1時間ほど再発生しませんでした。
少し探しました。RCUストール検出器に関する情報（私にとってはあまりにも技術的です。本物わかります） 以下を見ることができます。
- CPUが停止しました。
t=0 jiffies - CPUが「検出されない」
ファイルには、これが偽の肯定である可能性があることを示す説明があります。
["ステータスダンプが開始される前に停止が終了しました"]はまれですが、実際には発生します。道路ゼロファストストールフラグ指定可能この場合、停止警告と猶予期間の初期化がどのように相互作用するかによって異なります。この種の問題には、不要なstop_machine（）などのメソッドを使用せずにこの誤った肯定を完全に削除することは不可能であることに注意してください。
(強調は私のもの)
「ステータスダンプの開始前に停止」というメッセージは表示されませんが、上記の2つのログ行の後に表示される大規模なCPUダンプ以外は、診断方法で他の情報を取得できないようです。
役に立つ場合は、CPUダンプでより多くの情報を投稿できます。専門家ではありませんが、何も見つかりませんでした。
この問題の原因は何ですか？t=0 jiffiesログに追加の診断情報を印刷せずに、データポイントのみに基づいて偽の肯定を得ることはできますか？
（この質問は次のように異なります。rcu_sched が CPU 停止を検出しました。、これは「実際の問題」を示すようです。 )
ベストアンサー1
これは、次の3つの理由のいずれかが原因で発生する可能性が高くなります。
- トリガーしにくいカーネルのバグです。しかし、RCUはカーネルのコアなので、ほとんど誰もがバグに直面する可能性が高いので、これは可能ではないと思います。
- 悪い記憶。不良メモリモジュールによるメモリ破損により、このような奇妙なことが容易に発生する可能性があります。
- メモリ自体以外の理由で発生する一時的なメモリエラーです。上記と似ていますが、再び起こる可能性はありません。これはECCメモリが防止しようとするタイプです（ただし、ECCロジックで問題が完全に可能であるため、完全ではありません）。
このようなことが再発しない限り、おそらくこれがケース3であると仮定して続行することができます。このようなことが再発した場合は、周辺カーネルメッセージで類似点を検索するか、RAMを確認してください。