精华内容
下载资源
问答
  • 2021-05-15 05:05:46

    Written by

    arstercz

    -2019-11-12

    Linux 系统内核崩溃分析处理简介

    背景说明

    目前绝大多数的 Linux 发行版都会将 kdump.service 服务默认开启, 以方便在内核崩溃的时候, 可以通过 kdump 服务提供的 kexec 机制快速的启用保留在内存中的第二个内核来收集并转储内核崩溃的日志信息(vmcore 等文件), 这种机制需要服务器硬件特性的支持, 不过现今常用的服务器系列均已支持.

    如果没有特别设置, 系统都采用默认的 kdump 服务配置, 崩溃的日志文件默认以 disk 方式保存在本地的磁盘目录, Centos/Redhat 系列的系统主要保存在以下目录:

    /var/crash/

    一般生成的 vmcore 文件仅仅是内核崩溃时的一部分信息, 如果全部导出对磁盘和时间都是很大的消耗, 默认情况下, dump 的级别为 31, 仅导出内核态的数据, 详见 makedumpfile -d 选项. 这种情况下系统崩溃一般生成的 vmcore 文件大小受崩溃时内核占用的内存决定, 通常不会很大. 下面则主要介绍如何收集并简单分析这些 vmcore 文件.

    目录列表

    获取 vmcore

    我们在主机中分析 vmcore 文件的时候需要系统安装对应内核版本的 debuginfo 安装包以便获取函数的符号信息. 以如下内核版本为例:

    kernel-3.10.0-957.27.2.el7.x86_64 -- 系统内核版本

    kernel-debuginfo-3.10.0-957.27.2.el7.x86_64 -- 安装对应的 debuginfo 版本

    所以想要快速的分析 vmcore 文件大概可以采用以下两种方式:

    1. 在出问题的机器中直接安装对应版本的 debuginfo 包;

    2. 将 vmcore 文件推到指定的主机进行分析;

    上面两种方式都需要在主机中安装 crash 工具, 第一种方式相对快速, 不过会修改服务的主机, 另外也不容易大范围的安装到线上的所有机器. 第二种方式较慢, 具体取决于传输的速度, 不过很适合对线上故障的汇总分析.

    我们通常采用第二种方式, 可以修改 kdump 配置以 nfs 或 ssh 方式将生成的日志传到指定的机器, 也可以在问题主机重启后手动传到指定的机器. 当然主机间通信的速度要足够快, 崩溃日志传送完成后才会开始重启操作, 所以越慢就意味着机器正常重启需要的时间越长, 相应的从内核崩溃到可以简单的 crash 分析之间的时间间隔就越大.

    分析 vmcore

    安装 debuginfo 包的目的在于获取对应内核版本的符号信息(vmlinux 文件), 所以我们可以在指定机器中收集了业务运行的所有发行版内核对应的 debuginfo 包和内核源代码文件(方便查看代码), 如下所示:

    /data/

    ├── kernel-crash -- 收到的各主机的 vmcore 文件

    ├── kernel-debuginfo -- 对应线上内核版本的 debuginfo 文件

    ├── kernel-package -- 常用的 kernel 安装包

    └── kernel-source -- 对应线上内核版本的源码文件

    可以通过 rpm2cpio 的方式解压不同版本的 rpm 包来获取文件. 比如以下示例:

    mkdir /data/kernel-debuginfo-3.10.0-957.21.3

    pushd /data/kernel-debuginfo-3.10.0-957.21.3

    rpm2cpio /data/kernel-package/kernel-debuginfo-3.10.0-957.21.3.el7.src.rpm | cpio -div

    popd

    kernel-debuginfo 和 kernel-source 目录中存储了各内核版本对应的文件, 如下所示:

    /data/kernel-debuginfo/

    ├── kernel-debuginfo-2.6.32-642.13.1.el6.x86_64

    ├── kernel-debuginfo-3.10.0-862.14.4.el7.x86_64

    ├── kernel-debuginfo-3.10.0-957.21.3.el7.x86_64

    └── kernel-debuginfo-3.10.0-957.27.2.el7.x86_64

    /data/kernel-source/

    ├── linux-2.6.32-642.13.1.el6

    ├── linux-3.10.0-862.14.4.el7

    ├── linux-3.10.0-957.21.3.el7

    ├── linux-3.10.0-957.27.2.el7

    通过 crash 命令指定 vmcore 文件对应版本的 vmlinux 文件即可简单分析 vmcore 文件, 如下所示:

    # crash /data/kernel-debuginfo/kernel-debuginfo-3.10.0-957.21.3.el7.x86_64/usr/lib/debug/lib/modules/3.10.0-957.21.3.el7.x86_64/vmlinux vmcore

    crash 7.2.3-10.el7

    ......

    KERNEL: /export/kernel-debuginfo/kernel-debuginfo-3.10.0-957.21.3.el7.x86_64/usr/lib/debug/lib/modules/3.10.0-957.21.3.el7.x86_64/vmlinux

    DUMPFILE: vmcore [PARTIAL DUMP]

    CPUS: 40

    ...

    RELEASE: 3.10.0-957.21.3.el7.x86_64

    ...

    PANIC: "BUG: unable to handle kernel NULL pointer dereference at (null)"

    PID: 167966

    COMMAND: "java"

    TASK: ffff880103d74500 [THREAD_INFO: ffff880013c68000]

    CPU: 11

    STATE: TASK_RUNNING (PANIC)

    crash> bt

    PID: 167966 TASK: ffff880103d74500 CPU: 11 COMMAND: "java"

    #0 [ffff880013c6ba38] machine_kexec at ffffffff81051beb

    #1 [ffff880013c6ba98] crash_kexec at ffffffff810f2782

    #2 [ffff880013c6bb68] oops_end at ffffffff8163ea48

    #3 [ffff880013c6bb90] no_context at ffffffff8162eb28

    #4 [ffff880013c6bbe0] __bad_area_nosemaphore at ffffffff8162ebbe

    #5 [ffff880013c6bc28] bad_area_nosemaphore at ffffffff8162ed28

    #6 [ffff880013c6bc38] __do_page_fault at ffffffff8164184e

    #7 [ffff880013c6bc98] do_page_fault at ffffffff816419e3

    #8 [ffff880013c6bcc0] page_fault at ffffffff8163dc48

    [exception RIP: unknown or invalid address]

    RIP: 0000000000000000 RSP: ffff880013c6bd78 RFLAGS: 00010282

    RAX: ffff880103d74500 RBX: ffff880013c6be10 RCX: ffff880013c6bfd8

    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880103d74500

    RBP: 0000000000000000 R8: ffff880013c68000 R9: 0000000000000018

    R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001

    R13: 00007f7e88012454 R14: ffffc9001ce8efc0 R15: ffff880013c6bd60

    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

    ......

    crash>

    可以参考 crash-book 学习更多的调试技巧.

    分析 vmcore 的目的

    内核崩溃时会将 kernel buffer 中的信息写到 vmcore-dmesg.txt 文件, 不过由于缺乏符号信息我们一般难以找到更细致的线索. 而 vmcore 文件仅导出了部分内核转储日志, 实际上也不一定准确, 不过可以提供汇编和代码级的信息. 通常需要我们结合两个文件共同查看. 不过在实际的使用中, 存在很大的局限性, 因为很多时候难以确定问题的具体原因, 即便确定了原因我们可能也难以升级内核, 如果没有单独维护补丁更新, 就无法使用 kpatch 等在线升级功能. 所以从这方面来看, 每次出现内核崩溃的时候, 我们分析 vmcore 的目的主要在于以下几点:

    1. 明白内核崩溃的大致原因;

    2. 可以对内核崩溃的原因做更细致的分析;

    3. 可以对故障事件做代码级别的分类和汇总;

    4. 方便第三方厂商(如果购买了服务)分析原因定位问题;

    线上处理注意事项

    kdump 配置问题

    如果出现内核问题的频率不高, kdump 生成的日志可以仍旧以默认配置为主, 日志会存放到本地的 /var/crash 目录:

    # grep ^path /etc/kdump.conf

    path /var/crash

    如果产生的频率较高, 可以配置 ssh 选项, 将产生的崩溃日志直接发送到对应内网的其它机器. 注意内网通信的速度要够快, 越慢则意味着传送文件的速度越慢, 机器正常重启需要的时间越长. 配置 ssh 选项需要注意以下设置:

    # /etc/kdump.conf

    path /var/crash

    ssh kerenl-crash@collect-host

    default dump_to_rootfs # 如果 ssh 失败则选择将日志转储到本地磁盘路径

    core_collector makedumpfile -l --message-level 1 -d 31 -F # 如果启用 ssh, 则增加 -F 选项, 使导出到远程机器的数据日志为 flattened 格式.

    启用 ssh 选项需要在 makedumpfile 命令中增加 -F 选项, 数据会以 flattened 格式存储, 如果 ssh 失败则以本地磁盘的标准格式存储. 远程主机收到日志后, 以 flat 为后缀名, 通过 -R 选项可以将 flat 格式转为标准格式, 如下所示:

    makedumpfile -R vmcore < vmcore.flat

    快速查看原因

    在需要快速了解崩溃原因的时候, 可以简单查看崩溃主机(如果重启成功)的 vmcore-dmesg.txt 文件, 该文件列出了内核崩溃时的堆栈信息, 有助于我们大致了解崩溃的原因, 方便处理措施的决断. 如下所示为生成的日志文件通常的路径:

    /var/crash/127.0.0.1-2019-11-11-08:40:08/vmcore-dmesg.txt

    加快 vmcore 分析

    vmcore 文件的大小受 kdump 参数 dump 级别决定, 默认为 31 仅导出内核态的数据. 这种级别下一般由崩溃时内核占用的内存决定. 可以查看 /proc/meminfo 的 Slab 信息查看内核态大概的数据, 通常情况下 vmcore 都会小于 slab 的值. vmcore 传到指定的机器需要一定的时间, 如果传输较慢, 可以将 vmcore 文件拉倒对应内网机器进行分析. 该机器需要提前装好对应内核版本的 debuginfo 包, 当然不用非要 rpm 安装, 我们可以将 debuginfo 包通过 rpm2cpio 方式解压出来单独存放到指定的目录.

    备注: 使用 crash 工具分析 vmcore 文件的时候通常会出现 [PARTIAL DUMP] 的提示, 这种提示一般在设置 dump 级别的时候进行提示, 更多可以参考 bugzella-857111.

    处理反馈及建议

    在分析具体原因的时候我们可以遵循以下的规则尽快给业务人员反馈处理建议:

    1. 快速查看 vmcore-dmesg 文件了解大概的故障原因;

    2. 如果碰到过此类问题就参考知识库的处理;

    3. 如果没有碰到过, 需要单独分析 vmcore 日志, 在指定时间内反馈处理建议;

    4. 反馈后再慢慢分析可能的原因和处理方式, 汇总成知识库;

    参考

    更多相关内容
  • Linux 内核崩溃

    2021-11-15 23:05:12
    最近做了一块板子发现在跑速的时候,linux内核会偶发性崩溃,差了一两个星期了也没找出原因,希望大神能够分析一下!
  • 基于网络的Linux内核崩溃转储机制.pdf
  • 追风 2009.03.05概述当系统出现panic的时候,kdump(内核崩溃转储机制)会通过调用kexec来快速的启动预先准备好的dump-capture kernel.该启动方式与快速启动机制类似,不会经过BIOS,属于热启动。dump-capturekernel ...

    追风 2009.03.05

    概述

    当系统出现panic的时候,kdump(内核崩溃转储机制)会通过调用kexec来快速的启动

    预先准备好的dump-capture kernel.该启动方式与快速启动机制类似,不会经过BIOS,属于热启动。dump-capture

    kernel 启动后,前一个内核运行时的内存镜像会被保存到/proc/vmcore,可以通过cp

    或者scp将其vmcore文件拷贝到磁盘上。重启系统后,即可通过分析工具对刚才保存的vmcore文件进行分析,查找导致panic的原因。

    dump-capture

    kernel

    启动只是使用少量的内存,并且这些内存由第一个内核提供。这样设计保证了第一个内核启动且正在运行中的DMA不会破坏第二个内核的运行。在内核崩溃之前所

    有有关于核心映像的必要信息都用ELF格式编码并储存在预先保留的内存区域中。

    目前kdump和kexec只支持x86,x86_64,ppc64,ia64这四种架构。

    设置

    1.安装kexec-tools工具,至于如何安装,在此不再多说。

    2.编译支持kdump的系统内核,我们叫他primary kernel。

    确认以下内核选项已经被打开并重编内核。

    1) 使能"kexec system call => Processor type and features." ,使内核支持kexec系统调用

    CONFIG_KEXEC=y

    2) 使能"Filesystem" => "Pseudo

    filesystems."=> "sysfs file system support"

    CONFIG_SYSFS=y

    意:如果"General Setup."=>"Configure standard kernel features (for small

    system)" 没有打开的话,"sysfs file system support"可能并不会在"Pseudo

    filesystems."中出现,如果是这种情况,可以直接检查.config文件,确认CONFIG_SYSFS是不是已经开启。

    grep 'CONFIG_SYSFS' .config

    3)使能"Kernel hacking."=>"Compile the kernel with debug info" ,保证编译出的内核带有调试符号。因为dump分析工具在读取和分析dump文件时需要这些调试符号。

    CONFIG_DEBUG_INFO=Y

    3.编译dump-capture kernel

    针对不同的架构,内核选项也有不同,但是不论哪种架构,以下两个选项是必选的

    "Processor type and features"=> "kernel crash dumps"

    CONFIG_CRASH_DUMP=y

    "Filesystems" => "Pseudo filesystems"=>"/proc/vmcore support"

    CONFIG_PROC_VMCORE=y

    (当CONFIG_CRASH_DUMP 被选中时,CONFIG_PROC_VMCORE会被自动选中)

    下面我们看一下针对不同的架构,编译内核还有哪些特殊的选项

    1)i386 和x86_64

    *在i386上,使能高内存支持"Processor type and features"=>"high memory support"

    CONFIG_HIGHMEM64G=y

    or

    CONFIG_HIGHMEM4G

    *在i386 和x86_64上,关闭"Processor type and features"=>"symmetric multi-processing support"

    CONFIG_SMP=n

    如果没有将该选项设为n,则需要在加载dump-capture kernel时指定参数maxcpus=1。

    *如果想编译一个加载地址可浮动的内核,则选中"Processor type and features"=>"Build a relocatable kernel"

    CONFIG_RELOCATABLE=y

    *设置合适的值给"Processor type and features"=>"Physical address where the kernel is loaded"

    该值的设置与内核加载地址是否是可浮动的(即是否选中CONFIG_RELOCATABLE)有关。

    如果内核加载地址不可浮动, 则该值必须与crashkernel=Y@X中的X相同(至于crashkernel=Y@X的含义即如何使用将在后面讲到),例如:crashkernel=64M@16M,则CONFIG_PHYSICAL_START=0x100000

    0。

    如果内核加载地址可浮动,则CONFIG_PHYSICAL_START的值便可不必在意,使用默认的即可。不过为了保险起见,为了能使kdump正确执行,CONFIG_PHYSICAL_START的值不论在何时,都要于X的值相同。

    2)ppc64

    除了前面两个必须的选项,其余选项默认即可。

    3)ia64

    除了前面两个必须的选项,其余选项默认即可。

    4.准备好两个内核后,即可按如下步骤使用kdump

    1)使用primary kernel启动系统,但是要在启动参数中加入“crashkernel=Y@X”,Y表示为dump-capture kernel 预留了多少内存空间,X该段空间的起始地址,即内核选项中CONFIG_PHYSICAL_START的值。

    对于x86和x86_64架构,一般使用crashkernel=64M@16M,CONFIG_PHYSICAL_START=0x1000000

    对于ppc64架构,一般使用crashkernel=128M@32M,CONFIG_PHYSICAL_START=0x2000000

    对于ia64架构,通常使用crashkernel=256M@256M。

    2)加载dump-capture kernel

    系统启动后,即可加载dump-capture kernle。

    不同的架构,可以选择使用为压缩的dump-capture kernle (vmlinux) 或者压缩过的dump-capture kernle(bzImage/vmlinuz)。

    i386 和x86_64:

    如果dump-capture kernel编译时未选中CONFIG_RELOCATABLE,则只能使用vmlinux

    如果dump-capture kernel编译时打开了CONFIG_RELOCATABLE,则可以使用bzImage/vmlinuz

    ppc64 :

    只能使用vmlinux

    ia64:

    可以使用vmlinux或者vmlinuz.gz

    加载方法:

    kexec -p \

    --initrd=--args-linux \

    --append="root="

    dump-capture-kernel-vmlinux-image:表示存放dump-capture kernel 的路径

    initrd-for-dump-capture-kernel:表示initrd的路径,如果没有,可以省略该参数

    --args-linux:表示Pass linux kernel style options,没看明白什么意思,但是ia64架构不需要加这个参数,其他架构都要有。

    --append:该参数后跟内核启动参数。

    arch-

    specific-options:内核启动参数的一部分,该处根据不同架构,填写不同参数。 i386, x86_64 和 ia64 填"1

    irqpoll maxcpus=1 reset_devices",ppc64填"1 maxcpus=1 noirqdistrib

    reset_devices"。

    注:

    默认情况下,ELF文件头采用ELF64格式存储以支持那些拥有超过4GB内存的系统。但是可以指定

    “--elf32-core-headers”标志以

    强制使用ELF32格式的ELF文件头。这个标志是有必要注意的,一个重要的原因就是:当前版本的GDB不能在一个32位系统上打开一个使用ELF64格

    式的vmcore文件。ELF32格式的文件头不能使用在一个“没有物理地址扩展”(non-PAE)的系统上。(即是说,少于4GB内存的系统)

    1这个参数,将启动“转储捕捉内核”到一个没有网络支持的单用户模式。如果你希望有网络支持,那么使用“init 3”

    maxcpus=1,这个前面说过,如果CONFIG_SMP=n,则需要在启动参数中加入maxcpus=1。

    irqpoll 的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率。

    举例:

    kexec

    -p  /boot/vmlinux_capture --args-linux --append="root=/dev/nfs rw

    nfsroot=128.224.149.6:/tftpboot/cxu/15554/rootfs ip=dhcp

    console=ttyS0,115200 1 maxcpus=1 noirqdistrib reset_devices"

    3)测试kdump是否成功

    手动产生一个crash:echo c > /proc/sysrq-trigger。

    或者可以些一个强制产生crash的模块。

    如果成功,系统将会进入热启动过程,系统启动完成后,可以执行一下uname -a ,看看内核的名字是不是有-kdump的标签呢?

    然后就可以把生成的转储文件vmcore拷贝出来了,直接cp即可:

    cp /proc/vmcore 也可以通过/dev/oldmem这个设备将其考出:

    cd ~

    mknod /dev/oldmem c 1 12

    dd if=/dev/oldmem of=oldmem.001

    成功将vmcore拷贝出来后即可重启系统了。

    4)分析vmcore文件

    在开始分析“转储文件”之前,应该确定重启到一个稳定的内核。

    可以使用GDB在‘转储文件’上做有限的分析。分析的时候需要“带有调试信息的vmlinux文件”(编译的时候带有-g选项),运行如下命令:

    gdb vmlinux vmcore

    注意:GDB不能分析x86平台上以ELF64格式产生的“内核转储文件”。在一个最大内存为4GB的系统上,可以通过在“转储捕捉内核”上指定“--elf32-core-headers”标志来使用ELF32格式的文件头。

    也可以使用Crash工具集来分析Kdump产生的“内核转储文件”,crash 工具可以到网上下载:

    ~anderson/

    以上文档主要是翻译自内核自带文档linux/Documentation/kdump/kdump.txt,部分使用自己的语言表达。如有错误,请指正。

    阅读(987) | 评论(0) | 转发(0) |

    展开全文
  • 进入系统领域一段时间,在arm、x86、mips等一些平台见过许多系统内核崩溃的瞬间,伴随着串口异常打印。分析并处理过许多异常问题,也算对系统异常、系统内核崩溃等相关问题具备了一定程度认知。 异常问题分析思路 ...

    系统核心异常分析方法

    进入系统领域一段时间,在arm、x86、mips等一些平台见过许多系统内核崩溃的瞬间,伴随着串口异常打印。分析并处理过许多异常问题,也算对系统异常、系统内核崩溃等相关问题具备了一定程度认知。

    异常问题分析思路

    1. 分析异常问题,必定需要借助异常产生时的寄存器信息进行分析。需要知道产生异常的原因,发生异常的程序上下文是在什么位置,这些关键性信息只能通过异常时抓取的通用寄存器值进行分析,以及推论。
    2. 首先来说是产生异常的诱因。一般不同架构的芯片异常种类不尽相同,比如:x86不存在非对齐异常,但arm和mips都存在非对齐异常。所以不同架构的CPU要有针对性的去查看它的异常向量表,从而找到异常类型,不同的类型的异常,是分析问题的基本方向,也是思考并解决问题的大概思路。一般较成熟的异常管理机制会通过操作系统提供更多异常相关信息,以使更易于判断异常产生形式,如:产生异常是核心态或用户态,根据异常产生的代码上下文,可以人为的划分故障类型等。
    3. 产生异常的上下文。明确异常上下文是分析异常问题的起点,异常上下文只能通过产生异常时的通用寄存器值得到。至关重要的是产生异常的指令地址,函数调度返回地址。
    4. 分析异常基本原因。通过反汇编*.elf,并结合产生异常的指令地址,确认指令功能、指令访问的通用寄存器,并结合通用寄存器值,基本可以确认产生异常的原因。
    5. 结合反汇编代码找出异常指令对应的C代码位置。不管反汇编解析的程度如何,这个环节都是决定能否解决异常问题的关键,也是前期所有铺垫工作的目的,需要花时间找到异常C代码的准确位置,以承接后续的分析工作。部分简单的异常问题到这一步就可以宣告结束了,即:通过分析代码可知异常根因;对于复杂的异常问题到这步也就是正式进入分析的状态。
    6. 后续的异常问题分析,其实与常规问题已经没有差异了,就是通过通用寄存器值、内存数据建立逻辑分析,通过调试、打印都可以,将关键信息显示出来,一步一步分析。

    x86架构

    以常用的32位x86为例,分析x86异常问题:
    EIP:个人习惯称之为PC。主要用于存放当前代码段即将被执行的下一条指令的偏移,但其本质上并不能直接被指令直接访问。这个寄存器指令由控制转移指令、中断及异常所控制。读操作通过执行call指令并取得栈中所存放的地址来实现,而写操作则通过修改程序栈中的返回指令指针并执行RET/IRET指令来完成。
    EBP:基址针寄存器。是在x86平台进行栈回溯的关键寄存器。
    解决x86异常问题首要关注点都是EIP,其次会关注EBP及其它通用寄存器。x86没有arm架构中类似LR的专用寄存器,这与x86的函数调用实现机制有关,x86使用call指令调用某段代码,会先将EIP压栈,当调用ret/iret相关指令是会将栈上的内容先出栈给EIP。当试图在x86寻找LR时,可使用*(EBP + 偏移)得到,实时上这已经是栈回溯干的事了,所以在x86平台一般是直接通过EBP进行栈回溯,以获取完整的函数调用路径。
    其它比较在意的寄存器,EFLAGS算一个,用于标识当前指令执行的状态。其它寄存器随意看看寄存器值就行,不是说其它寄存器不重要,只是分析异常问题时参与度没那么高,往往它们其中某个寄存器保留着异常产生的关键线索。

    arm(aarch32)架构

    ARMV7架构。
    R15(PC):要执行的下一条指令地址,就存放在此处,每次指令执行完,就自动+4。
    R14(LR):程序跳转后,返回地址就保存到此处。
    从上面两个寄存器的定义来看,在结合编译器开优化也不会导致arm汇编代码排序大乱,arm的汇编代码简直不要太友好,这就是arm的精简指令集的优势所在吗。
    除了PC和LR,arm中的CPSR和SPSR也比较重要,arm的状态管理比较复杂,如果问题出在CPSR或SPSR上,有得分析啊。啊

    分析异常问题重点关注R15、R14就行,其它寄存器看看就行。

    arm64(aarch64)架构

    ARMV8架构。
    arm和arm64就是两个架构。
    PC:指令指针寄存器, 保存CPU将要执行的下一条指令的地址。
    X30(LR):用于保存子程序的返回地址。
    CPSR:标志寄存器。
    个人认为arm64汇编比arm更友好。

    mips架构

    EPC:属于CP0寄存器,用于保存造成异常的那条指令的地址。CP0是协处理器。处理异常问题将其当做PC就行。
    $31(ra):用于存放子程序返回地址。处理异常问题将其当做LR就行。
    MIPS架构只用过Loongson的芯片,CP0使用的是GS264。
    说到Loongson就不得不说其自研的延时槽机制,所谓延时槽基本理解是:跳转指令会消耗大量指令周期,故执行跳转指令前会进行预加载。在汇编代码中往往会看到跳转指令后还紧跟一条指令,该指令的实际执行时机是在执行跳转指令之前。延时槽,简而言之,就是指令的时空错位。
    如果要评论Loongson平台的汇编:时空错位意难寻,要问汇编天花板,得看O(2)优化加Loongson。

    展开全文
  • 默认Ubuntu 12.04没有配置内核崩溃自动重启及转存,造成发生内核崩溃的时候,没有core dump文件去分析,并且卡死在内核崩溃界面,为了方便查找内核崩溃原因,需要将内核崩溃自动重启配置及内核转存配置起来,配置...

    默认Ubuntu 12.04没有配置内核崩溃自动重启及转存,造成发生内核崩溃的时候,没有core dump文件去分析,并且卡死在内核崩溃界面,为了方便查找内核崩溃原因,需要将内核崩溃自动重启配置及内核转存配置起来,配置步骤如下:

    第一步 配置内核崩溃自动重启

    添加kernel.panic到内核参数,10为内核崩溃10秒之后,自动重启系统

    vi /etc/sysctl.conf

    kernel.panic = 10

    第二步 验证自动重启机制是否生效,需要配置sysrq

    添加kernel.sysrq 到内核参数,1为生效

    vi /etc/sysctl.conf

    kernel.sysrq = 1

    运行命令,使配置的参数生效,或者重启系统

    sysctl -p /etc/sysctl.conf

    检查配置的参数是否生效

    5d606d6d0293fce4b9bbd8e7db360073.png

    62ad104b5f64a62131040d555763c705.png

    模拟系统内核崩溃,同时按alt+sysrq+c三个键,或者运行如下命令

    echo c  >/proc/sysrq

    看以看到内核崩溃,并读秒重启

    5e4ab00bd54fde3689d1de6b00a52a63.png

    第三步 配置内核转存

    新装的系统需要升级下,否则不能通过apt-get安装软件

    apt-get update

    安装内核转存

    sudo apt-get install linux-crashdump

    查看是否生效

    c22e83ad755c7076dea7cf3340c19cac.png

    测试,模拟系统内核崩溃,同时按alt+sysrq+c三个键,或者运行如下命令

    发现系统崩溃,并卡死住,没有发送转存,也没有重启!

    961aa99cc57bae01bb4ed6bec719d262.png

    经过查找资料,发送这样的情况,可能和core dump内存配置不够有关系,于是修改了core dum内存配置

    9927b211ca4504833e97bab0e8be95dd.png

    修改成512M大小

    8ecdf7d684ec8efc4b74521ca8fccca2.png

    重新生成grub.cfg

    9cae93b74c50338f855a0d86f9b14743.png

    再测试,成功。

    f138492acfc6ea8e514816617ece506b.png

    0b1331709591d260c1c78e86d0c51c18.png

    展开全文
  • 查看内核崩溃日志

    2021-05-26 15:07:50
    /proc/last_kmsg /sys/fs/pstore/console-ramoops
  • centos7 内核崩溃分析

    2021-05-11 08:50:53
    关于kdump 和 crashdump是一种kernel crash dump的机制,它可以在内核crash时保存系统的内存信息用于后续的分析。kdump是基于kexec的。crash是一个用于交互式地分析正在运行的Linux系统或者kernel crash后的core ...
  • kdump相关概念standard...Crash(capture)kernel 捕获内核 ,linux系统崩溃后使用的内核。Kdump需要配置两个不同目的的kernel,其中一个我们在这里称作standard(production) kernel;另外一个称之为Crash(ca...
  • linux内核报错自动重启After a kernel panic, it is impossible to remotely connect to the Linux server to reboot it by SSH. How to make the panic ... 内核崩溃后,无法通过SSH远程连接到Linux服务器以重新...
  • 卸载重装过,网上各种方法都试了,下面有两个方法这个最好用。 方法1: 来源:用jupyter notebook画图就kernel dead_时透透郎酱的博客-CSDN博客 在最前面单独输入 %pylab inline import matplotlib.pyplot as ...
  • Linux 内核崩溃 引导修复 rescue 救援笔记 vmlinuxz-2.6.32-220.el6.x86_64 initramfs-2.6.32-220.el6.x86_64.img kernel 相关文件丢失:
  • pstore的主要功能是存储linux内核崩溃前的内核日志,具体可参考内核文档介绍: linux-4.19.125\Documentation\admin-guide\ramoops.rst 也可以参考宋宝华老师的博客:Linux pstore 实现自动“抓捕”内核崩溃日志_宋...
  • 本文首先介绍了 crash 的基本概念和安装方法,其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件,包括各种常用调试命令的使用方法,最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。...
  • 最近在回顾kdump内核崩溃转储技术,刚好可以整理下相关知识点,系统性地讲解下Kdump的部署过程以及原理。 kdump内核崩溃转储技术在处理linux内核遇到宕机等异常问题中,可以将其崩溃瞬间的内存映像(包括函数栈,...
  • 关于kdump 和 crashkdump是一种kernel crash dump的机制,它可以在内核crash时保存系统的内存信息用于后续的分析。kdump是基于kexec的。crash是一个用于交互式地分析正在运行的Linux系统或者kernel crash后的core ...
  • 首先安装必选包:apt-get -y install aptitude kdump-tools crash kexec-tools makedumpfile linux-image-`uname -r`-dbgaptitude full-upgrade # 避免运行的内核版本与调试的版本不一致导致无法调试Kdump配置文件 /...
  • linux kdump Kdump是获取崩溃的Linux内核转储的一种方法,但是要找到说明其用法和内部结构的文档可能会很困难。 在本文中,我将研究kdump使用的基础知识,并研究kdump / kexec内核实现的内部。 Kexec是Linux内核到...
  • Linuxpstore实现自动“抓捕”内核崩溃日志.pdf
  • Ubuntu 手动更新glibc导致内核崩溃(无法正常关机/开机启动失败) 问题:Ubuntu 手动更新glibc导致内核崩溃,无法正常关机,开机启动失败,开机界...
  • Linux使用addr2line工具定位内核崩溃(oops)代码位置示例定位异常代码行 示例 在驱动代码中增加空指针操作,内核崩溃 [ 5.529101] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ...
  • 模拟linux内核崩溃

    千次阅读 2018-06-07 15:24:32
    1、一条简单的命令即可 echo c &... /proc/sysrq-trigger 操作系统会进入内核崩溃模式; 1.1简单的操作系统会进入系统崩溃模式,比如:cirros 1.2成熟的操作系统会重启操作系统,比如:centos7...
  • 内核崩溃时,可以从 pc 寄存器得知崩溃发生时的函数、出错指令。但是很多情况下,错误有可能是它的调用者引入的,所以找出函数的调用关系也很重要。 使用 Oops 的栈信息手工进行栈回溯 前面说过,从 Oops 信息的 pc ...
  • 服务器内核崩溃 Kump 分析
  • 随着嵌入式Linux系统的广泛应用,对系统的可靠性提出了更高的要求,尤其是涉及到生命财产等重要领域,要求系统达到安全完整性等
  • 问题描述 DisabledFunctionError: cv2.imshow() is disabled in Colab, because it causes Jupyter sessions to crash;... 问题解决 如果使用的是 google colab,用此解决方案,替换报错的那一行: ...
  • linux内核崩溃调试

    千次阅读 2019-06-25 10:33:08
    https://www.ibm.com/developerworks/cn/linux/l-cn-kdump4/index.html?ca=drs ... 用kdump 和 crash 工具分析内核的奔溃信息 当linux内核发生崩溃的时候,可以用kdump等方式...
  • 在为wifi驱动添加新功能的时候,使用vmalloc和...出现如下错误导致内核崩溃。 问题原因: 在定时器函数中调用vfree,导致内核崩溃。改用kmalloc和kfree,问题解决。 根源: 在内核的中断函数中允许使用vma...
  • # 每次崩溃的报错还不太一样,如下图: ![图片说明](https://img-ask.csdn.net/upload/201709/04/1504505155_161568.png) ![图片说明](https://img-ask.csdn.net/upload/201709/04/1504513763_723517.png) ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 78,093
精华内容 31,237
关键字:

内核崩溃

友情链接: 1_Qlearning20180902.rar