私は4.14.93-rtカーネルの実行中にランダムなシステム停止をデバッグしようとしました。これを行うには、次の設定を使用してカーネルでロック検出器を有効にしました。
CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
目標は、ロックが発生したときにカーネルパニックを引き起こすことです。また、カーネルコマンドラインでNMI監視機能を有効にしました。
nmi_watchdog=1
kdump / kexecツールを使用して、カーネルがクラッシュしたときにカーネルの競合ダンプを生成するようにシステムを構成しました。このメカニズムは、パニックが手動でトリガーされたときに機能します。
echo c > /proc/sysrq-trigger
この場合、システムがダンプキャプチャカーネルをロードしていることを確認できます。ただし、実際のロックが発生すると、監視が有効になっている場合にのみシステムが再起動されます。私が知る限り、カーネルパニックは発生しません。ダンプキャプチャカーネルのスイッチはありません。コアダンプはなく、ログには何も保存されません。
関連するすべてのsysctlオプションを有効にしました。
kernel.panic = 1
kernel.panic_on_oops = 1
kernel.unknown_nmi_panic = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.panic_on_io_nmi = 1
kernel.softlockup_panic = 1
kernel.hung_task_panic = 1
実際のシステムが停止していることを経験したときに、この動作を見ました。これは、RT優先順位の高いすべてのコアでCPU集約型whileループを実行するときにも発生します。私はこれが保留中の操作として検出され、パニックを引き起こすと予想します。
この場合、パニック/kdumpメカニズムをトリガーせずに再起動を引き起こすのはなぜですか？