linux查看修改线程默认栈空间大小 ：ulimit -s
1、通过命令 ulimit -s 查看linux的默认栈空间大小，默认情况下 为10240 即10M
2、通过命令 ulimit -s 设置大小值 临时改变栈空间大小：ulimit -s 102400， 即修改为100M
3、可以在/etc/rc.local 内 加入 ulimit -s 102400 则可以开机就设置栈空间大小
4、在/etc/security/limits.conf 中也可以改变栈空间大小：
#<domain><type><item><value>
* soft stack 102400
重新登录，执行ulimit -s 即可看到改为102400 即100M
1. Linux Kernel Panic的产生的原因panic是英文中是惊慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它会尽可能把它此时能获取的全部信息都打印出来。
有两种主要类型kernel panic，后面会对这两类panic做详细说明：
1.hard panic(也就是Aieee信息输出)
2.soft panic (也就是Oops信息输出)
2. 常见Linux Kernel Panic报错内容：
(1) Kernel panic-not syncing fatal exception in interrupt
(2) kernel panic – not syncing: Attempted to kill the idle task!
(3) kernel panic – not syncing: killing interrupt handler!
(4) Kernel Panic – not syncing：Attempted to kill init !
3. 什么会导致Linux Kernel Panic?
只有加载到内核空间的驱动模块才能直接导致kernel panic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。
除此之外，内建在内核里的组件（比如memory map等）也能导致panic。
因为hard panic和soft panic本质上不同，因此我们分别讨论。
4. hard panic
一般出现下面的情况，就认为是发生了kernel panic:
机器彻底被锁定，不能使用
数字键(Num Lock)，大写锁定键(Caps Lock)，滚动锁定键(Scroll Lock)不停闪烁。
如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）
和Windows蓝屏相似
4.1 原因
对于hard panic而言，最大的可能性是驱动模块的中断处理(interrupt handler)导致的，一般是因为驱动模块在中断处理程序中访问一个空指针(null pointre)。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。
本人就曾遇到过这样一个例子：在多核系统中，包括AP应用处理器、mcu微控制器和modem处理器等系统中，mcu控制器用于系统的低功耗控制，mcu微控制器由于某种原因超时向AP应用处理器发送一个超时中断，AP接受中断后调用中断处理函数读取mcu的状态寄存器，发现是mcu的超时中断，就在中断处理程序中主动引用一个空指针，迫使AP处理器打印堆栈信息然后重启linux系统。这就是一个典型的hard panic，这里不对mcu超时原因做深入的分析，只是用来说明hard panic产生的机理。
3.2 信息收集
根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就kernel panic，那就无法只知道能收集到多少有用的信息了。
/var/log/messages: 幸运的时候，整个kernel panic栈跟踪信息都能记录在这里，当然对于嵌入式linux系统，kernel panic的内核打印信息被放到/data/dontpanic目录下，包括两个文件：apanic_console存放的是内核控制台的log，apanic_threads存放的是linux kernel发生panic时的所有内核线程的堆栈信息。
应用程序/库 日志: 可能可以从这些日志信息里能看到发生panic之前发生了什么。
其他发生panic之前的信息，或者知道如何重现panic那一刻的状态
终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。
如果kernel dump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：
如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。
确保屏幕不黑屏，可以使用下面的几个方法：
setterm -blank 0
setterm -powerdown 0
setvesablank off
从终端，拷贝屏幕信息（方法见上）
实际上，当内核发生panic时，linux系统会默认立即重启系统，当然这只是默认情况，除非你修改了产生panic时重启定时时间，这个值默认情况下是0，即立刻重启系统。所以当panic时没有把kernel信息导入文件的话，那么可能你很难再找到panic产生的地方。
3.3 完整栈跟踪信息的排查方法
栈跟踪信息(stack trace)是排查kernel panic最重要的信息，该信息如果在/var/log/messages日志里当然最好，因为可以看到全部的信息，如果仅仅只是在屏幕上，那么最上面的信息可能因为滚屏消失了，只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话，那么就可能根据这些充分的信息来定位panic的根本原因。要确认是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。
使用内核调试工具(kenrel debugger ,aka KDB)
如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kernel debugger(KDB)就需要请出来了。
KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。
使用KDB需要注意，内核必须是基本核心版本，比如是2.4.18，而不是2.4.18-5这样子的，因为KDB仅对基本核心有效。
4. soft panic
4.1 症状：
没有hard panic严重
通常导致段错误(segmentation fault)
可以看到一个oops信息，/var/log/messages里可以搜索到’Oops’
机器稍微还能用（但是收集信息后，应该重启系统）
4.2 原因
凡是非中断处理引发的模块崩溃都将导致soft panic。在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。导致hard panic的原因同样对soft panic也有用（比如在运行时访问一个空指针)
4.3 信息收集
当soft panic发生时，内核将产生一个包含内核符号(kernel symbols)信息的dump数据，这个将记录在/var/log/messages里。为了开始排查故障，可以使用ksymoops工具来把内核符号信息转成有意义的数据。
为了生成ksymoops文件,需要：
从/var/log/messages里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳(timestamp)，否则ksymoops会失败。
运行ksymoops程序（如果没有，请安装）
详细的ksymoops执行用法，可以参考ksymoops(8)手册。
5. Kernel panic实例：
今天就遇到 一个客户机器内核报错：“Kernel panic-not syncing fatal exception”，重启后正常，几个小时后出现同样报错，系统down了，有时重启后可恢复有时重启后仍然报同样的错误。
什么是fatal exception?
“致命异常（fatal exception）表示一种例外情况，这种情况要求导致其发生的程序关闭。通常，异常（exception）可能是任何意想不到的情况（它不仅仅包括程序错误）。致命异常简单地说就是异常不能被妥善处理以至于程序不能继续运行。
软件应用程序通过几个不同的代码层与 *** 作系统及其他应用程序相联系。当异常（exception）在某个代码层发生时，为了查找所有异常处理的代码，各个代码层都会将这个异常发送给下一层，这样就能够处理这种异常。如果在所有层都没有这种异常处理的代码，致命异常（fatal exception）错误信息就会由 *** 作系统显示出来。这个信息可能还包含一些关于该致命异常错误发生位置的秘密信息（比如在程序存储范围中的十六进制的位置）。这些额外的信息对用户而言没有什么价值，但是可以帮助技术支持人员或开发人员调试程序。
当致命异常（fatal exception）发生时， *** 作系统没有其他的求助方式只能关闭应用程序，并且在有些情况下是关闭 *** 作系统本身。当使用一种特殊的应用程序时，如果反复出现致命异常错误的话，应将这个问题报告给软件供应商。 ” 而且此时键盘无任何反应，必然使用reset键硬重启。
panic.c源文件有个方法，当panic挂起后，指定超时时间，可以重新启动机器，这就是前面说的panic超时重启。如果你的机器事先配置好了魔法键的使用，就可以在超时之前通过魔法键使系统在重启前尽可能多的为你多做些事情，当然这些事情不是用来使系统恢复正常，而是尽量避免损失或导出一些有用信息来帮助后面的定位。
方法：
#vi /etc/sysctl.conf 添加
kernel.panic = 20 #panic error中自动重启，等待timeout为20秒
kernel.sysrq=1 #激活Magic SysRq 否则，键盘鼠标没有响应
按住 [ALT]+[SysRq]+[COMMAND], 这里SysRq是Print SCR键，而COMMAND按以下来解释！
b – 立即重启
e – 发送SIGTERM给init之外的系统进程
o – 关机
s – sync同步所有的文件系统
u – 试图重新挂载文件系统
配置一下以防万一。
很多网友安装linux出现“Kernel panic-not syncing fatal exception in interrupt”是由于网卡驱动原因。解决方法：将选项“Onboard Lan”的选项“Disabled”,重启从光驱启动即可。等安装完系统之后，再进入BIOS将“Onboard Lan”的选项给“enable”，下载相应的网卡驱动安装。
如出现以下报错：
init() r8168 …
… …
… ：Kernel panic: Fatal exception
r8168是网卡型号。
在BIOS中禁用网卡，从光驱启动安装系统。再从网上下载网卡驱动安装。
#tar vjxf r8168-8.014.00.tar.bz2
# make clean modules (as root or with sudo)
# make install
# depmod -a
# modprobe r8168
安装好系统后reboot进入BIOS把网卡打开。
另有网友在Kernel panic出错信息中看到“alc880”，这是个声卡类型。尝试着将声卡关闭，重启系统，搞定。
安装linux系统遇到安装完成之后，无法启动系统出现Kernel panic-not syncing fatal exception。很多情况是由于板载声卡、网卡、或是cpu 超线程功能（Hyper-Threading ）引起的。这类问题的解决办法就是先查看错误代码中的信息，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。
另外出现“Kernel Panic — not syncing: attempted to kill init”和“Kernel Panic — not syncing: attempted to kill idle task”有时把内存互相换下位置或重新插拔下可以解决问题。
6. 一个kernel panic的解决之法
相信使用linux kernel开发过驱动的兄弟都知道，kernel panic对系统带来的危害要比应用程序panic大的多，甚至可以用灾难来形容。对于应用程序的panic最多导致linux系统杀掉该用户进程，但对于kernel panic就没办法了，因为kernel是整个系统的管理者，自己出现问题了（当然是不可恢复的异常）就只能等待重启了。
kernel panic的最大问题就是难于定位，对于一个开发者来说，有些kernel panic那简直就像是一场噩梦，上面主要说明了如何抓取kernel panic的方法和一些panic实例，当然，抓取panic的打印信息是解决panic的第一步也是关键一步，下面就根据自己曾碰到过的一个kernel panic做为实例来说明从出现panic到解决panic的一般方法。
6.1 抓取kernel panic信息
没错，正如前面说的，这是第一步也是非常关键的一步，如果要解决一个kernel panic当然必须首先要知道它产生的地方，也就是说产生panic的内核函数调用栈，当前的内核调用栈记录了产生kernel panic时的函数调用关系链，这里我不在贴出相关的打印实例，这样的kernel panic网上也到处都是，而且还有很多的文章来说明如何确定是哪个源文件的哪一行导致的panic，因此感兴趣的同学可以搜索一些这样的文章看看，这里指说明一下解决kernel panic的一般步骤和注意事项。
对于抓取kernel log的方法前面有介绍，这里不赘述，但想强调两点：
（1） 不管是什么样的panic，首先要抓取足够的内核打印信息，当然必要的情况下还需要搜集产生kernel panic时的应用程序的打印信息，对于Android系统来说就是logcat信息，在android嵌入式软件平台上其实有更好更全面的log搜集方法，那就是bugreport，它将产生此刻系统全方位的信息，对，没错，就是全方位的信息，包括内核、应用、内存、进程和处理器等所有相关信息，是一个非常好的调试工具，至于bugreport的工作原理感兴趣的同学自己查找下资料。
注意：bugreport的使用需注意两点：第一，它只能在系统正常运行的情况下使用，第二，正因为第一点，你需要在系统产生kernel panic重启系统后的第一时间使用bugreport导出所有信息，因为这所有信息中包含了上次系统重启的原因的相关log信息。
（2） 既然是抓取panic log信息，必然少不了复现panic这个过程，有的panic的产生时概率性随机的，就是说你不知道什么时候就可能会产生panic，因此请珍惜每一次复现panic的机会，起码要在复现panic之前准备好你要抓取的是那些信息，这些信息能否帮助你进一步定位panic，否则，不要在出现panic时手忙脚乱，不知道自己要什么，最好每次复现panic前计划好这次你要那些信息（可能每次抓取信息的重点不一样）。
注意：在工作中经常碰到这样一个现象：测试部门的同学好不容易发现一个问题，请开发同学定位，开发同学基本上没怎么分析问题就嚷着信息抓的不够没法定位，结果让测试同学半天甚至一天来复现这个问题，等复现了问题开发同学还没搞清楚自己到底要什么信息来定位，有的问题复现时的环境只能保持几分钟甚至几十秒钟，这势必会浪费了测试同学的劳动成果。
6.2 分析kernel panic
搜集了足够的panic信息，下面就是分析panic的时候了，对于一个panic问题，你要知道三点：
（1） 首先要对汇编语言有一定的了解，定位panic产生的C代码位置
其实就是根据当前内核线程的内核调用栈查找产生panic调用链，在panic log的前面几行已经显示了kernel panic的代码位置，但这个位置是相对于产生panic函数的偏移，你并不知道它到底是哪一行，这个时候你需要objdump反汇编器来对那个产生panic的镜像文件反汇编，然后根据panic信息的指示找到对应的汇编代码，对照C代码根据汇编上下文确定C代码行，其实，kernel panic的产生一般都是非法地址的引用，尤其是NULL指针的引用，这也比较容易定位出panic的C代码行。
（2） 分析导致panic的C代码行上下文，确定panic引入点
第一步应该会比较容易找到导致panic 的C代码行，根据产生panic的代码进一步找到panic的引入点，这一步可以搭配printk来定位（如果是大概率panic就更容易定位了），这一步相对第一步花费多一点的时间，如果是应用代码分析到这里已经差不多结束了，确定了panic引入点就可以修改代码进行回归测试了，但对于kernel来说要复杂的多。
正如之前曾碰到的panic，复现虽然不容易但是基本上在固定时间点左右就可以复现，我是用的脚本循环加载卸载wifi模块，每次都是大约500次左右产生panic，要知道必现的panic就容易解决的多了，但当时因为这500次的循环就要花费2个小时左右，而且环境还经常出现问题，导致我花费很长时间才定位出问题所在：每次的加载和卸载wifi模块都导致devices kset节点引用计数多减一，当devices kset的引用计数变为0的时候被系统回收，linux系统随后可能会出现N种panic现象，之后发现是因为wifi模块每次加载下载时对应的设备节点的引用计数增减失衡导致devices kset被多减一，然后发现是linux 内核核心代码的问题。
（3） 最好不要怀疑linux的核心代码，也不要试图去修改
正因为这一点，让我迟迟不敢确定是不是真的核心代码问题，linux的核心代码那可是数以万计的大牛经过千锤百炼的代码，岂容你轻易修改，经过进一步的分析这个panic是因为我们用的wifi卡是非标准媒体卡，走的是非标准流程，在这个流程中对wifi设备初始化时少了一次wifi设备节点的引用，但在卸载模块时同标准卡一样被解引用了。
（4）不要坚定的以为围绕着panic信息就能解决panic问题
还是上面的panic，实际上，上面提到的panic问题其实应该是很多的panic，这也是在后期复现panic时发现的，在加载卸载500次左右时必现panic，但却不是同一个panic，如果按照正常思路：既然是panic，就应该从panic信息下手，顺藤摸瓜一直追下去。如果是这样，这个问题恐怕永远也解决不了，因为你在复现一个panic时总是会有其他的panic出现，这回让你无所适从的。
通过对这些panic的log的分析，发现他们都有一个共性，在产生panic之前都有一段WARNING打印，也正是对这段打印的分析找出了问题的根源，对于这段WARNING的内容和分析过程不在这里说明，只为表达下面的观点：
事实证明，在碰到panic问题定位时，如果想当一段时间内定位不出来，又没有什么更好的思路时，你应该回头看看在panic之前kernel是否产生了哪些不太正常的log，这也许就是导致kernel panic的前兆或推手。
（5） 尽可能多的把握linux kernel的行为，对一些难啃的panic大胆猜测
这里的大胆猜测是建立在想当了解linux kernel行为上的有理性的推理，尽管有些猜测并不是完全正确的，但在你证明它是正确的过程中或许会有意外收获。对于wifi模块加载卸载的panic问题来说，我曾有过两次错误的猜测：
第一次，因为长时间的加载卸载都会出现panic，而且开始发现的panic是在kmem_cache_alloc函数中，因此猜测是内存泄露导致的内存耗尽，因此在后面的复现过程中我写了个脚本循环打印内存的使用情况，发现内存的占用一直稳定在一个正常的范围，证明了我的第一个猜测是错误的。
第二次，在看到devices 的内核对象kobject的名字在panic之前出现乱码的情况下（printk打印了名字），我曾大胆地做过猜测：linux kernel发生了踩内存现象，导致devices kset对象被破坏。随后做了各方面的努力来证明我的想法，结果发现几乎都是在第493次加载wifi模块时出现的panic问题，这让我很迷惑，如果是踩内存怎么可能固定在493次发生，虽然不能完全证明这个猜想是错误的，但这足以说明我的方向有问题。
如此反反复复，花费了我两个星期的时间才搞定这个panic，因此，kernel panic虽然难啃，但只要你愿意去尝试愿意去努力，就算最后拿不下这个panic，你也会学到很多很多的东西，包括linux kernel行为，这些会对你以后的学习产生很大的影响，在碰到这类问题一定是信心满满的。
7. 小结
一直想总结一点kernel panic的解决之法，在网上也搜索了很多资料，基本上都一样，本文前面也引用了这些文章中的一篇，曾经做过的总结过的东西能记录下来给别人看和给以后自己复习都是很有意义的事情，以前kernel panic的问题总让我不敢靠的太近，现在我还是可以比较自信的面对他们，这里也只是给同学们一些解决panic的建议，个人觉得分析一个具体的实例的意义也不是太大，所以也没有对一个具体的实例做详细分析，希望可以找到更多的相关文章来拜读，夜已深沉，还有什么人...
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）