1. 需要的只是：
2. 在跟踪bug的时候，掌握的信息越多越好。
1. 内核bug多种多样，产生的原因有很多：从错误代码（没有把正确的值存放在恰当的位置）；到同步时发生的错误（共享变量锁定不当）；再到错误的管理硬件（给错误的控制寄存器发送错误的指令）。
2. 从降低所有程序的运行性能到毁坏数据再到使得系统处于死锁状态都可能是bug发作时的症状。
3. 从隐藏在源代码中的错误到展现在目击者面前的bug，往往是经历一系列连锁反应的事件才可能触发的。
printk()是内核提供的格式化打印函数，除了和C库提供的printf()函数功能相同外还有一些自身特殊的功能。
1.健壮性是printk()函数最容易让人们接受的一个特质，在任何时候内核的任何地方都能调用它。
除非在启动过程的初期就要在终端输出，否则可以认为printk()在什么情况下都能工作。
2.printk()函数也会有漏洞，解决办法是提供一个变体函数early _ printk()，但这种办法在某些硬件体系结构上无法实现，缺少可移植性。
1.printk()可以指定一个日志级别，内核根据这个级别来判断是否在终端上打印消息。内核把级别比某个特定值低的所有消息显示在终端上。
2. KERN_ WARNING和KERN_ DEBUG都是简单的宏定义，加进printk()函数要打印的消息的开头。内核用这个指定的记录等级和当前终端的记录等级console_loglevel来决定是不是向终端上打印。
3.如果没有指定一个等级记录，函数会选用默认的DEFAULT _ MESSAGE _ LOGLEVEL，现在的默认等级为KERN _ WARNING。但默认值将来存在变化性，所以还是应该指定一个记录等级。
4.内核将最重要的记录等级KERN _ EMERG定为<0>，无关紧要的记录等级KERN _ DEBUG定为<7>
5.有两种赋予记录等级的方法：
内核消息都被保存在一个环形队列中，该缓冲区的大小可以在编译时通过设置CONFIG _ LOG _ BUF _ SHIFT进行调整，在单处理器的系统上默认值是16kb，也就是说内核在同一时间只能保存16kb的内核消息，再多的话新消息就会覆盖老消息。读写都是按照环形队列方式操作的。
1.在标准的Linux系统上，用户空间的守护进程klogd从记录缓冲区中获取内核消息，再通过syslogd守护进程将他们保存在系统日志文件中。
2.klogd：既可以从/proc/kmsg文件中，也可以通过syslog()系统调用读取获得的内核信息，默认情况下选择读取/proc方式实现。两种情况klogd都会阻塞，直到有新的内核消息可供读出，被唤醒之后，默认处理是将消息传给syslogd。在启动时，可以通过-c标志来改变终端的记录等级。
3.syslogd：把它接收到的所有消息添加到一个文件中，默认是/var/log/messages，也可通过/etc/syslog.conf配置文件重新指定。
1.oops是内核告知用户有不幸发生的最常用的方式。
2.因为内核是整个系统的管理者，不能采取像在用户空间出现运行错误时使用的那些简单手段，因为他很难自我修复，也不能将自己杀死，只能发布oops，过程为：向终端上输出错误消息、输出寄存器中保存的信息、输出可供跟踪的回溯线索。通常发布oops之后，内核会处于一种不稳定状态。
寄存器上下文和回溯线索
回溯线索中的地址需要转化成有意义的符号名称才可以方便使用，需要调用ksymoops命令，还必须提供编译内核时产生的System.map。如果用的是模块，还需要一些模块信息。调用方法：
kysmoop saved_oops.txt现在的版本中不需要使用sysmoops这个工具，因为可能会发生很多问题，新版本中引入了kallsyms疼，可以通过定义CONFIG _ KALLSYMS配置选项启用。
位于内核配置编辑器的内核开发菜单项中，都依赖于CONFIG _ DEBUG _ KERNEL。
一些内调用可以用来方便标记bug，提供断言并输出信息。
BUG()和BUG_ON()
被调用时会引发oops，导致栈的回溯和错误信息的打印。
可以把这些调用当做断言使用，想要断言某种情况不该发生：
if (bad_thing)
BUG();
或更好的形式：
BUG_ON(bad_thing);BUILD _ BUG_ ON()
与BUG_ON()作用相同，仅在编译时调用。
panic()
可以引发更严重的错误，不但会打印错误信息，还会挂起整个系统。
dump_stack()
只在终端上打印寄存器上下文和函数的跟踪线索。
这个功能可以通过定义CONFIG _ MAGIC _ SYSRQ配置选项来启用。SysRq（系统请求）键在大多数键盘上都是标准键。
该功能被启用时，无论内核出于什么状态，都可以通过特殊的组合键和内核进行通信。
除了配置选项以外，还要通过一个sysctl用来标记该特性的开或关，启动命令如下：
echo 1 > /proc/sys/kernel/sysrqSysrq的命令：
可以使用标准的GNU调试器对正在运行的内核进行查看。针对内核启动调试器的方法与针对进程的方法大致相同：
gdb vmlinux /proc/kcore可以使用gdb的所有命令来获取信息。
p global_variable//打印一个变量的值
disassemble function//反汇编一个函数-g参数还可以提供更多的信息。
局限性：
不能单步执行内核代码
是一个补丁 ，可以让我们在远程主机上通过串口利用gdb的所有功能对内核进行调试。
需要两台计算机：仪态运行带有kgdb补丁的内核，第二胎通过串行线使用gdb对第一台进行调试。
通过kgdb，gdb的所有功能都能使用:
一般情况下，加入特性时，只要保留原有的算法而把新算法加入到其他位置上，基本就能保证安全。
可以把用户id（UID）作为选择条件来实现这种功能，通过某种选择条件，安排到底执行哪种算法。
if (current-> uid !=7777) {
/* 老算法…… */
} else {
/* 新算法…… */
}即，除了uid=7777的用户以外，其他所有的用户都是用的老算法，所以这个7777用户可以专门用来测试新算法。
如果代码与进程无关，或者希望有一个针对所有情况都能使用的机制来控制某个特性，可以使用条件变量。
这种方式比使用UID更简单，只需要创建一个全局变量作为一个条件选择开关：
如果该变量为0，就使用某一个分支上的代码；
否则，选择另外一个分支。操控方式：某种接口，或者调试器。
这种方法常用于使用者需要掌握某个特定事件的发生规律的时候。
方法是创建统计量，并提供某种机制访问其统计结果。
定义全局变量
在/proc目录中创建一个文件
or新建一个系统调用
or通过调试器直接访问（最直接）注：不是SMP安全的，更好的方式是用原子操作。
当系统的调试信息过多的时候，有两种方式可以防止这类问题发生：
重复频率限制:
就是限制调试信息，最多几秒打印一次，可以根据自己的需要调节频率。
例如printk()函数的调节频率，可以用printk_ratelimit()函数限制。发生次数限制
这种方法是要调试信息至多输出几次，超过次数限制后就不能再输出。
这种方法可以用来确认在特定情况下某段代码的确被执行了。
注：用到的变量需要是静态的、局部的。不是SMP安全，不是抢占安全，更好的方式是用原子操作。
SMP（Symmetric Multi-Processing），对称多处理结构的简称，是指在一个计算机上汇集了一组处理器(多CPU),各CPU之间共享内存子系统以及总线结构。在这种技术的支持下，一个服务器系统可以同时运行多个处理器，并共享内存和其他的主机资源。
很多时候，内核的更新会带来bug，那么是哪一个内核版本带来的bug？可以使用二分法搜索。
我们可以利用GIT来实现这一步骤。
git bisect start # 告知git要进行二分搜索
git bisect bad <revision> # 已知出现问题的最早内核版本
git bisect bad # 当前版本就是引发bug的最初版本的情况下使用这条命令
git bisect good <revision> # 最新的可正常运行的内核版本这之后，git就会利用二分搜索法在Linux源码树中，自动检测正常的版本内核和有bug的内核版本之间那个版本有隐患，然后再编译、运行以及测试正被检测的版本。
如果这个版本正常：
git bisect good如果这个版本运行有异常：
git bisect bad对于每一个命令，GIT将在吗诶一个版本的基础上反复二分搜索源码树，并且返回所查的下一个内核版本，一直到不能再进行二分搜索位置，最终git会打印出有问题的版本号。
原文：http://www.cnblogs.com/disturbia/p/5332709.html