Oops debug小经验
常在河边走哪能不湿脚，写程序没有遇到bug那是不可能的。内核菜鸟写代码，出个kernel oops那更是家常便饭。
从我目前遇到的各种oops来看，debug首先要检验能否稳定重现bug。
若不能稳定重现（触发条件不一，Oops信息不一），那么恭喜了，基本是出现竞态了。这种问题可大可小，当然最后的问题肯定是在自己的代码里面的（前提是其他模块都是稳定的）。这个时候当然是得先把code path都走一遍，检查是不是逻辑有问题；之后就是检查各种锁了。
若能稳定重现，那么相对好办点。慢慢用printk定位到出问题的语句就可以了。objdump反汇编一下，配合oops里面的stack trace信息看看大概是哪个语句出问题了，不过个人觉得帮助不大。更加高级点的工具我基本不会用，囧。
最NB的debug工具还是printk，因为它在任何上下文都是健壮的，这是一个多么伟大的特性啊！（囧）
什么？没有stack trace？你没有开内核的debug功能？当我啥都没说吧。
© 2012, liuw. All rights reserved.