当前位置：首页 → 问答吧 → ［已解决］有什么好的办法可以保存 kernel panic 信息？

［已解决］有什么好的办法可以保存 kernel panic 信息？

时间：2010-05-31

来源：互联网

本帖最后由 Godbach 于 2010-06-02 10:46 编辑

往往 kernel panic 后，信息无法记录到 syslog 中，甚至连 keyboard 也无效了
虽然可以通过 netconsole 将数据输出到其他机器上，但毕竟不方便
有什么办法可以将数据保存在硬盘上，哪怕是单独分出一个分区也好？

解决办法：
当系统有问题时，fs 的系统调用是无法正常运行的，因此在 OOPS 代码中嵌入 save to file 代码从逻辑上是讲不通的
用 kexec 去启动一个 capture 内核，导出 /proc/vmcore，利用 crash 根据 vmlinux 去分析 vmcore 是个不错的办法
目前利用此方法已能解决我的问题，谢谢各位

作者: platinum 发布时间: 2010-05-31

白金兄的这种需求是可以实现的。可以考虑往内核插入一个函数，在系统发生Oops的时候，把信息写到文件立面。

作者: Godbach 发布时间: 2010-05-31

QUOTE:

白金兄的这种需求是可以实现的。可以考虑往内核插入一个函数，在系统发生Oops的时候，把信息写到文件立面。
Godbach 发表于 2010-05-31 09:40

哦？Godbach 兄，是不是需要一起用到 “内核写文件” 技术？
找到 OOPS 打印或 netconsole 发送 UDP 数据的前端位置，插入一个自己的 save to file 功能即可？
是否验证过此方法是否可行？

作者: platinum 发布时间: 2010-05-31

QUOTE:

哦？Godbach 兄，是不是需要一起用到 “内核写文件” 技术？

是的。

QUOTE:

找到 OOPS 打印或 netconsole 发送 UDP 数据的前端位置，插入一个自己的 save to file 功能即可？
是否验证过此方法是否可行？

开一个内核线程，来做这个工作应该就成。

作者: Godbach 发布时间: 2010-05-31

为什么要单开一个内核线程完成此事呢？
如果找到了产生 OOPS 信息的位置，直接在他前面加一个 function 实现 save to file 会有什么问题吗？

作者: platinum 发布时间: 2010-05-31

QUOTE:

为什么要单开一个内核线程完成此事呢？
如果找到了产生 OOPS 信息的位置，直接在他前面加一个 function 实 ...
platinum 发表于 2010-05-31 10:11

对，那样也可以。

也可以考虑做成一个内核模块。

作者: Godbach 发布时间: 2010-05-31

QUOTE:

对，那样也可以。

也可以考虑做成一个内核模块。
Godbach 发表于 2010-05-31 10:36

有办法实现在不 recompile 现有内核的情况下通过注册的方法挂载一个内核模块，实现功能嵌入，实现我的需求吗？

作者: platinum 发布时间: 2010-05-31

那就需要明确一下截获OOps信息，需要那修改那些内容。

作者: Godbach 发布时间: 2010-05-31

哦，我不是太明白为什么还要明确截获哪些 OOps 信息，为什么要明确呢？

作者: platinum 发布时间: 2010-05-31

照相机最靠谱,其他的方法都有问题

作者: qtdszws 发布时间: 2010-05-31

QUOTE:

照相机最靠谱,其他的方法都有问题
qtdszws 发表于 2010-05-31 11:34

qtdszws 兄可否多给一些提示，为什么说其他方法都有问题呢？它们可能存在哪些问题？

作者: platinum 发布时间: 2010-05-31

我正好做了个 - 参考内核带的kdump.txt.

结合lcrash工具, 相当完美.

作者: Arthur_ 发布时间: 2010-05-31

回复 Godbach

这样可能导致panic无限循环呵呵

作者: Arthur_ 发布时间: 2010-05-31

QUOTE:

我正好做了个 - 参考内核带的kdump.txt.

结合lcrash工具, 相当完美.
Arthur_ 发表于 2010-05-31 12:17

Arthur_ 兄可否与我们共同分享一下你的成功经验呀！

作者: platinum 发布时间: 2010-05-31

QUOTE:

Arthur_ 兄可否与我们共同分享一下你的成功经验呀！
platinum 发表于 2010-05-31 12:20

我也是照着kdump.txt这个文档一步步做的.

这个方法有个局限性:

1. 官方版本适合x86 ppc64
2. 产生的core很大压缩后40M左右

不知道你能接受不.
PS: arm似乎要打补丁(没用过).

作者: Arthur_ 发布时间: 2010-05-31

QUOTE:

我也是照着kdump.txt这个文档一步步做的.

这个方法有个局限性:

1. 官方版本适合x86 ppc64
2. ...
Arthur_ 发表于 2010-05-31 12:30

我看了一下文档，遇到了几个问题
1、文档中明确说明了要 SMP=N，那么是不是说我的内核在工作时不能跑 SMP 多 CPU 了？
2、文档中指出新编译一个内核，但是不要在 boot loader 中启动他，那么他的工作原理是怎么回事？启动的物理地址又是否必须是 0x100000（16MB）
3、从 LKCD 官方下载的 lkcdutils-6.x 编译无法通过，其中 lr.c 提示与 stdio.h 中的 getline 冲突，难道我还要改代码？

作者: platinum 发布时间: 2010-05-31

QUOTE:

回复 Godbach

这样可能导致panic无限循环呵呵
Arthur_ 发表于 2010-05-31 12:18

截获完之后，直接重启系统，可以解决这个问题么、

作者: Godbach 发布时间: 2010-05-31

我看了一下文档，遇到了几个问题
1、文档中明确说明了要 SMP=N，那么是不是说我的内核在工作时不能跑 SMP 多 CPU 了？
====
做这个东西需要两个内核，一个是你现在使用的内核（工作内核），一个是捕获内核。捕获内核要求CPU=1。

2、文档中指出新编译一个内核，但是不要在 boot loader 中启动他，那么他的工作原理是怎么回事？启动的物理地址又是否必须是 0x100000（16MB）
====
如果捕获内核选择了RELOC 那么地址默认，选择这个有个好处是捕获内核可以是bzimage（压缩的）。
当工作内核挂掉后，系统从这个地址启动捕获内核。（具体咋个加载不是很了解，目前正在研究VM）

3、从 LKCD 官方下载的 lkcdutils-6.x 编译无法通过，其中 lr.c 提示与 stdio.h 中的 getline 冲突，难道我还要改代码？
==
没有遇到这个问题哦，郁闷呵呵。
我记得我安装的是kexec-tools-2.0.0/

作者: Arthur_ 发布时间: 2010-05-31

再次请教 Arthur_ 兄
捕获内核可以与工作内核完全不同吗，比如工作内核是 2.6.31，而捕获内核是标准的 2.6.18？
还是有什么其他限制条件吗？

作者: platinum 发布时间: 2010-05-31

学习学习

作者: missuniverse110 发布时间: 2010-05-31

高亮一把。欢迎大家参与讨论。。。

作者: Godbach 发布时间: 2010-05-31

俺们也遇到这个问题，panic了一下就刷过去，啥都看不到

作者: duanjigang 发布时间: 2010-05-31

可以用notifier chain，register_die_notifier()。

作者: buptldf 发布时间: 2010-05-31

最简单的方法是，用串口连上去，在串口下操作

作者: lmarsin 发布时间: 2010-05-31

QUOTE:

我看了一下文档，遇到了几个问题
1、文档中明确说明了要 SMP=N，那么是不是说我的内核在工作时不能跑 SMP ...
Arthur_ 发表于 2010-05-31 14:01

我现在能通过 kexec 载入 dump-capture 内核，获取到 /proc/vmcore，但是这个怎么用呢？
我只希望能够知道之前 printk 到屏幕的信息即可，通过 netconsole 输出到别的机器上的数据即可，这个怎么实现？

我的想法是参考 netconsole.c 的实现，在 send_udp 之前进行 save buf to file，不知是否可行？

作者: platinum 发布时间: 2010-05-31

QUOTE:

可以用notifier chain，register_die_notifier()。
buptldf 发表于 2010-05-31 17:46

多谢 buptldf 兄指点！
正在参考内核中 register_die_notifier 的例子，看系统是如何捕获信息并 printk 到屏幕上的

作者: platinum 发布时间: 2010-05-31

1. try to use virtual machine
2. try kernel thread as what Godbach says.

作者: dzbjet 发布时间: 2010-05-31

本帖最后由 Arthur_ 于 2010-05-31 19:54 编辑

产生的/proc/vmcore 保存到某个位子 cp /proc/vmcore .
然后用lcrash工具打开 lcrash vmlinux vmcore
lcrash是改装过的gdb, 通过lcrash可以看到系统panic时所有进程的堆栈信息, 任务状态信息.

具体方法google lcrash.(使用方法跟gdb一样 bt呀 where呀)
http://www.ibm.com/developerworks/cn/linux/l-cn-dumpanalyse/

我说点家常, 说错了别怪我哦:

register_die_notifier 这个我用过, 不过失败了. 呵呵, 如果你能成功教教我哦.
当然结合硬件自身特点使用 register_die_notifier也可以做到保存文件机制.

我google好多资料关于如何保存panic成文件, 结果在中国论坛没有几个人问过，问过也不了了之.
但国外很多人问了,而且大部分也都给除了方法, 列出来也有好多. 但这些方式都没有收录内核中, 只有kexec+kdump被接受了. 其它啥也不说了.

啥都不说了.

作者: Arthur_ 发布时间: 2010-05-31

其实实际工作总这个需求还是比较突出的。

作者: Godbach 发布时间: 2010-05-31

高端玩法，只能看看