Ich teste die Funktion zum Absturz des Kernel-Image mit einem arm64-Gerät, die Kernel-Version ist Linux 5.4. Jetzt löse ich den Kernel-Absturz über „echo c > /proc/sysrq-trigger“ aus, dann löst der Kernel einen Nullzeiger-Absturz aus und speichert den Kontext, dann startet er den zweiten Kernel. Jetzt sehe ich einen Neustart des Kernels ohne Protokoll, also muss ich die Ursache für den Neustart des Kernels herausfinden.
Das Konsolenprotokoll lautet:
AP488B:/# echo c > /proc/sysrq-trigger
[04/17/2023 12:41:26.4299] Kernel panic - not syncing: sysrq triggered crash
[04/17/2023 12:41:26.4299] CPU: 1 PID: 8523 Comm: ash Kdump: loaded Tainted: P E 5.4.164 #29
[04/17/2023 12:41:26.4999] Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK02 (DT)
[04/17/2023 12:41:26.6099] Call trace:
[04/17/2023 12:41:26.7099] dump_backtrace+0x0/0x15c
[04/17/2023 12:41:26.7499] show_stack+0x14/0x1c
[04/17/2023 12:41:26.8099] dump_stack+0xb4/0xf8
[04/17/2023 12:41:26.8599] panic+0x154/0x358
[04/17/2023 12:41:26.9199] sysrq_handle_reboot+0x0/0x20
[04/17/2023 12:41:26.9599] __handle_sysrq+0xa0/0x158
[04/17/2023 12:41:27.0299] write_sysrq_trigger+0x98/0xa8
[04/17/2023 12:41:27.0799] proc_reg_write+0x58/0x94
[04/17/2023 12:41:27.1499] __vfs_write+0x18/0x38
[04/17/2023 12:41:27.1999] vfs_write+0xd4/0x18c
[04/17/2023 12:41:27.2599] ksys_write+0x70/0xd8
[04/17/2023 12:41:27.3099] __arm64_sys_write+0x14/0x1c
[04/17/2023 12:41:27.3699] el0_svc_common.constprop.0+0xfc/0x17c
[04/17/2023 12:41:27.4299] el0_svc_handler+0x7c/0x84
[04/17/2023 12:41:27.4999] el0_svc+0x8/0x680
[04/17/2023 12:41:27.5999] SMP: cpu1 stopping secondary CPUs 0,2-3
jG▒Ԉ8▒%▒o▒#▒▒▒▒▒H▒▒
8B▒▒▒H▒▒
Board type: C9124AX
U-Boot DEV 2016.01 (btldr release 38) (Mar 31 2023 - 14:02:16 -0700)