나는 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 메커니즘을 트리거하지 않고 재부팅을 일으키는 원인은 무엇입니까?