[Debug]Kernel Panic学习(一)

linux内核调试常见方法

1,可能导致kernel panic的原因有:
ARM捕捉到的异常 (KE)
          指令异常:程序跑飞,可能跑到数据区里执行
          访问无效地址:执行存取指令时抛出异常(访问了kernel space没有映射的内存)
代码主动发出的异常 (KE)
          调用BUG()/BUG_ON()函数
软件卡死导致看门狗复位 (无法调度) (HWT)
           代码出现死锁
           中断被关太久(中断频繁)
硬件卡死导致看门狗复位 (HW_REBOOT)
           CPU硬件卡死(bus hang)
           虚焊/断路/短路等PCB问题
           器件不良

2,内核的assert()函数

assert的作用是现计算表达式 expression ,如果其值为假(即为0),那么它先向stderr打印一条出错信息,然后通过调用 abort 来终止程序运行。果assert()返回失败,系统会强制因为assertion failed而panic,并将内存映象存入crash dump文件。

3,Crash工具学习

crash主页
内核部分的KEXEC+KDUMP的配置请参考:http://www.ibm.com/developerworks/cn/linux/l-cn-dumpanalyse/
 # cp /proc/vmcore mydumpfile
 正常linux内核发生异常的时候系统重启,那么重启之后系统内存里的异常信息就全部丢失了,而Crash机制的kdump就是将系统重启之前的内存信息dump出来并存储到相应的文件,这样后面可以通过Crash工具对这个内存进行分析系统异常的原因。比如可以打印backtrace等等。

4,oops机制

linux某个进程发生异常的时候发产生oops,oops 显示发生错误时处理器的状态,包括 CPU 寄存器的内容、页描述符表的位置,以及其一些难理解的信息,较为重要的信息就是指令指针(下一条指令的地址,EIP)由于很难从十六进制数值中看出含义,可使用符号解析工具klogd。klogd 守护进程能在 oops 消息到达记录文件之前对它们解码。通常Oops文本由klogd从内核缓冲区里读取并传给syslogd,由syslogd写到syslog文件中,该文件典型为/var/log/messages(依赖于/etc/syslog.conf)。如果klogd崩溃了,用户可"dmesg > file"从内核缓冲区中读取数据并保存下来。还可用"cat /proc/kmsg > file"读取数据,此时,需要用户中止传输,因为kmsg是一个"永不结束的文件"。

5,从kernel log查看当前发生异常时候pc指针的地址,然后用addr2line工具分析出此错误对应的源码位置

addr2line -e vmlinux 0xco2efe64

或者使用 b $(ADDRESS) in (gdb)分析

6,ram console
ram console
答:是通过ram console,这个是放在internal ram的里,手机重启数据不会丢失,native层通过proc文件系统的
/proc/kmsg来读取重启之前最后的信息。

7,kernel处理kernel panic的流程
当arm发生异常的时候,那么最终会调用到arm_notify_die()函数,最终会调用到arch/arm/kernel/traps.c文件中的die()函数。

时间: 2024-10-14 06:14:29

[Debug]Kernel Panic学习(一)的相关文章

深入 kernel panic 流程【转】

一.前言 我们在项目开发过程中,很多时候会出现由于某种原因经常会导致手机系统死机重启的情况(重启分Android重启跟kernel重启,而我们这里只讨论kernel重启也就是 kernel panic 的情况),死机重启基本算是影响最严重的系统问题了,有稳定复现的,也有概率出现的,解题难度也千差万别,出现问题后,通常我们会拿到类似这样的kernel log信息(下面log仅以调用BUG()为例,其它异常所致的死机log信息会有一些不同之处): [ 2.052157] <2>-(2)[1:swa

Azure上的一个kernel panic测试

今天意外发现,如果在Azure上的Centos 6.8 or 6.9的虚拟机上如果执行了"sudo yum remove -y net-tools"后,再执行重新部署的话,虚拟机就会出现"kernel panic"的报错,导致虚拟机无法正常启动. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++dracut Warning: Boot has

CentOS系统Kernel panic - not syncing: Attempted to kill init

结果启动虚拟机出现如下问题: Kernel panic - not syncing: Attempted to kill init     解决方法: 系统启动的时候,按下'e'键进入grub编辑界面,编辑grub菜单,选择"kernel /vmlinuz-2.6.23.1-42.fc8 ro root=/dev/vogroup00/logvol00 rhgb quiet" 一栏,按'e'键进入编辑,在末尾增加enforcing=0,即: kernel /vmlinuz-2.6.23.

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

移植文件系统时,我们可能会遇到这个问题: VFS: Mounted root (cramfs filesystem) readonly on device 31:3. Freeing unused kernel memory: 176K (c0616000 - c0642000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: sh Not tainted 3.

LFS kernel panic的问题解决之一

/*********************************************************************  * Author  : Samson  * Date    : 04/26/2015  * Test platform:  *              gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2  *              GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu)

linux加载rootfs 根文件系统 kernel panic - not

环境:linux内核加载自己的制作的文件系统. 错误信息有以下几种: 错误信息1: Root-NFS: Server returned error -5 while mounting /mini2440/rootfs VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0) Please append a correct &q

Data Types in the Kernel &lt;LDD3 学习笔记&gt;

Data Types in the Kernel Use of Standard C Types /* * datasize.c -- print the size of common data items * This runs with any Linux kernel (not any Unix, because of <linux/types.h>) * * Copyright (C) 2001 Alessandro Rubini and Jonathan Corbet * Copyr

挂载文件系统出现&quot;kernel panic...&quot; 史上最全解决方案

问:挂载自己制作的文件系统卡在这里: NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Mounted root (cramfs filesystem) readonly. Freeing init memory: 116K Failed to execute /linuxrc. Attempting defaults... Kernel panic - not syncing: No init f

kernel panic

Linux kernel panic是很难定位和排查的重大故障,一旦系统发生了kernel panic,相关的日志信息非常少,而一种常见的排查方法-重现法–又很难实现,因此遇到kernel panic的问题,一般比较头疼.没有一个万能和完美的方法来解决所有的kernel panic问题,这篇文章仅仅只是给出一些思路,一来如何解决kernel panic的问题,二来可以尽可能减少发生kernel panic的机会.什么是kernel panic 就像名字所暗示的那样,它表示Linux kernel