8

私のシステムはCentOS 6.3（実行中のカーネルバージョン2.6.32-279.el6.x86_64）です。

PCIeカードを管理するドライバーであるロード可能なカーネルモジュールがあります。OSの起動中にを使用して手動でドライバーを挿入するinsmodと、ドライバーは正常に読み込まれ、動作します。

ただし、rpmを使用してドライバをインストールしてからシステムを再起動しようとすると、起動中にOSがスタックし、すべてのCPUコアに対して次の「ソフトロックアップ」メッセージが出力されます。私のドライバーによって作成されたスレッドの1つ。

BUG: soft lockup - CPU#X stuck for 67s! [migration/8:36]
.......(same above message for all cores except one)
BUG: soft lockup - CPU#10 stuck for 67s! [mydriver_thread/8:36]
(one core is locked up in one of the threads in my driver).

私はこのカーネルのメッセージ/バグに関する情報をネットでかなり検索しましたが、それに関する投稿はかなりありますが、原因やデバッグ方法については何もありません。次の質問についての助けをいただければ幸いです。

  1. システムにログインできません。すべてのコアが「ソフトロックアップ」状態にあるため、シェルプロンプトからカーネルダンプをトリガーできないためだと思います。SysRqを有効にして、SysRqキーコンボを使用してカーネルダンプをトリガーしようとしましたが、うまくいきませんでした。システムがキーボードに応答していないようです（CapsLockボタンにも応答していません）。この状況でカーネルダンプをトリガーする方法について何か提案はありますか？

  2. 私のドライバースレッドが「ソフトロックアップ」を引き起こしている可能性を想像できます。しかし、私のドライバーのために、「移行」スレッド（カーネルスレッド）を「ソフトロックアップ」にするにはどうすればよいでしょうか。

  3. ネットの閲覧から、「移行」スレッドを使用して、あるCPUから別のCPUにタスクを移動します。誰かがこのスレッドが正確に何をするのか理解するのを手伝ってもらえますか？そして、もしあったとしても、他のスレッドによってどのように影響を受ける可能性があるか。

4

1 に答える 1

1

デスクトップで非常によく似た問題が発生しました。非常に頻繁にソフト ロックアップが発生します (1 日に 1 回程度)。

Intel Haswell で実行していたことが原因であることがわかりました。Intel プロセッサの Haswell/Broadwell シリーズには、システムを不安定にするバグがあるようです。このバグは、マイクロコードの更新で修正されました。

CentOS が intel-microcode パッケージを提供しているかどうかを確認し、インストールします。initramfs をロードする前に、grub を初期 ramdisk としてロードするように設定してください。

個人的には、Windows を起動して BIOS アップデートを実行することで、マイクロコードをアップグレードしました。grep 'microcode' /proc/cpuinfo更新前と更新後の出力を比較することで、マイクロコードが実際に更新されたかどうかを確認できます。

于 2016-06-14T12:36:12.930 に答える