返回列表 发帖

调试kernel panic -not syncing:attempted to kill init!的问题

调试kernel panic -not syncing:attempted to kill init!的问题

最近在帮助三星的人bring up的时候,调试了一个kernel panic -not syncing:attempted to kill init!问题,说起来对于这个问题我做了多年的驱动和内核也碰到过很多次,但是每次调试的方法都是不一样的,但是最终问题归纳起来大同小异了,下面我总结下我的调试经验:

  (1)首先查看linux的rootfs挂载方式,这个阶段挂载非常的简单就是initramfs。
(2)查看命令行参数rdinit=/busybox/rdinit是否传给内核成功,方法如下:

linux有一段代码,就是用来解析rdinit的参数后所做的动作:

  1. static int __init rdinit_setup(char *str)
  2. {
  3.         unsigned int i;

  4.         ramdisk_execute_command = str;
  5.         /* See "auto" comment in init_setup */
  6.         for (i = 1; i < MAX_INIT_ARGS; i++)
  7.                 argv_init = NULL;
  8.         return 1;
  9. }
  10. __setup("rdinit=", rdinit_setup);
复制代码

大家可以看到,最终这个变量:ramdisk_execute_command 就等于/busybox/rdinit
打印这个变量看看是否传成功,当然linux也已经帮你想好啦,已经有这个的判断啦:
  1.         if (!ramdisk_execute_command)
  2.                 ramdisk_execute_command = "/init";

  3.         if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
  4.                 ramdisk_execute_command = NULL;
  5.                 prepare_namespace();
  6.         }
复制代码
如果linux没有报告什么错误的话,那么就表示传进去的参数是对的,而且这个参数的路径中的文件可以访问。这一步是关键啊。

(3)如果第二步正确,那么如果还有kernel panic的问题,就很有可能就是你的root文件目录下载的busybox不好用,或者他本来就不能执行,这个时候你可以找一个你之前用过的,且保证busybox sh执行没有问题的bin文件过来替换现在的,如果发现还有问题,那么终极目标就是查找/busybox/rdinit,99%的可能是这个文件没有执行权限,或者执行过程中发现错误,我们这个问题就是这个rdinit的脚本引起的,我们需要这个脚本里面建立一些文件节点在根目录,但是在根目录里面没有dev目录,但是脚本里面需要进到这个dev下面去建立文件,所以执行就出错,最终出现kernel panic。
(4)还有一篇好的文章,大家可以参考。
http://hi.baidu.com/tony_200812/blog/item/b4f703502b0a6f3743a75b28.html
分享到: QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友

返回列表
网页右侧QQ悬浮滚动在线客服
网页右侧QQ悬浮滚动在线客服