在RK3399移植kdump的问题
尝试在RK3399上移植kdump，所有参数配置正确。尝试用echo c > /proc/sysrq-trigger 触发panic，只有一次设备进入了转储流程。附件是日志。[ 90.693264] rk808 0-001b: Failed to sync masks in 4d
[ 90.693726] rk808 0-001b: Failed to ack 0x4c: -11
[ 90.694164] rk808 0-001b: Failed to sync masks in 4f
[ 90.694627] rk808 0-001b: Failed to ack 0x4e: -11
[ 90.695064] Starting crashdump kernel...
[ 90.695430] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
不过，并没有重启完成，启动到一半卡住了。中间打印了很多报错。
[ 4.613455] dhd_deferred_work_init: work queue initialized
[ 4.613986] dhd_tcpack_suppress_set: TCP ACK Suppress mode 0 -> mode 2
[ 4.614649] get_mem_val_from_file: File doesn't exist
[ 4.615404] dhd_get_memdump_info: MEMDUMP ENABLED = 3
[ 4.615902] sdioh_cis_read: func_cis_ptr=0x10ac
[ 4.620725] dhdsdio_probe_init: making DHD_BUS_DOWN
[ 4.621296] Dongle Host Driver, version 100.10.545.19 (r826445-20210324-3)
[ 4.622409] Register interface MAC: d4:12:43:8b:d5:4e
[ 4.622409]
[ 4.623096] dhdsdio_probe : the lock is released.
[ 4.623656] dhd_module_init: Exit err=0
当我重启设备，配置好kexec后，触发panic，设备无法进入转储流程了？问题出在哪里了，有了解的大佬吗？
以下是我的配置流程：
root@firefly:~# cat /proc/iomem | grep Crash
c5e00000-f5dfffff : Crash kerne
kexec --t vmlinux -p /root/var/vmlinux --append="storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normalstoragenode=sdhci@fe330000 androidboot.slot_suffix= androidboot.serialno=3fdce35e50641399ro rootwait earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 console=ttyFIQ0 root=PARTLABEL=rootfs rootfstype=ext4 overlayroot=device:dev=PARTLABEL=userdata,fstype=ext4,mkfs=1 coherent_pool=1m systemd.gpt_auto=0 cgroup_enable=memory swapaccount=1 crashkernel=768M"
root@firefly:~# cat /sys/kernel/kexec_crash_loaded
1
root@firefly:~# cat /sys/kernel/kexec_crash_size
805306368
root@firefly:~# cat /proc/sys/kernel/kexec_load_disabled
root@firefly:~# echo 1 > /proc/sys/kernel/sysrq
root@firefly:~# echo c > /proc/sysrq-trigger
Call trace:
Exception stack(0xffffffc0be88fb30 to 0xffffffc0be88fc60)
fb20: ffffff80097a9968 0000008000000000
fb40: ffffffc0be88fd00 ffffff80085abed8 000000000000000f 0000000000000000
fb60: ffffff80099202f8 0000000000000002 ffffffc0be88fb90 000000030001b568
fb80: 00000000000000c3 0000000100000000 ffffffc0be88fc30 ffffff800810f6ec
fba0: ffffffc0be88fc90 ffffff80093fd151 ffffff800972a000 0000000000000004
fbc0: 0000000000000063 0000000000000000 0000000000000001 0000000000000000
fbe0: ffffffc0f7dbb320 0000000000000000 0000000000000000 0000000000000000
fc00: 0000000000000010 ffffff80097884b0 ffffff8008468ccc 7f7f7f7f7f7f7f7f
fc20: 71277660716d73ff 7f7f7f7f7f7f7f7f 0101010101010101 0000000000000000
fc40: 0ffffffffffffffe 0000000000000000 ffffff80081e990c 0000007fb0743058
[<ffffff80085abed8>] sysrq_handle_crash+0x24/0x30
[<ffffff80085ac9a8>] __handle_sysrq+0xa0/0x14c
[<ffffff80085acdd4>] write_sysrq_trigger+0x5c/0x74
[<ffffff8008244948>] proc_reg_write+0xa8/0xcc
[<ffffff80081e86dc>] __vfs_write+0x48/0xe8
[<ffffff80081e8fc8>] vfs_write+0xa8/0x15c
[<ffffff80081e9968>] SyS_write+0x5c/0xb0
[<ffffff8008082f70>] el0_svc_naked+0x24/0x28
Code: 52800020 b90a1c20 d5033e9f d2800001 (39000020)
SMP: stopping secondary CPUs卡在这里
附件是成功进入的转储的日志。
页:
[1]