详解kdump原理与使用方法

嵌入式ARM 2023-07-14 13:30

一、kdump机制

简介

Kdump是在系统崩溃、死锁或死机时用来转储内存运行参数的一个工具和服务,是一种新的crash dump捕获机制,用来捕获kernel crash(内核崩溃)的时候产生的crash dump

Kdump 使用两个内核:生产内核和捕获内核。生产内核是一个普通内核,它使用特殊的 kdump 特定标志启动。我们需要告诉生产内核保留一些物理内存,用于加载捕获内核。我们需要提前加载捕获内核,因为在崩溃发生的那一刻,由于内核损坏,无法从磁盘读取任何数据。

生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启动起来,与相应的ramdisk一起组建一个微环境,用以对生产内核下的内存进行收集和转存。

第一个内核保留了内存的一部分给第二内核启动用。由于kdump利用kexec启动捕获内核,绕过了 BIOS,所以第一个内核的内存得以保留。这是内核崩溃转储的本质。

dump原理

为了在生产内核崩溃时能顺利启动捕获内核,捕获内核以及它的ramdisk是事先放到生产内核的内存中的

生产内核的内存是通过/proc/vmcore这个文件交给捕获内核的。为了生成它,用户工具在生产内核中分析出内存的使用和分布等情况,然后把这些信息综合起来生成一个ELF头文件保存起来。

捕获内核被引导时会被同时传递这个ELF文件头的地址,通过分析它,捕获内核就可以生成出/proc/vmcore。有了/proc/vmcore这个文件,捕获内核的ramdisk中的脚本就可以通过通常的文件读写和网络来实现各种策略了。

注意,在启动时,kdump保留了一定数量的重要的内存,为了计算系统需要的真正最小内存,加上kdump使用的内存数量,以决定真正的最小内存的需求。

支持架构

x86,x86_64,arm,arm64,ppc,s390,sh

二、kexec机制

kexec简介

Kexec是基于kexec机制工作的,因此先了解一下Kexec。

kexec是一个快速启动机制,允许通过已经运行的内核的上下文启动一个Linux内核,不需要经过BIOS。(BIOS可能会消耗很多时间,特别是带有众多数量的外设的大型服务器。这种办法可以为经常启动机器的开发者节省很多时间。)

Kexec的实现包括2个组成部分:

** 一是内核空间的系统调用:kexec_load() **,负责在生产内核(production kernel 或 first kernel)启动时将捕获内核(capture kernel或sencond kernel)加载到指定地址。

** 二是用户空间的工具kexec-tools **,他将捕获内核的地址传递给生产内核,从而在系统崩溃的时候能够找到捕获内核的地址并运行。没有kexec就没有kdump。先有kexec实现了在一个内核中可以启动另一个内核,才让kdump有了用武之地。

kexec_load()

kexec 在 kernel 里以一个系统调用 kexec_load()的形式提供给用户。这个系统调用主要用来把另一个内核和其 ramdisk 加载到当前内核中。在 kdump中,捕获内核只能使用事先预留的一小段内存。

生产内核的内存镜像会被以 /proc/vmcore 的形式提供给用户。这是一个 ELF格式的方件,它的头是由用户空间工具 kexec 生成并传递来的。在系统崩溃时,系统最后会调用machine_kexec()。这通常是一个硬件相关的函数。它会引导捕获内核,从而完成 kdump 的过程。

kexec-tools

kdump 的很大一部分工作都是在用户空间内完成的。与 kexec相关的集中在一个叫kexec-tools的工具中的kexec程序中。

该程序主要是为调用 kexec_load()收集各种信息,然后调用之。这些信息主要包括 purgatory 的入口地址,还有一组由 struct kexec_segment描述的信息。

最后,附上一张图,看下kdump和kexec整个的工作流程。

三、kdump使用

内核配置

修改内核中以下的配置宏,可在.config文件中修改,或者通过make menuconfig修改

CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEBUG_INFO=y

确认修改成功

root@firefly:/sys/kernel# ls /sys/kernel/ | grep kexec
kexec_crash_loaded
kexec_crash_size
kexec_loaded
root@firefly:~# ls /proc/ | grep kcore
kcore

如果出现proc/kcorekexec相关节点说明配置生效了。

配置预留内存

预留内存的4种形式

预留内存的设置一般有4种形式:

  1. 第一种是最常用的,直接通过size指定预留的大小,offset指定预留内存地址的起始位置。不过,offset一般不指定,对于一般用户来讲,很难确定预留内存恶起始位置。
crashkernel=size[KMG][@offset[KMG]]
  1. 第二种方式会根据系统的内存大小自动选择预留内存的大小,比较灵活。
crashkernel=range1:size1[,range2:size,...][@offset]

举例

crashkernel=512M-2G:64M,2G-6G:256M,6G-8G:512M,8G-:768M

参数含义如下:

如果RAM大小小于512M,则不预留内存。

如果RAM大小为512M - 2G,则预留 64M。

如果RAM大小为2 - 6G,则预留 256M。

如果RAM大小大于8G,则预留768 M。

  1. 一般我们会在0~4G范围内预留内存。如果系统内存大于4G,则支持在4G以上预留内存,比如X86_64架构。当指定high参数时,系统会在0~4G和4G以上预留两段内存。默认情况下,x86_64会在4G以下预留256M内存。
crashkernel=size[KMG],hign
  1. low参数主要是配合high来使用的。如果觉得4G以下默认预留的256M太多了,可以手动指定预留内存。
crashkernel=size[KMG],low

在ARM上配置预留内存

在X86-64主机上一般是修改/etc/default/grup中的参数来配置及检查, 但是在嵌入式设备上因为是裁剪的系统,并没有grup这个文件。

但我们可以知道,配置grup文件的目的就是更改cmdline中的内容,那我们如何去更改cmdline的内容呢?提供以下几个思路:

  • 在dts中中添加:修改chosen
  • 在BoardConfig中添加
  • 在uboot中添加:在源码中添加或者通过setenv配置bootargs变量
  • 在android的Makefile中添加

这里我们选择在dts中修改。

vim kernel/arch/arm64/boot/dts/rockchip/rk3399-linux.dtsi   

当前使用的设备RAM已经是4G,所以预留的是256M

root@firefly:~# free -m
              total        used        free      shared  buff/cache   available
Mem:           3583         194        3154           8         234        3351
Swap:             0           0           0

重新编译烧写内核,看到设备启动时,已经加入了启动参数。

查看启动参数是否生效

root@firefly:~# cat /proc/iomem | grep Crash
e5e00000-f5dfffff : Crash kernel

确认分配内存大小

root@firefly:~# cat /sys/kernel/kexec_crash_size
268435456

预留内存大小评估

在某些情况下,我们需要正确评估预留内存的大小,主要从以下2个方面考虑。

  1. 系统内kernel,initrd,romfs,devices driver的大小。
  2. 捕获内核启动cpu的个数。启动cpu越多,需要的内存越大。一般情况下,捕获内核一般启动一个CPU核即可。

/proc/iomem表示的是系统的物理内存布局, System RAM entry表示当前系统可用的预留内存。例如,我当前设备的内存为3.8G,预留800M内存也是足够的。

root@firefly:~# cat /proc/iomem | grep System
00200000-083fffff : System RAM
0a200000-f7ffffff : System RAM 

编译kexec工具

  1. 从下面的网站下载最新的kexec-tools源码包。
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz
  1. 解压源码包。
tar xvpzf  kexec-tools-2.0.26.tar.gz 
  1. 进入到kexec-tools中,并进行配置。
LDFLAGS=-static ./configure ARCH=arm64 --build=x86_64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --without-xen

这里使用静态编译。

  1. 然后使用make进行编译。
make
  1. 将build目录下sbin/kexec 拷贝至rootfs /usr/sbin/中。
root@firefly:~/kexec/sbin# kexec -v
kexec-tools 2.0.26

查看kexec参数。

root@firefly:~# kexec -h
kexec-tools 2.0.26
Usage: kexec [OPTION]... [kernel]
Directly reboot into a new kernel

 -h,           Print this help.
 -v, --version        Print the version of kexec.
 -f, --force          Force an immediate kexec,
                      don't call shutdown.
 -i, --no-checks      Fast reboot, no memory integrity checks.
 -x, --no-ifdown      Don'
t bring down network interfaces.
 -y, --no-sync        Don't sync filesystems before kexec.
 -l, --load           Load the new kernel into the
                      current kernel.
 -p, --load-panic     Load the new kernel for use on panic.
 -u, --unload         Unload the current kexec target kernel.
                      If capture kernel is being unloaded
                      specify -p with -u.
 -e, --exec           Execute a currently loaded kernel.
     --exec-live-update Execute a currently loaded xen image after
storing the state required to live update.
 -t, --type=TYPE      Specify the new kernel is of this type.
     --mem-min= Specify the lowest memory address to
                      load code into.
     --mem-max= Specify the highest memory address to
                      load code into.
     --reuseinitrd    Reuse initrd from first boot.
     --print-ckr-size Print crash kernel region size.
     --load-preserve-context Load the new kernel and preserve
                      context of current kernel during kexec.
     --load-jump-back-helper Load a helper image to jump back
                      to original kernel.
     --load-live-update Load the new kernel to overwrite the
                      running kernel.
     --entry=   Specify jump back address.
                      (0 means it'
s not jump back or
                      preserve context)
                      to original kernel.
 -s, --kexec-file-syscall Use file based syscall for kexec operation
 -c, --kexec-syscall  Use the kexec_load syscall for for compatibility
                      with systems that don't support -s (default)
 -a, --kexec-syscall-auto  Use file based syscall for kexec and fall
                      back to the compatibility syscall when file based
                      syscall is not supported or the kernel did not
                      understand the image
 -d, --debug          Enable debugging to help spot a failure.
 -S, --status         Return 1 if the type (by default crash) is loaded,
                      0 if not.

Supported kernel file types and options: 
vmlinux
     An ARM64 ELF image, big or little endian.
     Typically vmlinux or a stripped version of vmlinux.

Image
     An ARM64 binary image, uncompressed, big or little endian.
     Typically an Image file.

uImage
     An ARM64 U-boot uImage file, compressed or not, big or little endian.

zImage
     An ARM64 zImage, compressed, big or little endian.
     Typically an Image.gz or Image.lzma file.

Architecture options: 
     --append=STRING       Set the kernel command line to STRING.
     --command-line=STRING Set the kernel command line to STRING.
     --dtb=FILE            Use FILE as the device tree blob.
     --initrd=FILE         Use FILE as the kernel initial ramdisk.
     --serial=STRING       Name of console used for purgatory printing. (e.g. ttyAMA0)
     --ramdisk=FILE        Use FILE as the kernel initial ramdisk.
     --reuse-cmdline       Use kernel command line from running system.

注意以下几个参数

-d: 执行kexec指令时会打印调试信息 
-p: 将内核加载到预留内存中,panic时自动启动capture内核。
-l: 将内核加载到预留内存中
--append : capture内核的command line的内容
--t: 内核的类型,比如vmlinux,Image,uImage,zImage
--intrd:指定initrd
--reuseinitrd:复用第一个内核的initrd
--dtb:指定设备树

vmlinux,Image,uImage,zImage区别参考:secure boot (一)FIT Image

四、测试

配置kexec

尝试手动配置kexec

kexec --t vmlinux -p /root/var/vmlinux --ramdisk /root/var/ramdisk.img --append="storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal  storagenode=sdhci@fe330000 androidboot.slot_suffix= androidboot.serialno=3fdce35e50641399  ro 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=256M"

command line 可以通过 cat /proc/cmdline  查看。

ramdisk.img 也可以叫做initrd.img,  它是一个小文件系统,麻雀虽小五脏俱全,它介于kernel 和 文件系统之间。kernel 启动后会先执行ramdisk.img 里面的init, 挂载这里的小型文件系统,接着开始完成一些必要的操作,最后在交给文件系统/sbin/init 进行执行。

查看捕获内核的加载状态 0:未加载,1:已加载

root@firefly:~# cat /sys/kernel/kexec_crash_loaded 
1

查看捕获内核的大小

root@firefly:~# cat /sys/kernel/kexec_crash_size
268435456

确认 kexec_load_disabled 的状态

root@firefly:~# cat /proc/sys/kernel/kexec_load_disabled
0

kexec_load_disabled:表示kexec_load系统调用是否被禁止,此系统调用用于kdump。当发生了一次kexec_load后,此值会自动设置为1。

测试启动捕获内核

在前面的准备工作完成后,如果触发系统崩溃,系统将重新引导到转储-捕获内核,触发点位于panic()die()die_nmi()和sysrq处理程序中。接下来我将通过 魔术键来触发系统panic。

开启sysrq

echo 1 > /proc/sys/kernel/sysrq 

触发sysrq

echo c > /proc/sysrq-trigger

触发sysrq后,系统重启,串口打印出标志性 log:Bye!Starting crashdump kernel...。

[06:48:37]root@firefly:~# echo c > /proc/sysrq-trigger
[06:48:37][   28.817657] sysrq: SysRq : Trigger a crash
[06:48:37][   28.818172] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[06:48:37][   28.818894] pgd = ffffffc0deb9d000
[06:48:37][   28.819326] [00000000] *pgd=0000000000000000, *pud=0000000000000000
....................
[06:48:37][   28.950698] [] sysrq_handle_crash+0x24/0x30
[06:48:37][   28.951218] [] __handle_sysrq+0xa0/0x14c
[06:48:37][   28.951713] [] write_sysrq_trigger+0x5c/0x74
[06:48:37][   28.952246] [] proc_reg_write+0xa8/0xcc
[06:48:37][   28.952744] [] __vfs_write+0x48/0xe8
[06:48:37][   28.953214] [] vfs_write+0xa8/0x15c
[06:48:37][   28.953674] [] SyS_write+0x5c/0xb0
[06:48:37][   28.954123] [] el0_svc_naked+0x24/0x28
[06:48:37][   28.954609] Code: 52800020 b90a1c20 d5033e9f d2800001 (39000020) 
[06:48:37][   28.955167] SMP: stopping secondary CPUs
[06:48:37][   28.955899] Starting crashdump kernel...
[06:48:37][   28.956264] Bye!
[06:48:51][    0.000000] Booting Linux on physical CPU 0x101
[06:48:51][    0.000000] Initializing cgroup subsys cp    0.000000] Initializing cgrouys cpu
[06:48:51][    0.000000] Initializys cpuacct
[06:48:51][    0.000000] Linux version 4.4.194+ (zhongyi@ubunty: b1730021dd51a88c333473088af3a402491b4c23) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05SMP Fri Mar 3 07:48:00 CST 2023
[06:48:51][    0.000000] Boot CPU: AArch64 Processor [410fd082]
[06:48:51][    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (opti '')
[06:48:51][    0.000000] bootconsole [uart0] enabled
[06:48:51][    0.000000] cannot allocate crashkernel (size:0x10000000)
[06:48:51][    0.000000] Reserving 1KB of memory at 0xf5dff000 for elfcorehdr
[06:48:51][    0.000000] psci: probing for conduit method from DT.
[06:48:51][    0.000000] psci: PSCIv1.0 detected in firmware.
[06:48:51][    0.000000] psci: Using standard PSCI v0.2 function IDs
[06:48:52][    0.000000] psci: Trusted OS migration not required
[06:48:52][    0.000000] PERCPU: Embedded 21 pages/cpu @ffffffc035cf1000 s46440 r8192 d31384 u86016
[06:48:52][    0.000000] Detected PIPT I-cache on CPU0
[06:48:52][    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64512
[06:48:52][    0.000000] Kernel command line: storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal  storagenode=sdhci@fe330000 androidboot.slot_suffix= androidboot.serialno=3fdce35e50641399  ro 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=256M
[06:48:52][    0.000000] PID hash table entries: 1024 (order: 1, 8192 bytes)
[06:48:52][    0.000000] Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
[06:48:52][    0.000000] Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
[06:48:52][    0.000000] software IO TLB: mapped [mem 0xf5c51000-0xf5c91000] (0MB)
[06:48:52][    0.000000] Memory: 208908K/262144K available (14782K kernel code, 2146K rwdata, 6988K rodata, 1216K init, 780K bss, 53236K reserved, 0K cma-reserved)
[06:48:52][    0.000000] Virtual kernel memory layout:
[06:48:52][    0.000000]     modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
[06:48:52][    0.000000]     vmalloc : 0xffffff8008000000 - 0xffffffbdbfff0000   (   246 GB)
[06:48:52][    0.000000]       .init : 0xffffff80095d0000 - 0xffffff8009700000   (  1216 KB)
[06:48:52][    0.000000]       .text : 0xffffff8008080000 - 0xffffff8008ef0000   ( 14784 KB)
[06:48:52][    0.000000]     .rodata : 0xffffff8008ef0000 - 0xffffff80095d0000   (  7040 KB)
[06:48:52][    0.000000]       .data : 0xffffff8009700000 - 0xffffff8009918808   (  2147 KB)
[06:48:52][    0.000000]     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
[06:48:52][    0.000000]               0xffffffbdc0978000 - 0xffffffbdc0d78000   (     4 MB actual)
[06:48:52][    0.000000]     fixed   : 0xffffffbffe7fb000 - 0xffffffbffec00000   (  4116 KB)
[06:48:52][    0.000000]     PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
[06:48:52][    0.000000]     memory  : 0xffffffc025e00000 - 0xffffffc035e00000   (   256 MB)
[06:48:52][    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
.........................................
[06:48:54][    2.313003] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops)
[06:48:54][    2.314207] i2c i2c-10: of_i2c: modalias failure on /dp@fec00000/ports
[06:48:54][    2.315077] rockchip-drm display-subsystem: bound fec00000.dp (ops cdn_dp_component_ops)
[06:48:54][    2.315815] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[06:48:54][    2.316404] [drm] No driver support for vblank timestamp query.
[06:48:54][    2.317133] rockchip-drm display-subsystem: connector[HDMI-A-1] can't found any modes
.................................................
[06:48:58][    6.180434] [dhd] dhd_conf_set_path_params : Final conf_path=/vendor/etc/firmware/config.txt
[06:48:58][    6.313492] [dhd] dhd_conf_set_txglom_params : txglom_mode=multi-desc
[06:48:58][    6.314159] [dhd] dhd_conf_set_txglom_params : txglomsize=36, deferred_tx_len=0
[06:48:58][    6.314868] [dhd] dhd_conf_set_txglom_params : txinrx_thres=128d_txminmax=-1
[06:48:58][    6.315529] [ddhd_conf_set_txglom_params : tx__offset=0, txctl_tmo_fix=300
[06:48:58][    6.316245] [dhd] dhd_conf_get_disable_proptx : fw_proptx=1, disable_proptx=-1
[06:48:58][    6.380768] [dhd] dhd_conf_map_country_list : CN/38
[06:48:58][    6.381222] [dhd] dhd_conf_set_country : set country CN, revision 38
[06:48:58][    6.385992] [dhd] dhd_conf_set_country : Country code: CN (CN/38)
[06:48:58][  OK  ] Started Network Manager.
[06:48:58][  OK  ] Reached target Network.
[06:48:58]         Starting Permit User Sessions...
[06:48:58]         Starting OpenBSD Secure Shell server...
[06:48:58][  OK  ] Started Permit User Sessions.
[06:48:58]         Starting Hold until boot process finishes up...
[06:48:58][  OK  ] Started Hold until boot process finishes up.
[06:48:58][  OK  ] Started Serial Getty on ttyFIQ0.
[06:48:58]         Starting Set console scheme...
[06:48:58][  OK  ] Started Set console scheme.
[06:48:58][  OK  ] Created slice system-getty.slice.
[06:48:58][  OK  ] Started Getty on tty1.
[06:48:58][  OK  ] Reached target Login Prompts.
[06:48:58][  OK  ] Started OpenBSD Secure Shell server.
[06:48:58][  OK  ] Started Adbd for linux.
[06:48:58][  OK  ] Started Setup rockchip platform environment.
[06:48:58]         Starting Light Display Manager...
[06:48:58][  OK  ] Reached target Multi-User System.
[06:48:59][  OK  ] Started Light Display Manager.
[06:48:59][  OK  ] Reached target Graphical Interface.
[06:48:59]         Starting Update UTMP about System Runlevel Changes...
[06:48:59][  OK  ] Started Update UTMP about System Runlevel Changes.
[06:48:59]
[06:48:59]Ubuntu 18.04.6 LTS firefly ttyFIQ0  
[06:49:39]root@firefly:~# ls -al /proc/vmcore 
[06:49:41]-r-------- 1 root root 3885387776 Mar  5 22:49 /proc/vmcore
[06:50:24]root@firefly:~# ls -al --block-size=m   /proc/vmcore 

系统正常启动后,就可以将/proc/vmcore文件拷贝出来在ubuntu上用crash工具分析。

五、常见问题及解决办法

在ARM平台上,系统崩溃后卡死,未启动第二内核

不清楚是宿主机的原因还是代码原因,目前主线的 Linux kernel 代码在执行命令使第一个内核崩溃之后,跳转到第二个内核的过程中卡死,在社区上也有其他人遇到了类似的情况并给出了补丁,但是并没有合并到主线,不过目前为了演示暂时不考虑为何原因导致这个问题的出现,如果你的 arm64 不存在这个问题,那么就不需要打这个补丁了。奉上补丁如下:

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index aa9c94113700..3b0350d20e31 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -234,19 +234,12 @@ static void machine_kexec_mask_interrupts(void)

        for_each_irq_desc(i, desc) {
                struct irq_chip *chip;
-               int ret;

                chip = irq_desc_get_chip(desc);
                if (!chip)
                        continue;

-               /*
-                * First try to remove the active state. If this
-                * fails, try to EOI the interrupt.
-                */
-               ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
-
-               if (ret && irqd_irq_inprogress(&desc->irq_data) &&
+               if (irqd_irq_inprogress(&desc->irq_data) &&
                    chip->irq_eoi)
                        chip->irq_eoi(&desc->irq_data);

还有一点需要说明的就是在 Ubuntu 默认仓库的 crash 不支持最新版本的 Linux 内核,需要更新到 7.2.5 版本才可以。

没有生产vmcore

按照kdump执行流程,确定问题来自那个阶段。

预留内存失败

预留内存过大,设备没有足够的可用内存。默认会在0~4G预留内存。比如预留512M的空间,而在0~4G并没有可用的512M空间,就会导致预留失败。

加载内核失败

  1. 是否预留内存,crashkernel是否配置?

  2. 预留内存失败。

  3. 预留内存成功:尝试使用kexec -d -p 查看失败的具体原因。

第二内核启动失败

  1. 打印出bye后没有任何信息输出,可能是第二内核可能未配置串口,earlycon/console

  2. oom后卡死,可能是预留内存太小。

  3. 驱动初始化失败。有些驱动,比如dma32,可能只能使用0~4G内存,在4G以上预留内存会导致驱动加载失败。

makedumpfile失败

加上-D,打印出debug选项,查看失败原因。

用户态工具问题

kernel,kexec,makedumpfile,crash匹配问题,更新到最新的工具。

六、本文参考

https://lore.kernel.org/lkml/ba0c6804-51a3-f36e-a67e-20ce84961451@arm.com/T/

https://www.cnblogs.com/shineshqw/articles/2359114.html

https://wiki.archlinux.org/title/Kdump

https://kaiwantech.wordpress.com/2017/07/13/setting-up-kdump-and-crash-for-arm-32-an-ongoing-saga/

https://juejin.cn/post/7115949300147814430

https://blog.csdn.net/Luckiers/article/details/124581570

END

来源:嵌入式与Linux那些事

版权归原作者所有,如有侵权,请联系删除。

推荐阅读
分享一套面向MCU的前后台系统
STM32的ADC用法,你知道几种?
走嵌入式方向,一定要软硬件都懂?

→点关注,不迷路←

嵌入式ARM 关注这个时代最火的嵌入式ARM,你想知道的都在这里。
评论 (0)
  • 文/Leon编辑/cc孙聪颖‍2025年1月至今,AI领域最出圈的除了DeepSeek,就是号称首个“通用AI Agent”(智能体)的Manus了,其邀请码一度被炒到8万元。很快,通用Agent就成为互联网大厂、AI独角兽们的新方向,迅速地“卷”了起来。国外市场,Open AI、Claude、微软等迅速推出Agent产品或构建平台,国内企业也在4月迅速跟进。4月,字节跳动、阿里巴巴、百度纷纷入局通用Agent市场,主打复杂的多任务、工作流功能,并对个人用户免费。腾讯则迅速更新腾讯元器的API接
    华尔街科技眼 2025-05-12 22:29 148浏览
  •   定制软件开发公司推荐清单   在企业数字化转型加速的2025年,定制软件开发需求愈发多元复杂。不同行业、技术偏好与服务模式的企业,对开发公司的要求大相径庭。以下从技术赛道、服务模式及行业场景出发,为您提供适配的定制软件开发公司推荐及选择建议。   华盛恒辉科技有限公司:是一家专注于高端软件定制开发服务和高端建设的服务机构,致力于为企业提供全面、系统的开发制作方案。在部队政企开发、建设到运营推广领域拥有丰富经验,在教育,工业,医疗,APP,管理,商城,人工智能,部队软件、工业软件、数字化转
    华盛恒辉l58ll334744 2025-05-12 15:55 332浏览
  • 递交招股书近一年后,曹操出行 IPO 进程终于迎来关键节点。从 2024 年 4 月首次递表,到 2025 年 4 月顺利通过中国证监会境外发行上市备案,并迅速更新招股书。而通过上市备案也标志着其赴港IPO进程进入实质性推进阶段,曹操出行最快有望于2025年内完成港股上市,成为李书福商业版图中又一关键落子。行路至此,曹操出行面临的挑战依然不容忽视。当下的网约车赛道,早已不是当年群雄逐鹿的草莽时代,市场渐趋饱和,竞争近乎白热化。曹操出行此时冲刺上市,既是背水一战,也是谋篇布局。其招股书中披露的资金
    用户1742991715177 2025-05-10 21:18 104浏览
  •   基于 2025 年行业权威性与时效性,以下梳理国内知名软件定制开发企业,涵盖综合型、垂直领域及特色技术服务商:   华盛恒辉科技有限公司:是一家专注于高端软件定制开发服务和高端建设的服务机构,致力于为企业提供全面、系统的开发制作方案。在部队政企开发、建设到运营推广领域拥有丰富经验,在教育,工业,医疗,APP,管理,商城,人工智能,部队软件、工业软件、数字化转型、新能源软件、光伏软件、汽车软件,ERP,系统二次开发,CRM等领域有很多成功案例。   五木恒润科技有限公司:是一家专业的部队信
    华盛恒辉l58ll334744 2025-05-12 16:13 250浏览
  • 感谢面包板论坛组织的本次测评活动,本次测评的对象是STM32WL Nucleo-64板 (NUCLEO-WL55JC) ,该测试板专为LoRa™应用原型构建,基于STM32WL系列sub-GHz无线微控制器。其性能、功耗及特性组合经过精心挑选,支持通过Arduino® Uno V3连接,并利用ST morpho接头扩展STM32WL Nucleo功能,便于访问多种专用屏蔽。STM32WL Nucleo-64板集成STLINK-V3E调试器与编程器,无需额外探测器。该板配备全面的STM
    无言的朝圣 2025-05-13 09:47 149浏览
  • 在 AI 浪潮席卷下,厨电行业正经历着深刻变革。AWE 2025期间,万得厨对外首次发布了wan AiOS 1.0组织体超智能系统——通过AI技术能够帮助全球家庭实现从健康检测、膳食推荐,到食材即时配送,再到一步烹饪、营养总结的个性化健康膳食管理。这一创新之举并非偶然的个案,而是整个厨电行业大步迈向智能化、数字化转型浪潮的一个关键注脚,折射出全行业对 AI 赋能的热切渴求。前有标兵后有追兵,万得厨面临着高昂的研发成本与技术迭代压力,稍有懈怠便可能被后来者赶
    用户1742991715177 2025-05-11 22:44 177浏览
  • 在当下竞争激烈的 AI 赛道,企业高层的变动往往牵一发而动全身,零一万物近来就深陷这样的动荡漩涡。近日,零一万物联合创始人、技术副总裁戴宗宏离职创业的消息不胫而走。这位在大模型基础设施领域造诣颇深的专家,此前在华为云、阿里达摩院积累了深厚经验,在零一万物时更是带领团队短期内完成了千卡 GPU 集群等关键设施搭建,其离去无疑是重大损失。而这并非个例,自 2024 年下半年以来,李先刚、黄文灏、潘欣、曹大鹏等一众联创和早期核心成员纷纷出走。
    用户1742991715177 2025-05-13 21:24 105浏览
  • ‌磁光克尔效应(Magneto-Optic Kerr Effect, MOKE)‌ 是指当线偏振光入射到磁性材料表面并反射后,其偏振状态(偏振面旋转角度和椭偏率)因材料的磁化强度或方向发生改变的现象。具体表现为:1、‌偏振面旋转‌:反射光的偏振方向相对于入射光发生偏转(克尔旋转角 θK)。2、‌椭偏率变化‌:反射光由线偏振变为椭圆偏振(克尔椭偏率 εK)。这一效应直接关联材料的磁化状态,是表征磁性材料(如铁磁体、反铁磁体)磁学性质的重要非接触式光学探测手段,广泛用于
    锦正茂科技 2025-05-12 11:02 297浏览
  • 在印度与巴基斯坦的军事对峙情境下,歼10C的出色表现如同一颗投入平静湖面的巨石,激起层层涟漪,深刻印证了“质量大于数量”这一铁律。军事领域,技术优势就是决定胜负的关键钥匙。歼10C凭借先进的航电系统、强大的武器挂载能力以及卓越的机动性能,在战场上大放异彩。它能够精准捕捉目标,迅速发动攻击,以一敌多却毫不逊色。与之形成鲜明对比的是,单纯依靠数量堆砌的军事力量,在面对先进技术装备时,往往显得力不从心。这一现象绝非局限于军事范畴,在当今社会的各个领域,“质量大于数量”都已成为不可逆转的趋势。在科技行业
    curton 2025-05-11 19:09 256浏览
  •   电磁数据展示系统平台解析   北京华盛恒辉电磁数据展示系统平台是实现电磁数据高效展示、分析与管理的综合性软件体系,以下从核心功能、技术特性、应用场景及发展趋势展开解读:   应用案例   目前,已有多个电磁数据展示系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润电磁数据展示系统。这些成功案例为电磁数据展示系统的推广和应用提供了有力支持。   一、核心功能模块   数据采集与预处理   智能分析处理   集成频谱分析、时频变换等信号处理算法,自动提取时域频域特征;
    华盛恒辉l58ll334744 2025-05-13 10:20 359浏览
  • 【拆解】+CamFi卡菲单反无线传输器拆解 对于单反爱好者,想要通过远程控制自拍怎么办呢。一个远程连接,远程控制相机拍摄的工具再合适不过了。今天给大伙介绍的是CamFi卡菲单反无线传输器。 CamFi 是专为数码单反相机打造的无线传输控制器,自带的 WiFi 功能(无需手机流量),不但可通过手机、平板、电脑等设备远程连接操作单反相机进行拍摄,而且还可实时传输相机拍摄的照片到 iPad 和电视等大屏设备进行查看和分享。 CamFi 支持大部分佳能和尼康单反相机,内置可充电锂离子电池,无需相机供电。
    zhusx123 2025-05-11 14:14 406浏览
  •         信创产业含义的“信息技术应用创新”一词,最早公开信息见于2019年3月26日,在江苏南京召开的信息技术应用创新研讨会。本次大会主办单位为江苏省工业和信息化厅和中国电子工业标准化技术协会安全可靠工作委员会。        2019年5月16日,美国将华为列入实体清单,在未获得美国商务部许可的情况下,美国企业将无法向华为供应产品。       2019年6
    天涯书生 2025-05-11 10:41 199浏览
  •   舰艇电磁兼容分析与整改系统平台解析   北京华盛恒辉舰艇电磁兼容分析与整改系统平台是保障海军装备作战效能的关键技术,旨在确保舰艇电子设备在复杂电磁环境中协同运行。本文从架构、技术、流程、价值及趋势五个维度展开解析。   应用案例   目前,已有多个舰艇电磁兼容分析与整改系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润舰艇电磁兼容分析与整改系统。这些成功案例为舰艇电磁兼容分析与整改系统的推广和应用提供了有力支持。   一、系统架构:模块化智能体系   电磁环境建模:基
    华盛恒辉l58ll334744 2025-05-14 11:22 45浏览
  • 在全球供应链紧张和国产替代需求推动下,国产存储芯片产业快速发展,形成设计到封测一体化的完整生态。北京君正、兆易创新、紫光国芯、东芯股份、普冉股份和佰维存储等六大上市公司在NOR/NAND Flash、DRAM、嵌入式存储等领域布局各具特色,推动国产替代提速。贞光科技代理的品牌紫光国芯,专注DRAM技术,覆盖嵌入式存储与模组解决方案,为多领域客户提供高可靠性产品。随着AI、5G等新兴应用兴起,国产存储厂商有望迎来新一轮增长。存储芯片分类与应用易失性与非易失性存储芯片易失性存储芯片(Volatile
    贞光科技 2025-05-12 16:05 200浏览
  •   电磁数据管理系统深度解析   北京华盛恒辉电磁数据管理系统作为专业的数据处理平台,旨在提升电磁数据的处理效率、安全性与可靠性。以下从功能架构、核心特性、应用场景及技术实现展开分析:   应用案例   目前,已有多个电磁数据管理系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润电磁数据管理系统。这些成功案例为电磁数据管理系统的推广和应用提供了有力支持。   一、核心功能模块   数据采集与接入:实时接收天线、频谱仪等设备数据,兼容多协议接口,确保数据采集的全面性与实时性
    华盛恒辉l58ll334744 2025-05-13 10:59 270浏览
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦