level 1
level 13
level 7
2017年04月13日 11点04分
5
安装好了以后闪退
2017年04月15日 03点04分
level 7
1 现象
Kernel panic - not syncing: Attempted to kill init!
[<c0069278>] (unwind_backtrace+0x0/0xe4) from [<c0315360>] (panic+0x68/0x190)
[<c0315360>] (panic+0x68/0x190) from [<c0078188>] (do_exit+0xb0/0x724)
[<c0078188>] (do_exit+0xb0/0x724) from [<c00788bc>] (do_group_exit+0xc0/0xf0)
[<c00788bc>] (do_group_exit+0xc0/0xf0) from [<c0084b84>] (get_signal_to_deliver+0x3cc/0x42c)
[<c0084b84>] (get_signal_to_deliver+0x3cc/0x42c) from [<c0066214>] (do_signal+0xa0/0x5c4)
[<c0066214>] (do_signal+0xa0/0x5c4) from [<c0066750>] (do_notify_resume+0x18/0x4c)
[<c0066750>] (do_notify_resume+0x18/0x4c) from [<c0063e54>] (work_pending+0x24/0x28)
2关于“illegal instruction”
illegal instruction，即SIGILL， 是POSIX标准中提供的一类错误。 从名字上看，SIGILL是启动的某个进程中的某一句不能被CPU识别成
正确的
指令。 此类错误是由操作系统发送给进程的，在进程试图执行一些形式错误、未知或者特权指令时操作系统会使用SIGILL信号终止程序。 SIGILL对应的常数是4.
3造成SIGILL的原因
3.1将不正确的数据写入代码段
进程在代码段中的数据是要被作为一个指令执行的。 若不小心覆盖了已有的代码段，可能会得到错误格式的指令。 这种错误尤其在Just-In-Time即时编译器中最可能出现。
同样，如果不小心覆盖了栈上活跃记录中的返回地址，程序就可能根据这个错误地址，执行没有意义的内存中的数据，进而操作。
进一步可以认为，任何导致数据错误的问题都可能带来illegal instruction问题。比如硬盘发生故障。
3.2指令集的演进
比如SIMD指令，自从奔腾4开始有MMX，X86的芯片就开始不停的增加和拓宽SIMD支持，SSE、SSE2、SSE3、SSE42、AVX、AVX2。 默认情况下，很多编译器都在O2或者O3中开了自动向量化，这就导致很多在新体系结构中编译的可执行程序，在老机器上运行时会有illegal instruction问题。
3.3工具链bug
对于普通C语言通过编译器生成的可执行程序。一般都已经通过严格的测试,不会随便发生这种问题。 所以如果你遇到这种错，并且试过了静态链，而且程序中没有嵌入式汇编，基本可以断定是工具链出了问题。 编译器？汇编器或者链接器。
3.4访存对齐或浮点数格式问题
根据Heiher的经验，请注意出现错误的指令可能和访存地址指令有关。 另外，浮点数的格式是否符合IEEE的标准也可能会有影响。
4错误排查指南
程序中有没有特权指令、或者访问特权寄存器有没有将在较新CPU上编译得到的可执行文件拿到老CPU上运行程序中有没有嵌入式汇编，先检查。一般编译器很少会生成有这种问题的代码X86平台上要尤其注意64位汇编指令和32位汇编指令的混用问题程序有在进程代码段空间写数据的机会吗？栈操作够安全吗？注意程序的ABI是否正确尤其是动态链和静态链是否处理的正确，尽量避免动态链的可执行文件调用错误库的问题（ARM的EABI，MIPS的N32/O32/N64都很可能出这种问题）用的工具链靠谱吗？
常见原因:编译器选择不正确, arch 和代码指令集不正确
2017年04月14日 11点04分
9
Kernel panic - not syncing: Attempted to kill init!
[<c0069278>] (unwind_backtrace+0x0/0xe4) from [<c0315360>] (panic+0x68/0x190)
[<c0315360>] (panic+0x68/0x190) from [<c0078188>] (do_exit+0xb0/0x724)
[<c0078188>] (do_exit+0xb0/0x724) from [<c00788bc>] (do_group_exit+0xc0/0xf0)
[<c00788bc>] (do_group_exit+0xc0/0xf0) from [<c0084b84>] (get_signal_to_deliver+0x3cc/0x42c)
[<c0084b84>] (get_signal_to_deliver+0x3cc/0x42c) from [<c0066214>] (do_signal+0xa0/0x5c4)
[<c0066214>] (do_signal+0xa0/0x5c4) from [<c0066750>] (do_notify_resume+0x18/0x4c)
[<c0066750>] (do_notify_resume+0x18/0x4c) from [<c0063e54>] (work_pending+0x24/0x28)
2关于“illegal instruction”
illegal instruction，即SIGILL， 是POSIX标准中提供的一类错误。 从名字上看，SIGILL是启动的某个进程中的某一句不能被CPU识别成
正确的
指令。 此类错误是由操作系统发送给进程的，在进程试图执行一些形式错误、未知或者特权指令时操作系统会使用SIGILL信号终止程序。 SIGILL对应的常数是4.
3造成SIGILL的原因
3.1将不正确的数据写入代码段
进程在代码段中的数据是要被作为一个指令执行的。 若不小心覆盖了已有的代码段，可能会得到错误格式的指令。 这种错误尤其在Just-In-Time即时编译器中最可能出现。
同样，如果不小心覆盖了栈上活跃记录中的返回地址，程序就可能根据这个错误地址，执行没有意义的内存中的数据，进而操作。
进一步可以认为，任何导致数据错误的问题都可能带来illegal instruction问题。比如硬盘发生故障。
3.2指令集的演进
比如SIMD指令，自从奔腾4开始有MMX，X86的芯片就开始不停的增加和拓宽SIMD支持，SSE、SSE2、SSE3、SSE42、AVX、AVX2。 默认情况下，很多编译器都在O2或者O3中开了自动向量化，这就导致很多在新体系结构中编译的可执行程序，在老机器上运行时会有illegal instruction问题。
3.3工具链bug
对于普通C语言通过编译器生成的可执行程序。一般都已经通过严格的测试,不会随便发生这种问题。 所以如果你遇到这种错，并且试过了静态链，而且程序中没有嵌入式汇编，基本可以断定是工具链出了问题。 编译器？汇编器或者链接器。
3.4访存对齐或浮点数格式问题
根据Heiher的经验，请注意出现错误的指令可能和访存地址指令有关。 另外，浮点数的格式是否符合IEEE的标准也可能会有影响。
4错误排查指南
程序中有没有特权指令、或者访问特权寄存器有没有将在较新CPU上编译得到的可执行文件拿到老CPU上运行程序中有没有嵌入式汇编，先检查。一般编译器很少会生成有这种问题的代码X86平台上要尤其注意64位汇编指令和32位汇编指令的混用问题程序有在进程代码段空间写数据的机会吗？栈操作够安全吗？注意程序的ABI是否正确尤其是动态链和静态链是否处理的正确，尽量避免动态链的可执行文件调用错误库的问题（ARM的EABI，MIPS的N32/O32/N64都很可能出这种问题）用的工具链靠谱吗？
常见原因:编译器选择不正确, arch 和代码指令集不正确
