Kernel panic-not syncing fatal exception in interrupt問題解決

問題描述

在vmware8中安裝kali2020在進(jìn)入圖形化界面安裝之后不久就顯示出錯(cuò)界面。

解決方法

升級(jí)更新VMware workstation到最新版本成功解決。

實(shí)踐親測(cè)有效故記錄一下，如果還是無(wú)法解決參見↓↓↓↓↓↓↓↓

Linux Kernel Panic報(bào)錯(cuò)解決思路

Linux雖然沒有藍(lán)屏現(xiàn)象，不過Kernel報(bào)錯(cuò)有時(shí)也會(huì)讓人頭疼。有時(shí)重啟后正常，linux系統(tǒng)運(yùn)行一段時(shí)間后又down了，總不能出現(xiàn)問題就reboot啊。

我從網(wǎng)上搜集一下資料，整理了出來(lái)，希望大家能在評(píng)論與我交流您的看法與經(jīng)驗(yàn)。

什么是Kernel Panic?

wiki:

A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover. The term is largely specific to Unix and Unix-like systems; for Microsoft Windowsoperating systems the equivalent term is “Bug check” (or, colloquially, “Blue Screen of Death“).

The kernel routines that handle panics (in AT&T-derived and BSD Unix source code, a routine known as panic()) are generally designed to output an error message to the console, dump an image of kernel memory to disk for post-mortemdebugging and then either wait for the system to be manually rebooted, or initiate an automatic reboot. The information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.

Attempts by the operating system to read an invalid or non-permitted memory address are 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 of Unix and demonstrated a major difference between the design philosophies of Unix and its predecessor Multics. Multics developer Tom van Vleck recalls a discussion of this change with Unix developer Dennis 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 there’s 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.’”[1]

The original panic() function was essentially unchanged from Fifth Edition UNIX to the VAX-based UNIX 32V and output only an error message with no other information, then dropped the system into an endless idle loop. As the Unixcodebase was enhanced, the panic() function was also enhanced to dump various forms of debugging information to the console.

panic是英文中是驚慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它會(huì)盡可能把它此時(shí)能獲取的全部信息都打印出來(lái)。

有兩種主要類型kernel panic：

• 1.hard panic(也就是Aieee信息輸出)
• 2.soft panic (也就是Oops信息輸出)

常見Linux Kernel Panic報(bào)錯(cuò)內(nèi)容

Kernel panic-not syncing fatal exception in interrupt
kernel panic – not syncing: Attempted to kill the idle task!
kernel panic – not syncing: killing interrupt handler!
Kernel Panic – not syncing：Attempted to kill init !

什么會(huì)導(dǎo)致Linux Kernel Panic?

只有加載到內(nèi)核空間的驅(qū)動(dòng)模塊才能直接導(dǎo)致kernel panic，你可以在系統(tǒng)正常的情況下，使用lsmod查看當(dāng)前系統(tǒng)加載了哪些模塊。

除此之外，內(nèi)建在內(nèi)核里的組件（比如memory map等）也能導(dǎo)致panic。

因?yàn)閔ard panic和soft panic本質(zhì)上不同，因此我們分別討論。

hard panic

一般出現(xiàn)下面的情況，就認(rèn)為是發(fā)生了kernel panic:

• 機(jī)器徹底被鎖定，不能使用
• 數(shù)字鍵(Num Lock)，大寫鎖定鍵(Caps Lock)，滾動(dòng)鎖定鍵(Scroll Lock)不停閃爍。
• 如果在終端下，應(yīng)該可以看到內(nèi)核dump出來(lái)的信息（包括一段”Aieee”信息或者”Oops”信息）
• 和Windows藍(lán)屏相似

原因：

對(duì)于hard panic而言，最大的可能性是驅(qū)動(dòng)模塊的中斷處理(interrupt handler)導(dǎo)致的，一般是因?yàn)轵?qū)動(dòng)模塊在中斷處理程序中訪問一個(gè)空指針(null pointre)。一旦發(fā)生這種情況，驅(qū)動(dòng)模塊就無(wú)法處理新的中斷請(qǐng)求，最終導(dǎo)致系統(tǒng)崩潰。

信息收集

根據(jù)panic的狀態(tài)不同，內(nèi)核將記錄所有在系統(tǒng)鎖定之前的信息。因?yàn)閗enrel panic是一種很嚴(yán)重的錯(cuò)誤，不能確定系統(tǒng)能記錄多少信息，下面是一些需要收集的關(guān)鍵信息，他們非常重要，因此盡可能收集全，當(dāng)然如果系統(tǒng)啟動(dòng)的時(shí)候就kernel panic，那就無(wú)法只知道能收集到多少有用的信息了。

• /var/log/messages: 幸運(yùn)的時(shí)候，整個(gè)kernel panic棧跟蹤信息都能記錄在這里。
• 應(yīng)用程序/庫(kù) 日志: 可能可以從這些日志信息里能看到發(fā)生panic之前發(fā)生了什么。
• 其他發(fā)生panic之前的信息，或者知道如何重現(xiàn)panic那一刻的狀態(tài)
• 終端屏幕dump信息，一般OS被鎖定后，復(fù)制，粘貼肯定是沒戲了，因此這類信息，你可以需要借助數(shù)碼相機(jī)或者原始的紙筆工具了。

如果kernel dump信息既沒有在/var/log/message里，也沒有在屏幕上，那么嘗試下面的方法來(lái)獲?。ó?dāng)然是在還沒有死機(jī)的情況下）：

如果在圖形界面，切換到終端界面，dump信息是不會(huì)出現(xiàn)在圖形界面的，甚至都不會(huì)在圖形模式下的虛擬終端里。

確保屏幕不黑屏，可以使用下面的幾個(gè)方法：

• setterm -blank 0
• setterm -powerdown 0
• setvesablank off

從終端，拷貝屏幕信息（方法見上）

完整棧跟蹤信息的排查方法

棧跟蹤信息(stack trace)是排查kernel panic最重要的信息，該信息如果在/var/log/messages日志里當(dāng)然最好，因?yàn)榭梢钥吹饺康男畔?，如果僅僅只是在屏幕上，那么最上面的信息可能因?yàn)闈L屏消失了，只剩下棧跟蹤信息的一部分。如果你有一個(gè)完整棧跟蹤信息的話，那么就可能根據(jù)這些充分的信息來(lái)定位panic的根本原因。要確認(rèn)是否有一個(gè)足夠的棧跟蹤信息，你只要查找包含”EIP”的一行，它顯示了是什么函數(shù)和模塊調(diào)用時(shí)導(dǎo)致panic。

使用內(nèi)核調(diào)試工具(kenrel debugger ,aka KDB)

如果跟蹤信息只有一部分且不足以用來(lái)定位問題的根本原因時(shí)，kernel debugger(KDB)就需要請(qǐng)出來(lái)了。

KDB編譯到內(nèi)核里，panic發(fā)生時(shí)，他將內(nèi)核引導(dǎo)到一個(gè)shell環(huán)境而不是鎖定。這樣，我們就可以收集一些與panic相關(guān)的信息了，這對(duì)我們定位問題的根本原因有很大的幫助。

使用KDB需要注意，內(nèi)核必須是基本核心版本，比如是2.4.18，而不是2.4.18-5這樣子的，因?yàn)镵DB僅對(duì)基本核心有效。

soft panic

癥狀：

• 沒有hard panic嚴(yán)重
• 通常導(dǎo)致段錯(cuò)誤(segmentation fault)
• 可以看到一個(gè)oops信息，/var/log/messages里可以搜索到’Oops’
• 機(jī)器稍微還能用（但是收集信息后，應(yīng)該重啟系統(tǒng)）

原因：

凡是非中斷處理引發(fā)的模塊崩潰都將導(dǎo)致soft panic。在這種情況下，驅(qū)動(dòng)本身會(huì)崩潰，但是還不至于讓系統(tǒng)出現(xiàn)致命性失敗，因?yàn)樗鼪]有鎖定中斷處理例程。導(dǎo)致hard panic的原因同樣對(duì)soft panic也有用（比如在運(yùn)行時(shí)訪問一個(gè)空指針)

信息收集：

當(dāng)soft panic發(fā)生時(shí)，內(nèi)核將產(chǎn)生一個(gè)包含內(nèi)核符號(hào)(kernel symbols)信息的dump數(shù)據(jù)，這個(gè)將記錄在/var/log/messages里。為了開始排查故障，可以使用ksymoops工具來(lái)把內(nèi)核符號(hào)信息轉(zhuǎn)成有意義的數(shù)據(jù)。

為了生成ksymoops文件,需要：

• 從/var/log/messages里找到的堆棧跟蹤文本信息保存為一個(gè)新文件。確保刪除了時(shí)間戳(timestamp)，否則ksymoops會(huì)失敗。
• 運(yùn)行ksymoops程序（如果沒有，請(qǐng)安裝）
• 詳細(xì)的ksymoops執(zhí)行用法，可以參考ksymoops(8)手冊(cè)。

Kernel panic實(shí)例

今天就遇到 一個(gè)客戶機(jī)器內(nèi)核報(bào)錯(cuò)：“Kernel panic-not syncing fatal exception”

重啟后正常，幾個(gè)小時(shí)后出現(xiàn)同樣報(bào)錯(cuò)，系統(tǒng)down了，有時(shí)重啟后可恢復(fù)有時(shí)重啟后仍然報(bào)同樣的錯(cuò)誤。

我先來(lái)解釋一下什么是fatal exception?

“致命異常（fatal exception）表示一種例外情況，這種情況要求導(dǎo)致其發(fā)生的程序關(guān)閉。通常，異常（exception）可能是任何意想不到的情況（它不僅僅包括程序錯(cuò)誤）。致命異常簡(jiǎn)單地說就是異常不能被妥善處理以至于程序不能繼續(xù)運(yùn)行。

軟件應(yīng)用程序通過幾個(gè)不同的代碼層與操作系統(tǒng)及其他應(yīng)用程序相聯(lián)系。當(dāng)異常（exception）在某個(gè)代碼層發(fā)生時(shí)，為了查找所有異常處理的代碼，各個(gè)代碼層都會(huì)將這個(gè)異常發(fā)送給下一層，這樣就能夠處理這種異常。如果在所有層都沒有這種異常處理的代碼，致命異常（fatal exception）錯(cuò)誤信息就會(huì)由操作系統(tǒng)顯示出來(lái)。這個(gè)信息可能還包含一些關(guān)于該致命異常錯(cuò)誤發(fā)生位置的秘密信息（比如在程序存儲(chǔ)范圍中的十六進(jìn)制的位置）。這些額外的信息對(duì)用戶而言沒有什么價(jià)值，但是可以幫助技術(shù)支持人員或開發(fā)人員調(diào)試程序。

當(dāng)致命異常（fatal exception）發(fā)生時(shí)，操作系統(tǒng)沒有其他的求助方式只能關(guān)閉應(yīng)用程序，并且在有些情況下是關(guān)閉操作系統(tǒng)本身。當(dāng)使用一種特殊的應(yīng)用程序時(shí)，如果反復(fù)出現(xiàn)致命異常錯(cuò)誤的話，應(yīng)將這個(gè)問題報(bào)告給軟件供應(yīng)商。 ”

而且此時(shí)鍵盤無(wú)任何反應(yīng)，必然使用reset鍵硬重啟。

panic.c源文件有個(gè)方法，當(dāng)panic掛起后，指定超時(shí)時(shí)間，可以重新啟動(dòng)機(jī)器

方法：

#vi /etc/sysctl.conf  添加

kernel.panic = 20 #panic error中自動(dòng)重啟，等待timeout為20秒
kernel.sysrq=1 #激活Magic SysRq  否則，鍵盤鼠標(biāo)沒有響應(yīng)

按住 [ALT]+[SysRq]+[COMMAND], 這里SysRq是Print SCR鍵，而COMMAND按以下來(lái)解釋！

• b – 立即重啟
• e – 發(fā)送SIGTERM給init之外的系統(tǒng)進(jìn)程
• o – 關(guān)機(jī)
• s – sync同步所有的文件系統(tǒng)
• u – 試圖重新掛載文件系統(tǒng)

配置一下以防萬(wàn)一。

很多網(wǎng)友安裝linux出現(xiàn)“Kernel panic-not syncing fatal exception in interrupt”是由于網(wǎng)卡驅(qū)動(dòng)原因。

解決方法：將選項(xiàng)“Onboard Lan”的選項(xiàng)“Disabled”,重啟從光驅(qū)啟動(dòng)即可。

等安裝完系統(tǒng)之后，再進(jìn)入BIOS將“Onboard Lan”的選項(xiàng)給“enable”，下載相應(yīng)的網(wǎng)卡驅(qū)動(dòng)安裝。

如出現(xiàn)以下報(bào)錯(cuò)：

init() r8168 … 

          … …

         … ：Kernel panic: Fatal exception

r8168是網(wǎng)卡型號(hào)。

在BIOS中禁用網(wǎng)卡，從光驅(qū)啟動(dòng)安裝系統(tǒng)。再?gòu)木W(wǎng)上下載網(wǎng)卡驅(qū)動(dòng)安裝。

#tar  vjxf  r8168-8.014.00.tar.bz2
# make  clean  modules       (as root or with sudo)
      # make  install
      # depmod  -a
      # modprobe  r8168

安裝好系統(tǒng)后reboot進(jìn)入BIOS把網(wǎng)卡打開。

另有網(wǎng)友在Kernel panic出錯(cuò)信息中看到“alc880”，這是個(gè)聲卡類型。嘗試著將聲卡關(guān)閉，重啟系統(tǒng)，搞定。

安裝linux系統(tǒng)遇到安裝完成之后，無(wú)法啟動(dòng)系統(tǒng)出現(xiàn)Kernel panic-not syncing fatal exception。很多情況是由于板載聲卡、網(wǎng)卡、或是cpu 超線程功能（Hyper-Threading ）引起的。這類問題的解決辦法就是先查看錯(cuò)誤代碼中的信息，找到錯(cuò)誤所指向的硬件，將其禁用。系統(tǒng)啟動(dòng)后，安裝好相應(yīng)的驅(qū)動(dòng)，再啟用該硬件即可。

另外出現(xiàn)“Kernel Panic — not syncing: attempted to kill init”和“Kernel Panic — not syncing: attempted to kill idle task”有時(shí)把內(nèi)存互相換下位置或重新插拔下可以解決問題。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論