原文:http://artistehsu.pixnet.net/blog/post/276425695-%E4%BD%BF%E7%94%A8-ramoops-%E9%99%A4%E9%8C%AF
这个目前只在x86机器上测试过的,这个需要BIOS提供支持的,国产BIOS不一定支持
内核配置
1.Kernel configure:
CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_FTRACE=y
CONFIG_PSTORE_RAM=y
2.kernel args:
ramoops.mem_size=
ramoops.mem_address=
3.crash and reboot,you can see this:
cat /sys/fs/pstore/console-ramoops
example
可以抓到crash的dmesg,然后根据RIP看到最后执行的指令:
打开CONFIG_DEBUG_INFO
,利用addr2line -e vmlinux address
来看到最后的代码行,然后基本上就可以
看出来哪里错误,可以分析接下来的事情.
如果oops的地址发生在动态加载的module里面,就不能直接使用addr2line工具来直接得到对应的源码行了,
此时应该使用objdump -dS \*.ko
来得到所有的反汇编,然后根据oops中的相对偏移地址来对应源码行了.
其他
还有一些看起来比较low的方法:
切换到文本控制台,然后打开控制台显式dmesg -E
,调整printk级别sysctl -w kernel.printk="7 4 1 7"
,调整panic参数sysctl -w kernel.panic=50
,崩溃时可以在控制台上看到一部分信息。
这种方法可能信息获取不全,但是简便实用,对大部分机器都是有效的。
嵌入式上例如高通等,他们基本上都是有自己定制的dump工具,可以抓全部内存的,但是通常是购买他们的服务才会提供工具和技术支持,所以这点限制比较大。另外他们可能也实现了pstore功能,上面的ramoops就是pstore的一种,对于嵌入上还有一种mtdoops可以实用,具体参考[这里]
抓取崩溃信息工作的困难之处在于内核崩溃时它不知道哪一部分是可信的,有可能IO栈已经被破坏了,你还要继续使用它来保存dump,很可能造成进一步数据破坏。所以保存崩溃信息的实现方式尽量不要和内核系统纠缠太多,耦合尽量少。
来源:CSDN
作者:wjx5210
链接:https://blog.csdn.net/faxiang1230/article/details/103778193