Oops中的error code解释



当内核发生异常(比如非法地址访问)时，产生Oops，常见的打印如下：
...
BUG:unable to handle kernel paging request at f80c6131
*pdpt=0000000000d08001 *pde=00000000372a0067 *pte=0000000000000000
0ops:0010 [#1] SMP
Modules linked in:...
...
其中的0010即为error code，当异常发生时，由硬件压入栈中。可以通过这个看出Oops发生的大致原因。
对于x86架构来说，error code具体定义如下：

/*
 * Page fault error code bits:
 *
 *   bit 0 ==     0: no page found    1: protection fault
 *   bit 1 ==     0: read access        1: write access
 *   bit 2 ==     0: kernel-mode access    1: user-mode access
 *   bit 3 ==                1: use of reserved bit detected
 *   bit 4 ==                1: fault was an instruction fetch
 */
enum x86_pf_error_code {

    PF_PROT        =        1 << 0,
    PF_WRITE    =        1 << 1,
    PF_USER        =        1 << 2,
    PF_RSVD        =        1 << 3,
    PF_INSTR    =        1 << 4,
};

常用低3位，具体含义为：
1、如果第1位被清0，则异常是由一个不存在的页所引起的；否则是由无效的访问权限引起的。
2、如果第1位被清0，则异常由读访问或者执行访问所引起；否则异常由写访问引起。
3、如果第2位被清0，则异常发生在内核态；否则异常发生在用户态。
所以，上述样例中的error code 0010，表示：
1、异常由无效的访问权限引起，也就是说被访问的地址存在对应的物理页，但是没有权限访问。
2、异常由写操作引起
3、异常发生在内核态
总结来说就是该异常由于在内核态对没有写权限的地址进行写操作时产生。

Oops中的 [#1] crash发生次数。
Oops中的 PREEMPT 是指系统支持抢占模式，有时会还会输出SMP(多核) ARM/THUMB(指令集)等信息。

有时候，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自己的驱动，这个信息就没什么意义了。

Linux虽然没有蓝屏现象，不过Kernel报错有时也会让人头疼。有时重启后正常，linux系统运行一段时间后又down了，总不能出现问题就reboot啊。我从网上搜集一下资料，整理了出来，希望大家能在评论与我交流您的看法与经验。

上面两种Oops：第一种是UND_32表示是发生了用户空间，第二种SVC_32表示发生在内核空间。pc表示出问题的地址。

 

几个常识概念：

1.程序计数器PC （R15），可以作为一般的通用寄存器使用，但有一些指令在使用R15时有一些限制。由于ARM采用了流水线处理器机制，当正确读取了PC的值时，该值为当前指令地址值加上8个字节。也就是说，对于ARM指令集来说，PC指向当前指令的下两条指令的地址。由于ARM指令是字对齐的，PC值的第0位和第一位总为 0。

2.寄存器R13(SP)，通常用作堆栈指针，每一种模式都有自己的物理R13，程序初始化R13。当进入该模式

时，可以将要使用的寄存器保存在R13所指的栈中，当退出时，将弹出，从而实现了现场保护。

3.寄存器R14被称为链接寄存器(LR)，当中存放每种模式下，当前子程序的返回地址或者

发生异常中断的时候，将R14设置成异常模式将要返回的地址。

4.寄存器R12

 

在给linux内核添加netfilter和iptables配置后，生成内核。下载到开发板的后启动插入网线出现错误提示：

eth1: link up, 100Mbps, full-duplex, lpa 0xCDE1        //插入网线后提示

------------------首先这些打印是kernel的panic函数列出的，具体意义可以直接找到kernel代码去看，很有帮助。
Unable to handle kernel paging request at virtual address 06400040

-----------------------空指针错误，这个一般就是非法地址访问，至于为什么导致非法，请关注PC周围的代码逻辑。有必要的话就printk出来。

pgd = c0004000
[06400040] *pgd=00000000
Internal error: Oops: 5 [#1]  //错误提示 ------5代表什么？要在你的手册或kernel代码中查，null pointer？？

Modules linked in: zd1211rw rt73usb rt2x00usb rt2x00lib asix usbnet mac80211 inp
ut_polldev
CPU: 0    Not tainted  (2.6.30.4-LanxumDomas #19)

PC is at skb_release_data+0x74/0xc4

--------当前pc指针，这个十分有用！可以将kernel反汇编，然后找dequeue_task的相对位置0xc处

LR is at __kfree_skb+0x1c/0xd0

-----------------以下为当前寄存器值，也有帮助
pc : [<c0282b68>]    lr : [<c028266c>]    psr: 20000013
sp : c040dd90  ip : c040dda8  fp : c040dda4
r10: 00000001  r9 : c0465fc8  r8 : c3a22000
r7 : c3b54300  r6 : c3b50004  r5 : c3ae1600  r4 : c3ae1600
r3 : 00000000  r2 : c3b50822  r1 : 00000000  r0 : 06400040
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 33af0000  DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc040c268)
Stack: (0xc040dd90 to 0xc040e000)
dd80:                                     c3ae1600 c3ae1600 c040ddbc c040dda8
dda0: c028266c c0282b04 c3ae19c0 c3ae1600 c040ddcc c040ddc0 c0282794 c0282660 

-----------------以下是调用堆栈，可以看到程序的流程，便于跟踪。

出现以上错误后，可以根据错误的提示oops；以下介绍根据错误提示进行错误定位。

1.首先在编译生成内核的时候同时生成了一个vmlinux，使用gdb。

   在内核配置时，make menuconfig 要打开complie with debug info选项。

   注意这行： PC is at skb_release_data+0x74/0xc4

   这告诉我们，skb_release_data函数有0xc4这么大，而Oops发生在0x74处。 那么我们先看一下skb_release_data从哪里开始：

      # grep skb_release_data ./System.map

         c0282af4 t skb_release_data

     于是我们知道在系统出现错误时程序指针在 c0282af4+0x74=c0282b68

  2.然后用gdb查看，gdb ./vmlinux (在linux目录下执行)，进入调试模式。

                                (gdb) b *0xc0282b68

  Breakpoint 1 at 0xc0282b68: file net/core/skbuff.c ,line312

  这就是告诉我们在哪个文件，在哪一行。如此知道了错误的位置，具体的原因带解决。

3，反汇编

                (gdb) disassemble 0xc0282b68

panic是英文中是惊慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它会尽可能把它此时能获取的全部信息都打印出来。

有两种主要类型kernel panic：

1.hard panic(也就是Aieee信息输出)
2.soft panic (也就是Oops信息输出)

常见Linux Kernel Panic报错内容：

Kernel panic-not syncing fatal exception in interrupt
kernel panic – not syncing: Attempted to kill the idle task!
kernel panic – not syncing: killing interrupt handler!
Kernel Panic – not syncing：Attempted to kill init !

什么会导致Linux Kernel Panic?

只有加载到内核空间的驱动模块才能直接导致kernel panic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。
除此之外，内建在内核里的组件（比如memory map等）也能导致panic。

因为hard panic和soft panic本质上不同，因此我们分别讨论。

hard panic

一般出现下面的情况，就认为是发生了kernel panic:

1. 机器彻底被锁定，不能使用
2. 数字键(Num Lock)，大写锁定键(Caps Lock)，滚动锁定键(Scroll Lock)不停闪烁。
3. 如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）
4. 和Windows蓝屏相似

原因：

对于hard panic而言，最大的可能性是驱动模块的中断处理(interrupt handler)导致的，一般是因为驱动模块在中断处理程序中访问一个空指针(null pointre)。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。

信息收集
根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就kernel panic，那就无法只知道能收集到多少有用的信息了。

1. /var/log/messages: 幸运的时候，整个kernel panic栈跟踪信息都能记录在这里。
2. 应用程序/库 日志: 可能可以从这些日志信息里能看到发生panic之前发生了什么。
3. 其他发生panic之前的信息，或者知道如何重现panic那一刻的状态
4. 终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。

如果kernel dump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：

1. 如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。
2. 确保屏幕不黑屏，可以使用下面的几个方法：
   • setterm -blank 0
   • setterm -powerdown 0
   • setvesablank off
3. 从终端，拷贝屏幕信息（方法见上）

完整栈跟踪信息的排查方法

栈跟踪信息(stack trace)是排查kernel panic最重要的信息，该信息如果在/var/log/messages日志里当然最好，因为可以看到全部的信息，如果仅仅只是在屏幕上，那么最上面的信息可能因为滚屏消失了，只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话，那么就可能根据这些充分的信息来定位panic的根本原因。要确认是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。

使用内核调试工具(kenrel debugger ,aka KDB)

如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kernel debugger(KDB)就需要请出来了。
KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。

使用KDB需要注意，内核必须是基本核心版本，比如是2.4.18，而不是2.4.18-5这样子的，因为KDB仅对基本核心有效。

soft panic

症状：

1. 没有hard panic严重
2. 通常导致段错误(segmentation fault)
3. 可以看到一个oops信息，/var/log/messages里可以搜索到’Oops’
4. 机器稍微还能用（但是收集信息后，应该重启系统）

原因：

凡是非中断处理引发的模块崩溃都将导致soft panic。在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。导致hard panic的原因同样对soft panic也有用（比如在运行时访问一个空指针)

信息收集：
当soft panic发生时，内核将产生一个包含内核符号(kernel symbols)信息的dump数据，这个将记录在/var/log/messages里。为了开始排查故障，可以使用ksymoops工具来把内核符号信息转成有意义的数据。

为了生成ksymoops文件,需要：

• 从/var/log/messages里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳(timestamp)，否则ksymoops会失败。
• 运行ksymoops程序（如果没有，请安装）
• 详细的ksymoops执行用法，可以参考ksymoops(8)手册。

Oops 信息包含以下几部分内容。
1 一段文本描述信息。
比如类似“Unable to handle kernel NULL pointer dereference at virtual address 00000000”
的信息,它说明了发生的是哪类错误。
2 Oops 信息的序号。
比如是第 1 次、第 2 次等。这些信息与下面类似,中括号内的数据表示序号。
Internal error: Oops: 805 [#1]
3 内核中加载的模块名称,也可能没有,以下面字样开头。
Modules linked in:
4 发生错误的 CPU 的序号,对于单处理器的系统,序号为 0,比如:
CPU: 0
Not tainted (2.6.22.6 #36)
5 发生错误时 CPU 的各个寄存器值。
6 当前进程的名字及进程 ID,比如:
Process swapper (pid: 1, stack limit = 0xc0480258)
这并不是说发生错误的是这个进程,而是表示发生错误时,当前进程是它。错误可能发
生在内核代码、驱动程序,也可能就是这个进程的错误。
7 栈信息。
8 栈回溯信息,可以从中看出函数调用关系,形式如下:
Backtrace:
[<c001a6f4>] (s3c2410fb_probe+0x0/0x560) from [<c01bf4e8>] (platform_drv_
probe+0x20/0x24)
...
9 出错指令附近的指令的机器码,比如(出错指令在小括号里)
:
Code: e24cb004 e24dd010 e59f34e0 e3a07000 (e5873000)