【移动应用开发技术】kernel panic - not syncing fatal exception的问题

【移动应用开发技术】kernelpanic-notsyncingfatalexception的问题

屏幕上显示：

kernelpanic-notsyncing:fatalexception

之后就一直停在那里.大概方法：1、重启下机器，看错误信息还是这些，或者说机器故障还停留在这里，如果出现更多错误信息或者新的错误信息；

2、系统出现此错误，无法启动。很多情况是由于板载声卡、网卡、或是cpu超线程功能（Hyper-Threading(HT)）引起的（BIOS进行关闭），有些关闭USB好了。这类问题在机器重启过程中注意关键错误点，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。

3、注意一下bios中显示的CPU或者内存条的温度。这种情况的表现是系统的极不稳定。或者进入不了系统，syslog停止于kernelpanic；或者重启后可以进入系统，但不久就死机，键盘上的Caps-Lock与Scroll-Lock两个灯在闪。这种情况方法：多半与内存有关，不妨把内存条互换一下位置，也许有效，把内存换了位置，然后开机重启。

4、重启机器的过程中，帮我确认是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。

另外的一些方法：

查了一些网站资料，大部分都是双CPU才发生的，有些是关闭：Hyper-Threading(HT)好了，有些关闭USB好了。

但是我试过了关闭HT，或者关闭USB都无法解决。

还尝试了关闭SELinux的配置，也无法解决。

经过四次重装之后，还是没有解决，在就要放弃之际。突然看到出错信息中有“alc880”的字样，这是个声卡类型。尝试着将声卡关闭，重启系统。OK，搞定。

总结：安装linux系统经常会遇到安装完成之后，无法启动系统。很多情况是由于板载声卡、网卡、或是cpu超线程功能引起的。这类问题的解决办法就是先查看错误代码中的信息，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。

查了一些网站资料，大部分都是双CPU才发生的，有些是关闭：Hyper-Threading(HT)好了，有些关闭USB好了。但是我试过了关闭HT，或者关闭USB都无法解决。

还尝试了关闭SELinux的配置，也无法解决。

经过四次重装之后，还是没有解决，在就要放弃之际。突然看到出错信息中有“alc880”的字样，这是个声卡类型。尝试着将声卡关闭，重启系统。OK，搞定。

总结：安装linux系统经常会遇到安装完成之后，无法启动系统。很多情况是由于板载声卡、网卡、或是cpu超线程功能引起的。这类问题的解决办法就是先查看错误代码中的信息，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。更详细的方法介绍：查了一些网站资料，大部分都是双CPU才发生的，有些是关闭：Hyper-Threading(HT)好了，有些关闭USB好了。

但是我试过了关闭HT，或者关闭USB都无法解决。

还尝试了关闭SELinux的配置，也无法解决。

经过四次重装之后，还是没有解决，在就要放弃之际。突然看到出错信息中有“alc880”的字样，这是个声卡类型。尝试着将声卡关闭，重启系统。OK，搞定。

总结：安装linux系统经常会遇到安装完成之后，无法启动系统。很多情况是由于板载声卡、网卡、或是cpu超线程功能引起的。这类问题的解决办法就是先查看错误代码中的信息，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。

Linuxkernelpanic错误释疑

已有1688次阅读

2010-01-0514:24

标签:

Linux

panic

kernel

释疑

kernelpanic主要有以下几个出错提示：

Kernelpanic-notsyncingfatalexceptionininterrupt

kernelpanic-notsyncing:Attemptedtokilltheidletask!

kernelpanic-notsyncing:killinginterrupthandler!

KernelPanic-notsyncing：

查看了一下linux的源码文件，找到相关位置

kernel/panic.c

NORET_TYPEvoidpanic(constchar*fmt,...)

{

staticcharbuf[1024];

va_listargs;

bust_spinlocks(1);

va_start(args,fmt);

vsnprintf(buf,sizeof(buf),fmt,args);

va_end(args);

printk(KERN_EMERG"Kernelpanic-notsyncing:%s\n",buf);

bust_spinlocks(0);

kernel/exit.c

if(unlikely(in_interrupt()))

panic("Aiee,killinginterrupthandler!");#中断处理

if(unlikely(!tsk->pid))

panic("Attemptedtokilltheidletask!");#空任务

if(unlikely(tsk->pid==1))

panic("Attemptedtokillinit!");#初始化

从其他源文件和相关文档看到应该有几种原因：

1、硬件问题

使用了SCSI-device并且使用了未知命令

#WDIOS_TEMPPANICKernelpanicontemperaturetrip

#

#TheSETOPTIONScallcanbeusedtoenableanddisablethecard

#andtoaskthedrivertocallpanicifthesystemoverheats.

#

#IfoneusesaSCSI-deviceofunsupportedtype/commands,one

#immediatelyrunsintoakernel-paniccausedbyCommandError.Tobetter

#understandwhichSCSI-commandcausedtheproblem,Iextendedthis

#specificpanic-messageslightly.

#

#read/writecausesacommanderrorfrom

#thesubsystemandthiscauseskernel-panic

2、系统过热

如果系统过热会调用panci，系统挂起

#WDIOS_TEMPPANICKernelpanicontemperaturetrip

#

#TheSETOPTIONScallcanbeusedtoenableanddisablethecard

#andtoaskthedrivertocallpanicifthesystemoverheats.

3、文件系统引起

#Avarietyofpanicsandhangswith/tmponareiserfsfilesystem

#Anyotherpanic,hang,orstrangebehavior

#

#Itturnsoutthatthere'salimitofsixenvironmentvariablesonthe

#kernelcommandline.Whenthatlimitisreachedorexceeded,argument

#processingstops,whichmeansthatthe'root='argumentthatUML

#usuallyaddsisnotseen.So,thefilesystemhasnoideawhatthe

#rootdeviceis,soitpanics.

#Thefixistoputlessstuffonthecommandline.Glommingallyour

#setupvariablesintooneisprobablythebestwaytogo.

Linux内核命令行有6个环境变量。如果即将达到或者已经超过了的话root=参数会没有传进去

启动时会引发panics错误。

vigrub.conf

#####################

titleRedHatEnterpriseLinuxAS(2.6.9-67.0.15.ELsmp)

root(hd0,0)

kernel/boot/vmlinuz-2.6.9-67.0.15.ELsmproroot=LABEL=/

initrd/boot/initrd-2.6.9-67.0.15.ELsmp.img

titleRedHatEnterpriseLinuxAS-up(2.6.9-67.EL)

root(hd0,0)

kernel/boot/vmlinuz-2.6.9-67.ELroroot=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)

{

inti;

/*

*Delaytimeoutsecondsbeforerebootingthemachine.

*Wecan'tusethe"normal"timerssincewejustpanicked..

*/

printk(KERN_EMERG"Rebootingin%dseconds..",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#激活MagicSysRq！否则，键盘鼠标没有响应

Linux的稳定性勿容置疑，但是有些时候一些Kernel的致命错误还是会发生（有些时候甚至是因为硬件的原因或驱动故障），KernelPanic会导致系统crash，并且默认的系统会一直hung在那里，直到你去把它重新启动！

不过你可以在/etc/sysctl.conf文件中加入

kernel.panic=20

来告诉系统从Panic错误中自动重启，等待时间为20秒！这个由管理员自己设定！

另外一个讨厌的事情是系统hung住之后，键盘鼠标没有响应，这个可以通过设置MagicSysRq来试着解决，也是在/etc/sysctl.conf中，

kernel.sysrq=1

来激活MagicSysRq！

这样在挂住的时候至少还有一招可以使，

按住[ALT]+[SysRq]+[COMMAND],这里SysRq是PrintSCR键，而COMMAND按以下来解释！b-立即重启

e-发送SIGTERM给init之外的系统进程

o-关机

s-sync同步所有的文件系统

u-试图重新挂载文件系统

当然，谁也不希望经常用到这些招数！:O，有备无患而已

Linuxkernelpanic是很难定位和排查的重大故障,一旦系统发生了kernelpanic，相关的日志信息非常少，而一种常见的排查方法—重现法–又很难实现，因此遇到kernelpanic的问题，一般比较头疼。

没有一个万能和完美的方法来解决所有的kernelpanic问题，这篇文章仅仅只是给出一些思路，一来如何解决kernelpanic的问题，二来可以尽可能减少发生kernelpanic的机会。

什么是kernelpanic

就像名字所暗示的那样，它表示Linuxkernel走到了一个不知道该怎么走下一步的状况，一旦到这个情况，kernel就尽可能把它此时能获取的全部信息都打印出来，至于能打印出多少信息，那就看是那种情况导致它panic了。

1.hardpanic(也就是Aieee信息输出也就是Oops信息输出什么能导致kernelpanic

只有加载到内核空间的驱动模块才能直接导致kernelpanic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。

除此之外，内建在内核里的组件（比如memorymap等）也能导致panic。

因为hardpanic和softpanic本质上不同，因此我们分别讨论。

一般出现下面的情况，就认为是发生了

数字键(NumLock)，大写锁定键(CapsLock)，滚动锁定键(ScrollLock)不停闪烁。如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）

对于hardpanic而言，最大的可能性是驱动模块的中断处理(interrupthandler)导致的，一般是因为驱动模块在中断处理程序中访问一个空指针(nullpointre)。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。

信息收集

根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrelpanic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就kernelpanic，那就无法只知道能收集到多少有用的信息了。

/var/log/messages:幸运的时候，整个kernelpanic栈跟踪信息都能记录在这里。应用程序/库日志:可能可以从这些日志信息里能看到发生panic之前发生了什么。其他发生panic之前的信息，或者知道如何重现panic那一刻的状态终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。

如果kerneldump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：

如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。确保屏幕不黑屏，可以使用下面的几个方法：

栈跟踪信息(stacktrace)是排查kernelpanic最重要的信息，该信息如果在/var/log/messages日志里当然最好，因为可以看到全部的信息，如果仅仅只是在屏幕上，那么最上面的信息可能因为滚屏消失了，只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话，那么就可能根据这些充分的信息来定位panic的根本原因。要确认是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。大概就像下面这个例子一样：

EIPisat_dlgn_setevmask[streams-dlgnDriver]0xe

UnabletohandlekernelNULLpointerdereferenceatvirtualaddress0000000c

EIP:0010:[<f89e568a>]Tainted:PF

EIPisat_dlgn_setevmask[streams-dlgnDriver]0xe

eax:00000000ebx:f65f5410ecx:f5e16710edx:f65f5410

esi:00001ea0edi:f5e23c30ebp:f65f5410esp:f1cf7e78

Processpwcallmgr(pid:10334,stackpage=f1cf7000)

Stack:00000000c01067fa00000086f1cf7ec000001ea0f5e23c30f65f5410f89e53ec

f89fcd60f5e16710f65f5410f65f5410f8a54420f1cf7ec0f8a4d73a0000139e

f5e16710f89fcd6000000086f5e16710f5e16754f65f54100000034af894e648

CallTrace:[setup_sigcontext+218/288]setup_sigcontext[kernel]0xda

CallTrace:[<c01067fa>]setup_sigcontext[kernel]0xda

[<f89e53ec>]dlgnwput[streams-dlgnDriver]0xe8

[<f89fcd60>]Sm_Handle[streams-dlgnDriver]0×1ea0

[<f8a54420>]intdrv_lock[streams-dlgnDriver]0×0

[<f8a4d73a>]Gn_Maxpm[streams-dlgnDriver]0×8ba

[<f89fcd60>]Sm_Handle[streams-dlgnDriver]0×1ea0

[<f894e648>]lis_safe_putnext[streams]0×168

[<f8a7b098>]__insmod_streams-dvbmDriver_S.bss_L117376[streams-dvbmDriver]0xab8

[<f8a78821>]dvbmwput[streams-dvbmDriver]0×6f5

[<f8a79f98>]dvwinit[streams-dvbmDriver]0×2c0

[<f894e648>]lis_safe_putnext[streams]0×168

[<f893e6d8>]lis_strputpmsg[streams]0×54c

[<f895482e>]__insmod_streams_S.rodata_L35552[streams]0×182e

[<f8951227>]sys_putpmsg[streams]0×6f

[system_call+51/56]system_call[kernel]0×33

[<c010719b>]system_call[kernel]0×33

Nov2812:17:58taluskernel:

Nov2812:17:58taluskernel:

Code:8b700c8b0683f8208b5424208b6c2424761c895c

如果只有部分跟踪信息，要快速定位问题的根本原因就变得很难，因为没有明显的信息来告诉我们是哪个模块或者函数的调用导致了内核panic，你可能只能看到kernel最后的一些指令。这种情况下，要尽可能多的收集信息，包括程序日志，库的跟踪信息，故障重现的步骤等。

Hardpanic部分跟踪信息例子（没有EIP信息）：

[<c01e42e7>]ip_rcv[kernel]0×357

[<f8a179d5>]sramintr[streams_dlgnDriver]0×32d

[<f89a3999>]lis_spin_lock_irqsave_fcn[streams]0×7d

[<f8a82fdc>]inthw_lock[streams_dlgnDriver]0×1c

[<f8a7bad8>]pwswtbl[streams_dlgnDriver]0×0

[<f8a15442>]dlgnintr[streams_dlgnDriver]0×4b

[<f8a7c30a>]Gn_Maxpm[streams_dlgnDriver]0×7ae

[<c0123bc1>]__run_timers[kernel]0xd1

[<c0108a6e>]handle_IRQ_event[kernel]0×5e

[<c0108c74>]do_IRQ[kernel]0xa4

[<c0105410>]default_idle[kernel]0×0

[<c0105410>]default_idle[kernel]0×0

[<c022fab0>]call_do_IRQ[kernel]0×5

[<c0105410>]default_idle[kernel]0×0

[<c0105410>]default_idle[kernel]0×0

[<c010543d>]default_idle[kernel]0×2d

[<c01054c2>]cpu_idle[kernel]0×2d

[<c011bb86>]__call_console_drivers[kernel]0×4b

[<c011bcfb>]call_console_drivers[kernel]0xeb

Code:8b500c85d27431f6420a0274048944240831f60f

<0>Kernelpanic:Aiee,killinginterrupthandler!

Ininterrupthandler–notsyncing

使用内核调试工具(kenreldebugger,akaKDB)

如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kerneldebugger(KDB)就需要请出来了。

KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。

使用KDB需要注意，内核必须是基本核心版本，比如是2.4.18，而不是2.4.18-5这样子的，因为KDB仅对基本核心有效。

可以看到一个oops信息，/var/log/messages里可以搜索到

凡是非中断处理引发的模块崩溃都将导致softpanic。在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。导致hardpanic的原因同样对softpanic也有用（比如在运行时访问一个空指针

信息收集：

当softpanic发生时，内核将产生一个包含内核符号(kernelsymbols)信息的dump数据，这个将记录在/var/log/messages里。为了开始排查故障，可以使用ksymoops工具来把内核符号信息转成有意义的数据。

从/var/log/messages里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳(timestamp)，否则ksymoops会失败。详细的ksymoops执行用法，可以参考ksymoops(8)手册。

Code:8b700c50e