linux內核模塊的死機有沒有從外部規避的辦法？

01-13

如題，嵌入式設備中，內核模塊死機導致的系統重啟和不可用，如何降低這種影響。比如：

原本Null Pointer訪問導致應該panic死機的情況變成不死機重啟，自恢復。

或者極快的速度整機重啟恢復。原本整機重啟要2分鐘，現在1秒恢復之類的。

或者其他什麼大招。

這裡不考略解決這些死機的思路，只考慮從外圍規避問題。我自己是認為不存在這種大招。因為：
1、如果有的話，linux為什麼不引入這種機制。

2、從原理上分析，比如內存改寫，引發錯誤的指針訪問，這種問題即使做到不死機（能做到么？），也無法保證自恢復了吧。
3、如果我有這麼牛逼的技術，我早TM自己幹了。
但是這些理由不足以說服老闆（已入魔），他認為業界應該有方案，只是沒有好好去找。
請問存在這種方案嗎？如果有，請指點下。
如果沒有，如何用嚴密的計算機科學的理論證明出來。
再補充下，硬體平台有ARM，MIPS，PowerPC幾種，有單核的也有多核的，硬體沒法變更。內存128M。資源消耗已經滿額了。系統的硬體架構沒有辦法改變了，要求在以前的產品上通過軟體升級提升可用性。
kernel 目前使用2.6到3.14之間的幾個版本。軟體可以變更。

系統重啟業務恢復速度2分鐘，這個也做過很多輪優化，瓶頸在於硬體的初始化和業務邏輯的固有消耗。不是內核重新起來就完事了。
熱備方案也不考慮。
-----
0715
其實我自己清楚在以上的限制條件下是沒什麼招的，但是怎麼從理論上證明確實沒招，其實是好奇這個答案。

既然是你老闆開的題，讓你老闆也開個價唄？

雖然不熟悉，但是你方向肯定搞錯了。

首先你得分清楚哪些是哪些不需要恢復的，哪些是需要恢復的，恢復到什麼程度。

錯了的肯定就是錯了，沒有必要恢復，讓系統再次可用即可。

別鑽牛角尖，我感覺你做到高可用性就滿足你們老闆的需求了。

就像@唐生說的就是一個思路

根本問題是驅動代碼不合格，內核態應該盡量簡單明確杜絕問題。其他的複雜操作可以帶到用戶空間的驅動庫中解決，沒必要在內核里塞一大坨代碼。

想要消滅蟲害，應該徹底除蟲，切不可弄一堆備件咬爛了就換。

做主備機業務，內核死機通知備機升主，主動倒換業務，灰常快。不用謝，請叫我雷鋒。

看門狗就行了。

嵌入式linux, 優化下2秒啟動，不是啥問題。

利用虛擬機級ha

「原本Null Pointer訪問導致應該panic死機的情況變成不死機重啟，自恢復。」——修改data abort handler。但是這個沒什麼價值——null pointer已經證明你寫的程序有嚴重問題了，沒必要嘗試恢復。

把你的邏輯移到用戶態實現

提主說了通過外部避歸。我理解意思是不去正面解決問題（例如提升代碼質量、縝密的差錯處理等手段），理解為預期內核會隨時、高頻率crash，crash以後怎麼恢復能力。可能的思路：想辦法提高硬重啟速度，壓榨代碼運行時間；熱重啟，例如windows 10的快速啟動模式，保存核心狀態，重啟時直接load進來；虛擬化、並行運行多份kernel；再向外想，冗餘機器一起跑，一台沒響應切換到其他機器。

話說，外部補救辦法總是有的，代價就是money，有錢可以任性。最好能在內部把問題解決掉，除了提高代碼健壯性，有些工程手段也值得借鑒，例如微內核能做到模塊隔離，不讓問題擴散，在linux環境下也適用，服務盡量不要依賴內核代碼。

做冗餘備份？一台掛掉切換到另一台，typeC，typeD一類的

二個設備綁一塊，互ping，一台死了馬上另一台自動接上並且重啟死的那台

解決這個問題太簡單了，既然是外部解決，那說明此嵌入式主機肯定不是題主他們公司做的，如果不是本公司做的，它老死機你們幹嘛還用它，換供應商/方案商即可。你要想辦法幫你們老闆解決問題，而不是按照他的思路解決問題。

有沒有像我一樣看著覺得可怕的，太小了，就覺得不可能的事，餅乾這樣設計完全沒辦法贊同呀～

內核崩潰有串口log，通過log能基本大概確定是什麼部位，甚至是哪一個函數調用出錯的，出現崩潰首先得要解決根本性的問題，而不是fail safe，實在解決不了的時候才用補救方法。

linux做不到。。。如果可以你試試把驅動寫在用戶態吧，效率低點。嵌入式資源這麼少也不適合虛擬化。不過arm 有幾款帶硬體hypervisor的多核心處理器，早期做手機的就是有裝兩個系統，分別跑在不同core上，一個跑rtos整信號處理和基帶，另一個跑linux. 也許有大神可以整出跑多個linux? 你關注下kvm。思路好像跟伺服器虛擬化差不多，就看處理器資源夠不夠多。再有就是試試minix這種微內核的操作系統?

首先這個問題，沒太懂，內核死機重啟又不可用，又什麼內核機制，你確定你代碼沒問題?

你想2秒啟動也可以，就是自製rootfs，就能實現，但是無法解決你的根本問題。