Kernel panic常见原因.docx

kernel panic错误表现kernel panic主要有以下几个出错提示：Kernel panic-not syncing fatal exception in interruptkernel panic - not syncing: Attempted to kill the idle task!kernel panic - not syncing: killing interrupt handler!Kernel Panic - not syncing：Attempted to kill init !kernel错误分析查看了一下linux的源码文件，找到相关位置kernel/panic.cNORET_TYPE void panic(const char * fmt, .)static char buf1024;va_list args;bust_spinlocks(1);va_start(args, fmt);vsnprintf(buf, sizeof(buf), fmt, args);va_end(args);printk(KERN_EMERG Kernel panic - not syncing: %s/n,buf);bust_spinlocks(0);kernel/exit.cif (unlikely(in_interrupt()panic(Aiee, killing interrupt handler!); #中断处理if (unlikely(!tsk-pid)panic(Attempted to kill the idle task!); #空任务if (unlikely(tsk-pid = 1)panic(Attempted to kill init!); #初始化从其他源文件和相关文档看到应该有几种原因：1、硬件问题使用了SCSI-device并且使用了未知命令#WDIOS_TEMPPANIC Kernel panic on temperature trip# The SETOPTIONS call can be used to enable and disable the card# and to ask the driver to call panic if the system overheats.# If one uses a SCSI-device of unsupported type/commands, one# immediately runs into a kernel-panic caused by Command Error. To better# understand which SCSI-command caused the problem, I extended this# specific panic-message slightly.#read/write causes a command error from# the subsystem and this causes kernel-panic2、系统过热如果系统过热会调用panci，系统挂起#WDIOS_TEMPPANIC Kernel panic on temperature trip# The SETOPTIONS call can be used to enable and disable the card# and to ask the driver to call panic if the system overheats.3、文件系统引起#A variety of panics and hangs with /tmp on a reiserfs filesystem#Any other panic, hang, or strange behavior# It turns out that theres a limit of six environment variables on the# kernel command line. When that limit is reached or exceeded, argument# processing stops, which means that the root= argument that UML# usually adds is not seen. So, the filesystem has no idea what the# root device is, so it panics.# The fix is to put less stuff on the command line. Glomming all your# setup variables into one is probably the best way to go.Linux内核命令行有6个环境变量。如果即将达到或者已经超过了的话root=参数会没有传进去启动时会引发panics错误。vi grub.conf#title Red Hat Enterprise Linux AS (2.6.9-67.0.15.ELsmp)root (hd0,0)kernel /boot/vmlinuz-2.6.9-67.0.15.ELsmp ro root=LABEL=/initrd /boot/initrd-2.6.9-67.0.15.ELsmp.imgtitle Red Hat Enterprise Linux AS-up (2.6.9-67.EL)root (hd0,0)kernel /boot/vmlinuz-2.6.9-67.EL ro root=LABEL=/initrd /boot/initrd-2.6.9-67.EL.img应该是其中的root=LABEL=/没有起作用。4、内核更新网上相关文档多半是因为升级内核引起的，建议使用官方标准版、稳定版另外还有使用磁盘的lvm逻辑卷，添加CPU和内存。可在BIOS中禁掉声卡驱动等不必要的设备。也有报是ext3文件系统的问题。解决：手工编译内核，把ext3相关的模块都编译进去，5、处理panic后的系统自动重启panic.c源文件有个方法，当panic挂起后，指定超时时间，可以重新启动机器if (panic_timeout 0)int i;/* Delay timeout seconds before rebooting the machine.* We cant use the normal timers since we just panicked.*/printk(KERN_EMERG Rebooting in %d seconds.,panic_timeout);for (i = 0; i panic_timeout; i+) touch_nmi_watchdog();mdelay(1000);修改方法：/etc/sysctl.conf文件中加入kernel.panic = 30 #panic错误中自动重启，等待时间为30秒kernel.sysrq=1 #激活Magic SysRq！否则，键盘鼠标没有响应Linux Kernel Panic之后的招数Linux的稳定性勿容置疑，但是有些时候一些Kernel的致命错误还是会发生（有些时候甚至是因为硬件的原因或驱动故障），Kernel Panic会导致系统crash，并且默认的系统会一直hung在那里，直到你去把它重新启动！不过你可以在/etc/sysctl.conf文件中加入kernel.panic = 20来告诉系统从Panic错误中自动重启，等待时间为20秒！这个由管理员自己设定！另外一个讨厌的事情是系统hung住之后，键盘鼠标没有响应，这个可以通过设置Magic SysRq来试着解决，也是在/etc/sysctl.conf中，kernel.sysrq=1来激活Magic SysRq！这样在挂住的时候至少还有一招可以使，按住ALT+SysRq+COMMAND,这里SysRq是Print SCR键，而COMMAND按以下来解释！b -立即重启e -发送SIGTERM给init之外的系统进程o -关机s - sync同步所有的文件系统u -试图重新挂载文件系统当然，谁也不希望经常用到这些招数！:O，有备无患而已Kernelpanic问题如何调试Linux kernel panic是很难定位和排查的重大故障,一旦系统发生了kernel panic，相关的日志信息非常少，而一种常见的排查方法重现法又很难实现，因此遇到kernel panic的问题，一般比较头疼。没有一个万能和完美的方法来解决所有的kernel panic问题，这篇文章仅仅只是给出一些思路，一来如何解决kernel panic的问题，二来可以尽可能减少发生kernel panic的机会。什么是kernel panic就像名字所暗示的那样，它表示Linux kernel走到了一个不知道该怎么走下一步的状况，一旦到这个情况，kernel就尽可能把它此时能获取的全部信息都打印出来，至于能打印出多少信息，那就看是那种情况导致它panic了。有两种主要类型kernel panic：1.hard panic(也就是Aieee信息输出)2.soft panic (也就是Oops信息输出)什么能导致kernel panic只有加载到内核空间的驱动模块才能直接导致kernel panic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。除此之外，内建在内核里的组件（比如memory map等）也能导致panic。因为hard panic和soft panic本质上不同，因此我们分别讨论。如何排查hard panic一般出现下面的情况，就认为是发生了kernel panic:1. 机器彻底被锁定，不能使用2. 数字键(Num Lock)，大写锁定键(Caps Lock)，滚动锁定键(Scroll Lock)不停闪烁。3. 如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）4. 和Windows蓝屏相似原因：对于hard panic而言，最大的可能性是驱动模块的中断处理(interrupt handler)导致的，一般是因为驱动模块在中断处理程序中访问一个空指针(null pointre)。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。信息收集根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就kernel panic，那就无法只知道能收集到多少有用的信息了。1. /var/log/messages:幸运的时候，整个kernel panic栈跟踪信息都能记录在这里。2. 应用程序/库日志:可能可以从这些日志信息里能看到发生panic之前发生了什么。3. 其他发生panic之前的信息，或者知道如何重现panic那一刻的状态4. 终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。如果kernel dump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：1. 如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。2. 确保屏幕不黑屏，可以使用下面的几个方法：o setterm -blank 0o setterm -powerdown 0o setvesablank off3. 从终端，拷贝屏幕信息（方法见上）完整栈跟踪信息的排查方法栈跟踪信息(stack trace)是排查kernel panic最重要的信息，该信息如果在/var/log/messages日志里当然最好，因为可以看到全部的信息，如果仅仅只是在屏幕上，那么最上面的信息可能因为滚屏消失了，只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话，那么就可能根据这些充分的信息来定位panic的根本原因。要确认是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。大概就像下面这个例子一样：EIP is at _dlgn_setevmask streams-dlgnDriver 0xehard panic的一个完整跟踪信息例子：Unable to handle kernel NULL pointer dereference at virtual address 0000000cprinting eip:f89e568a*pde = 32859001*pte = 00000000Oops: 0000Kernel 2.4.9-31enterpriseCPU: 1EIP: 0010: Tainted: PFEFLAGS: 00010096EIP is at _dlgn_setevmask streams-dlgnDriver 0xeeax: 00000000 ebx: f65f5410 ecx: f5e16710 edx: f65f5410esi: 00001ea0 edi: f5e23c30 ebp: f65f5410 esp: f1cf7e78ds: 0018 es: 0018 ss: 0018Process pwcallmgr (pid: 10334, stackpage=f1cf7000)Stack: 00000000 c01067fa 00000086 f1cf7ec0 00001ea0 f5e23c30 f65f5410 f89e53ecf89fcd60 f5e16710 f65f5410 f65f5410 f8a54420 f1cf7ec0 f8a4d73a 0000139ef5e16710 f89fcd60 00000086 f5e16710 f5e16754 f65f5410 0000034a f894e648Call Trace: setup_sigcontext+218/288 setup_sigcontext kernel 0xdaCall Trace: setup_sigcontext kernel 0xda dlgnwput streams-dlgnDriver 0xe8 Sm_Handle streams-dlgnDriver 01ea0 intdrv_lock streams-dlgnDriver 00 Gn_Maxpm streams-dlgnDriver 08ba Sm_Handle streams-dlgnDriver 01ea0 lis_safe_putnext streams 0168 _insmod_streams-dvbmDriver_S.bss_L117376 streams-dvbmDriver 0xab8 dvbmwput streams-dvbmDriver 06f5 dvwinit streams-dvbmDriver 02c0 lis_safe_putnext streams 0168 lis_strputpmsg streams 054c _insmod_streams_S.rodata_L35552 streams 0182e sys_putpmsg streams 06fsystem_call+51/56 system_call kernel 033 system_call kernel 033Nov 28 12:17:58 talus kernel:Nov 28 12:17:58 talus kernel:Code: 8b 70 0c 8b 06 83 f8 20 8b 54 24 20 8b 6c 24 24 76 1c 89 5c完整栈信息无效的排查方法如果只有部分跟踪信息，要快速定位问题的根本原因就变得很难，因为没有明显的信息来告诉我们是哪个模块或者函数的调用导致了内核panic，你可能只能看到kernel最后的一些指令。这种情况下，要尽可能多的收集信息，包括程序日志，库的跟踪信息，故障重现的步骤等。Hard panic部分跟踪信息例子（没有EIP信息）： ip_rcv kernel 0357 sramintr streams_dlgnDriver 032d lis_spin_lock_irqsave_fcn streams 07d inthw_lock streams_dlgnDriver 01c pwswtbl streams_dlgnDriver 00 dlgnintr streams_dlgnDriver 04b Gn_Maxpm streams_dlgnDriver 07ae _run_timers kernel 0xd1 handle_IRQ_event kernel 05e do_IRQ kernel 0xa4 default_idle kernel 00 default_idle kernel 00 call_do_IRQ kernel 05 default_idle kernel 00 default_idle kernel 00 default_idle kernel 02d cpu_idle kernel 02d _call_console_drivers kernel 04b call_console_drivers kernel 0xebCode: 8b 50 0c 85 d2 74 31 f6 42 0a 02 74 04 89 44 24 08 31 f6 0f Kernel panic: Aiee, killing interrupt handler!In interrupt handler not syncing使用内核调试工具(kenrel debugger ,aka KDB)如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kernel debugger(KDB)就需要请出来了。KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。使用KDB需要注意，内核必须是基本核心版本，比如是2.4.18，而不是2.4.18-5这样子的，因为KDB仅对基本核心有效。如何排查soft panic症状：1. 没有hard panic严重2. 通常导致段错误(segmentation fault)3. 可以看到一个oops信息，/var/log/messages里可以搜索到Oops4. 机器稍微还能用（但是收集信息后，应该重启系统）原因：凡是非中断处理引发的模块崩溃都将导致soft panic。在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。导致hard panic的原因同样对soft panic也有用（比如在运行时访问一个空指针)信息收集：当soft panic发生时，内核将产生一个包含内核符号(kernel symbols)信息的dump数据，这个将记录在/var/log/messages里。为了开始排查故障，可以使用ksymoops工具来把内核符号信息转成有意义的数据。为了生成ksymoops文件,需要： 从/var/log/messages里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳(timestamp)，否则ksymoops会失败。 运行ksymoops程序（如果没有，请安装） 详细的ksymoops执行用法，可以参考ksymoops(8)手册。下面是一个soft panic的oopsg跟踪例子：Code: 8b 70 0c 50 e8 69 f9 f8 ff 83 c4 10 83 f8 08 74 35 66 c7 47EIP; f89ba71e Trace; f8951bd6 Trace; f8a2705c Trace; f8a27040 Trace; f89b9198 案例分析Kernel Panic - not syncing: attempted to kill idle task出现这种错误是进入不了操作系统的，kernel panic的成因有多种多样，但这种情况是比较奇特的一种，因为它很可能不是软件的问题，而是硬件的问题。几年前我用带奔三的旧主板时遇到过，当时不知道如何解决，只知道它偶尔出现，放一放也会自行消失，所以当初没有重视。现在，当我重新用上旧主板，这种情况又出现了，而且这一次比较顽固，无论怎样重启，总是这条错误，不但硬盘上现有的两个操作系统都进不去，而且连光驱里的LiveCD也进不去了，这显然不是硬盘的问题，也不是内核的问题。以前我就明白应该是主板的问题，可能是主板太旧，电路信号不太通畅的原因，但不知道怎么办，害得我一天一宿没上网。今天早上去网吧，查了点资料，大体上有几种说法：一种是在grub作内核引导时添加idle参数，这一种是国内网常见的一种说法；第二个方法是注意一下bios中显示的CPU或者内存条的温度；第三种是重新作initrd，即mkinitrd；第四种是在grub中启动memtest86来测试内存，这几个是外国人的论坛上说的。我回到家以后，先试了第一种，加了idle的各种参数后，毫无效果，关于第二种方法，我在bios中看到似乎硬件的温度不是可以调节的，但我从这个思路出发，考虑到，如果与内存有关，不妨把三个内存条互换一下位置，也许有效，于是，我把我的三个SD内存换了位置，然后开机，一切正常了。Kernel Panic - not syncing: attempted to kill init这一种情况的表现是系统的极不稳定。或者进入不了系统，syslog停止于kernel panic；或者重启后可以进入系统，但不久就死机，键盘上的Caps-Lock与Scroll-Lock两个灯在闪。这种错误与上面那个有相同的成因，解决方法也相同。+Linux虽然没有蓝屏现象，不过Kernel报错有时也会让人头疼。有时重启后正常，linux系统运行一段时间后又down了，总不能出现问题就reboot啊。我从网上搜集一下资料，整理了出来，希望大家能在评论与我交流您的看法与经验。什么是Kernel Panic?wiki:Akernel panicis an action taken by anoperating systemupon detecting an internalfatal errorfrom which it cannot safely recover. The term is largely specific toUnixandUnix-likesystems; forMicrosoft Windowsoperating systems the equivalent term is “Bug check” (or,colloquially, “Blue Screen of Death“).Thekernelroutines that handle panics (inAT&T-derived andBSDUnix source code, a routine known aspanic() are generally designed to output anerror messageto theconsole, dump an image of kernel memory to disk for post-mortemdebuggingand then either wait for the system to be manually rebooted, or initiate an automaticreboot. The information provided is of highly technical nature and aims to assist asystem administratororsoftware developerin diagnosing the problem.Attempts by the operating system to read an invalid or non-permittedmemory addressare a common source of kernel panics. A panic may also occur as a result of a hardware failure or a bug in the operating system. In many cases, the operating system could continue operation after memory violations have occurred. However, the system is in an unstable state and rather than risking security breaches and data corruption, the operating system stops to prevent further damage and facilitate diagnosis of the error.The kernel panic was introduced in an early version ofUnixand demonstrated a major difference between the design philosophies of Unix and its predecessorMultics. Multics developerTom van Vleckrecalls a discussion of this change with Unix developerDennis Ritchie:I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, “We left all that stuff out. If theres an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, Hey, reboot it.”1The originalpanic()function was essentially unchanged from Fifth Edition UNIX to theVAX-based UNIX 32V and output only an error message with no other information, then dropped the system into an endless idle loop. As the Unixcodebasewas enhanced, thepanic()function was also enhanced to dump various forms of debugging information to the console.panic是英文中是惊慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它会尽可能把它此时能获取的全部信息都打印出来。有两种主要类型kernel panic：1.hard panic(也就是Aieee信息输出)2.soft panic (也就是Oops信息输出)常见Linux Kernel Panic报错内容：Kernel panic-not syncing fatal exception in interruptkernel panic not syncing: Attempted to kill the idle task!kernel panic not syncing: killing interrupt handler!Kernel Panic not syncing：Attempted to kill init !什么会导致Linux Kernel Panic?只有加载到内核空间的驱动模块才能直接导致kernel panic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。除此之外，内建在内核里的组件（比如memory map等）也能导致panic。因为hard panic和soft panic本质上不同，因此我们分别讨论。hard panic一般出现下面的情况，就认为是发生了kernel panic:1. 机器彻底被锁定，不能使用2. 数字键(Num Lock)，大写锁定键(Caps Lock)，滚动锁定键(Scroll Lock)不停闪烁。3. 如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）4. 和Windows蓝屏相似原因：对于hard panic而言，最大的可能性是驱动模块的中断处理(interrupt handler)导致的，一般是因为驱动模块在中断处理程序中访问一个空指针(null pointre)。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。信息收集根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就kernel panic，那就无法只知道能收集到多少有用的信息了。1. /var/log/messages: 幸运的时候，整个kernel panic栈跟踪信息都能记录在这里。2. 应用程序/库 日志: 可能可以从这些日志信息里能看到发生panic之前发生了什么。3. 其他发生panic之前的信息，或者知道如何重现panic那一刻的状态4. 终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。如果kernel dump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：1. 如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。2. 确保屏幕不黑屏，可以使用下面的几个方法：o setterm -blank 0o setterm -powerdown 0o setvesablank off3. 从终端，拷贝屏幕信息（方法见上）完整栈跟踪信息的排查方法栈跟踪信息(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仅对基本核心有效。soft panic症状：1. 没有hard panic严重2. 通常导致段错误(segmentation fault)3. 可以看到一个oops信息，/var/log/messages里可以搜索到Oops4. 机器稍微还能用（但是收集信息后，应该重启系统）原因：凡是非中断处理引发的模块崩溃都将导致soft panic。在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。导致hard panic的原因同样对soft panic也有用（比如在运行时访问一个空指针)信息收集：当soft panic发生时，内核将产生一个包含内核符号(kernel symbols)信息的dump数据，这个将记录在/var/log/messages里。为了开始排查故障，可以使用ksymoops工具来把内核符号信息转成有意义的数据。为了生成ksymoops文件,需要： 从/var/log/messages里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳(timestamp)，否则ksymoops会失败。 运行ksymoops程序（如果没有，请安装） 详细的ksymoops执行用法，可以参考ksymoops(8)手册。Kernel panic实例：今天就遇到 一个客户机器内核报错：“Kernel panic-not syncing fatal exception”重启后正常，几个小时后出现同样报错，系统down了，有时重启后可恢复有时重启后仍然报同样的错误。我先来解释一下什么是fatal except