linux内核的oops

什么是Oops？从语言学的角度说，Oops应该是一个拟声词。当出了点小事故，或者做了比较尴尬的事之后，你可以说"Oops"，翻译成中国话就叫做“哎呦”。“哎呦，对不起，对不起，我真不是故意打碎您的杯子的”。看，Oops就是这个意思。

在Linux内核开发中的Oops是什么呢？其实，它和上面的解释也没什么本质的差别，只不过说话的主角变成了Linux。当某些比较致命的问题出现时，我们的Linux内核也会抱歉的对我们说：“哎呦（Oops），对不起，我把事情搞砸了”。Linux内核在发生kernel panic时会打印出Oops信息，把目前的寄存器状态、堆栈内容、以及完整的Call trace都show给我们看，这样就可以帮助我们定位错误。

下面，我们来看一个实例。为了突出本文的主角--Oops，这个例子唯一的作用就是造一个空指针引用错误。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

#include <linux/kernel.h>

#include <linux/module.h>

static int __init hello_init(void)

{

    int *p = 0;

    

    *p = 1;

    return 0;

}

static void __exit hello_exit(void)

{

    return;

}

module_init(hello_init);

module_exit(hello_exit);

MODULE_LICENSE("GPL");

很明显，错误的地方就是第8行。

接下来，我们把这个模块编译出来，再用insmod来插入到内核空间，正如我们预期的那样，Oops出现了。

[  100.243737] BUG: unable to handle kernel NULL pointer dereference at (null)

[  100.244985] IP: [<f82d2005>] hello_init+0x5/0x11 [hello]

[  100.262266] *pde = 00000000

[  100.288395] Oops: 0002 [#1] SMP

[  100.305468] last sysfs file: /sys/devices/virtual/sound/timer/uevent

[  100.325955] Modules linked in: hello(+) vmblock vsock vmmemctl vmhgfs acpiphp snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ppdev psmouse serio_raw fbcon tileblit font bitblit softcursor snd parport_pc soundcore snd_page_alloc vmci i2c_piix4 vga16fb vgastate intel_agp agpgart shpchp lp parport floppy pcnet32 mii mptspi mptscsih mptbase scsi_transport_spi vmxnet

[  100.472178] [  100.494931] Pid: 1586, comm: insmod Not tainted (2.6.32-21-generic #32-Ubuntu) VMware Virtual Platform

[  100.540018] EIP: 0060:[<f82d2005>] EFLAGS: 00010246 CPU: 0

[  100.562844] EIP is at hello_init+0x5/0x11 [hello]

[  100.584351] EAX: 00000000 EBX: fffffffc ECX: f82cf040 EDX: 00000001

[  100.609358] ESI: f82cf040 EDI: 00000000 EBP: f1b9ff5c ESP: f1b9ff5c

[  100.631467]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068

[  100.657664] Process insmod (pid: 1586, ti=f1b9e000 task=f137b340 task.ti=f1b9e000)

[  100.706083] Stack:

[  100.731783]  f1b9ff88 c0101131 f82cf040 c076d240 fffffffc f82cf040 0072cff4 f82d2000

[  100.759324] <0> fffffffc f82cf040 0072cff4 f1b9ffac c0182340 f19638f8 f137b340 f19638c0

[  100.811396] <0> 00000004 09cc9018 09cc9018 00020000 f1b9e000 c01033ec 09cc9018 00015324

[  100.891922] Call Trace:

[  100.916257]  [<c0101131>] ? do_one_initcall+0x31/0x190

[  100.943670]  [<f82d2000>] ? hello_init+0x0/0x11 [hello]

[  100.970905]  [<c0182340>] ? sys_init_module+0xb0/0x210

[  100.995542]  [<c01033ec>] ? syscall_call+0x7/0xb

[  101.024087] Code: <c7> 05 00 00 00 00 01 00 00 00 5d c3 00 00 00 00 00 00 00 00 00 00

[  101.079592] EIP: [<f82d2005>] hello_init+0x5/0x11 [hello] SS:ESP 0068:f1b9ff5c

[  101.134682] CR2: 0000000000000000

[  101.158929] ---[ end trace e294b69a66d752cb ]---

Oops首先描述了这是一个什么样的bug，然后指出了发生bug的位置，即“IP: [<f82d2005>] hello_init+0x5/0x11 [hello]”。

在这里，我们需要用到一个辅助工具objdump来帮助分析问题。objdump可以用来反汇编，命令格式如下：

objdump -S  hello.o

下面是hello.o反汇编的结果，而且是和C代码混排的，非常的直观。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

hello.o:     file format elf32-i386

Disassembly of section .init.text:

00000000 <init_module>:

#include <linux/kernel.h>

#include <linux/module.h>

static int __init hello_init(void)

{

   0:   55                      push   %ebp

    int *p = 0;

    

    *p = 1;

    

    return 0;

}

   1:   31 c0                   xor    %eax,%eax

#include <linux/kernel.h>

#include <linux/module.h>

static int __init hello_init(void)

{

   3:   89 e5                   mov    %esp,%ebp

    int *p = 0;

    

    *p = 1;

   5:   c7 05 00 00 00 00 01    movl   $0x1,0x0

   c:   00 00 00

    

    return 0;

}

   f:   5d                      pop    %ebp

  10:   c3                      ret   

Disassembly of section .exit.text:

00000000 <cleanup_module>:

static void __exit hello_exit(void)

{

   0:   55                      push   %ebp

   1:   89 e5                   mov    %esp,%ebp

   3:   e8 fc ff ff ff          call   4 <cleanup_module+0x4>

    return;

}

   8:   5d                      pop    %ebp

   9:   c3                      ret   

对照Oops的提示，我们可以很清楚的看到，出错的位置hello_init+0x5的汇编代码是：


1

5:c7 05 00 00 00 00 01 movl   $0x1,0x0

这句代码的作用是把数值1存入0这个地址，这个操作当然是非法的。

我们还能看到它对应的c代码是：


1

*p = 1;

Bingo！在Oops的帮助下我们很快就解决了问题。

我们再回过头来检查一下上面的Oops，看看Linux内核还有没有给我们留下其他的有用信息。

Oops: 0002 [#1]

这里面，0002表示Oops的错误代码（写错误，发生在内核空间），#1表示这个错误发生一次。

Oops的错误代码根据错误的原因会有不同的定义，本文中的例子可以参考下面的定义（如果发现自己遇到的Oops和下面无法对应的话，最好去内核代码里查找）：

* error_code:
 *      bit 0 == 0 means no page found, 1 means protection fault
 *      bit 1 == 0 means read, 1 means write
 *      bit 2 == 0 means kernel, 1 means user-mode
 *      bit 3 == 0 means data, 1 means instruction

有时候，Oops还会打印出Tainted信息。这个信息用来指出内核是因何种原因被tainted（直译为“玷污”）。具体的定义如下：

1: ‘G‘ if all modules loaded have a GPL or compatible license, ‘P‘ if any proprietary module has been loaded.  Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary.
  2: ‘F‘ if any module was force loaded by "insmod -f", ‘ ‘ if all modules were loaded normally.
  3: ‘S‘ if the oops occurred on an SMP kernel running on hardware that hasn‘t been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable.
  4: ‘R‘ if a module was force unloaded by "rmmod -f", ‘ ‘ if all modules were unloaded normally.
  5: ‘M‘ if any processor has reported a Machine Check Exception, ‘ ‘ if no Machine Check Exceptions have occurred.
  6: ‘B‘ if a page-release function has found a bad page reference or some unexpected page flags.
  7: ‘U‘ if a user or user application specifically requested that the Tainted flag be set, ‘ ‘ otherwise.
  8: ‘D‘ if the kernel has died recently, i.e. there was an OOPS or BUG.
  9: ‘A‘ if the ACPI table has been overridden.
 10: ‘W‘ if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.)
 11: ‘C‘ if a staging driver has been loaded.
 12: ‘I‘ if the kernel is working around a severe bug in the platform firmware (BIOS or similar).

基本上，这个Tainted信息是留给内核开发者看的。用户在使用Linux的过程中如果遇到Oops，可以把Oops的内容发送给内核开发者去debug，内核开发者根据这个Tainted信息大概可以判断出kernel panic时内核运行的环境。如果我们只是debug自己的驱动，这个信息就没什么意义了。

本文的这个例子非常简单，Oops发生以后没有造成宕机，这样我们就可以从dmesg中查看到完整的信息。但更多的情况是Oops发生的同时系统也会宕机，此时这些出错信息是来不及存入文件中的，关掉电源后就无法再看到了。我们只能通过其他的方式来记录：手抄或者拍照。

还有更坏的情况，如果Oops信息过多的话，一页屏幕显示不全，我们怎么来查看完整的内容呢？第一种方法，在grub里用vga参数指定更高的分辨率以使屏幕可以显示更多的内容。很明显，这个方法其实解决不了太多的问题；第二种方法，使用两台机器，把调试机的Oops信息通过串口打印到宿主机的屏幕上。但现在大部分的笔记本电脑是没有串口的，这个解决方法也有很大的局限性；第三种方法，使用内核转储工具kdump把发生Oops时的内存和CPU寄存器的内容dump到一个文件里，之后我们再用gdb来分析问题。

开发内核驱动的过程中可能遇到的问题是千奇百怪的，调试的方法也是多种多样，Oops是Linux内核给我们的提示，我们要用好它。

#################################

修订：

2010-11-19: Oops的error code

转自：http://www.cnblogs.com/wwang/archive/2010/11/14/1876735.html

时间： 2024-08-04 16:58:55

linux内核的oops的相关文章

（转）Linux内核的Oops

原文:http://www.cnblogs.com/wwang/archive/2010/11/14/1876735.html 什么是Oops?从语言学的角度说,Oops应该是一个拟声词.当出了点小事故,或者做了比较尴尬的事之后,你可以说"Oops",翻译成中国话就叫做“哎呦”.“哎呦,对不起,对不起,我真不是故意打碎您的杯子的”.看,Oops就是这个意思. 在Linux内核开发中的Oops是什么呢?其实,它和上面的解释也没什么本质的差别,只不过说话的主角变成了Linux.当某些比较致

Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)（Linux-3.0 ARMv7）【转】

原文地址:Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)(Linux-3.0 ARMv7) 作者:tekkamanninja 转自:http://blog.chinaunix.net/uid-25909619-id-4938395.html 前面粗略分析start_kernel函数,此函数中基本上是对内存管理和各子系统的数据结构初始化.在内核初始化函数start_kernel执行到最后,就是调用rest_init函数,这个函数的主要使命就是创建并启动内核线

Linux Kernel - Debug Guide (Linux内核调试指南 )

http://blog.csdn.net/blizmax6/article/details/6747601 linux内核调试指南 一些前言 作者前言 知识从哪里来 为什么撰写本文档 为什么需要汇编级调试 ***第一部分:基础知识*** 总纲:内核世界的陷阱 源码阅读的陷阱 代码调试的陷阱 原理理解的陷阱 建立调试环境 发行版的选择和安装 安装交叉编译工具 bin工具集的使用 qemu的使用 initrd.img的原理与制作 x86虚拟调试环境的建立 arm虚拟调试环境的建立 arm开发板调试环

Linux内核设计与实现读书笔记——第十八章

第18章 调试 调试工作艰难是内核级开发区别于用户级开发的一个显著特点,相比于用户级开发,内核调试的难度确实要艰苦得多.更可怕的是,它带来的风险比用户级别更高,内核的一个错误往往立刻就能让系统崩溃. 18.1 准备开始 一个bug.听起来很可笑,但确实需要一个确定的bug.如果错误总是能够重现的话,那对我们会有很大的帮助(有一部分错误确实如此).然而不幸的是,大部分bug通常都不是行为可靠而且定义明确的. 一个藏匿bug的内核版本.如果你知道这个bug最早出现在哪个内核版本中那就再理想不过了.

Linux 内核的同步机制，第 1 部分 + 第二部分（转）

http://blog.csdn.net/jk198310/article/details/9264721  原文地址: Linux 内核的同步机制,第 1 部分 一. 引言 在现代操作系统里,同一时间可能有多个内核执行流在执行,因此内核其实象多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问.尤其是在多处理器系统上,更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问.在主流的Linux内核中包含了几乎所有现代的操作系统具有的同步机制,这些同步机制包括:原子操作

ARMv8 Linux内核异常处理过程分析

NOTE:为了方便大家阅读,制作了PDF版文档.下载请猛戳这里 老样子,为了赚点积分下载其它人的文件,下载以上资料须要资源分2分. 假设没有积分请留言全部文档,留下邮箱就可以. 看了Linaro提供的开源ARMv8 Linux内核源代码,发现ARMv8异常处理与ARMv7及之前的架构有所不同,简单分析. LinaroARMv8工程:http://www.linaro.org/engineering/engineering-projects/armv8 1.1 Linux内核异常处理相关文件 Li

《linux内核设计与实现》读书笔记第十八章

第18章 调试 18.1 准备开始 准备工作需要的是: 一个bug 一个藏匿bug的内核版本 相关内核代码的知识和运气 18.2 内核中的bug 内核中bug的产生原因 从明白无误的错误代码——没有把正确的值存放在恰当的位置 同步时发生的错误——共享变量锁定不当 错误地管理硬件——错误的控制寄存器发送错误的指令 危害: 从降低所有程序的运行性能到毁坏数据 使得系统处于死锁状态 18.3 通过打印来调试 prink()是内核的格式化打印程序. 18.3.1 健壮性 prink()函数健壮性——任何

《Linux内核设计与实现》第十八章读书笔记

1.内核中的bug 内核中的bug表现得不像用户级程序中那么清晰——因为内核.用户以及硬件之间的交互会很微妙: 从隐藏在源代码中的错误到展现在目击者面前的bug,往往是经历一系列连锁反应的事件才可能触发的. 内核调试的难点 重现bug困难 调试风险比较大 定位bug的初始版本困难 2. 内核调试的工具和方法 2.1 输出 LOG 输出LOG不光是内核调试, 即使是在用户态程序的调试中, 也是经常使用的一个调试手段. 通过在可疑的代码周围加上一些LOG输出, 可以准确的了解bug发生前后的一些重要

Linux内核分析之跟踪分析Linux内核的启动过程

一.实验过程 使用实验楼虚拟机打开shell cd LinuxKernel/ qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img 内核启动进入 menu 程序.下面是用 gbd 来跟踪内核的启动过程: gdb (gdb)file linux-3.18.6/vmlinux # 在gdb界面中targe remote之前加载符号表 (gdb)target remote:1234 # 建立gdb和gdbserver之间的