隨著嵌入式Linux系統的廣泛應用，對系統的可靠性提出了更高的要求，尤其是涉及到生命財產等重要領域，要求系統達到安全完整性等級3級以上［1］，故障率（每小時出現危險故障的可能性）為10-7以下，相當于系統的平均故障間隔時間（MTBF）至少要達到1141年以上，因此提高系統可靠性已成為一項艱巨的任務。對某公司在工業領域14 878個控制器系統的應用調查表明，從2004年初到2007年9月底，隨著硬軟件的不斷改進，根據錯誤報告統計的故障率已降低到2004年的五分之一以下，但查找錯誤的時間卻增加到原來的3倍以上。
　　這種解決問題所需時間呈上升的趨勢固然有軟件問題，但缺乏必要的手段以輔助解決問題才是主要的原因。通過對故障的統計跟蹤發現，難以解決的軟件錯誤和從發現到解決耗時較長的軟件錯誤都集中在操作系統的核心部分，這其中又有很大比例集中在驅動程序部分［2］。因此，錯誤跟蹤技術被看成是提高系統安全完整性等級的一個重要措施［1］，大多數現代操作系統均為發展提供了操作系統內核“崩潰轉儲”機制，即在軟件系統宕機時，將內存內容保存到磁盤［3］，或者通過網絡發送到故障服務器［3］，或者直接啟動內核調試器［4］等，以供事后分析改進。
　　基于Linux操作系統內核的崩潰轉儲機制近年來有以下幾種：
　　（1） LKCD（Linux Kernel Crash Dump）機制［3］;
　　（2） KDUMP（Linux Kernel Dump）機制［4］；
　　（3） KDB機制［5］；
　　（4） KGDB機制［6］。
　　綜合上述幾種機制可以發現，這四種機制之間有以下三個共同點：
　　（1） 適用于為運算資源豐富、存儲空間充足的應用場合；
　　（2） 發生系統崩潰后恢復時間無嚴格要求；
　　（3） 主要針對較通用的硬件平臺，如X86平臺。
　　在嵌入式應用場合想要直接使用上列機制中的某一種，卻遇到以下三個難點無法解決：
　　（1） 存儲空間不足
　　嵌入式系統一般采用Flash作為存儲器，而Flash容量有限，且可能遠遠小于嵌入式系統中的內存容量。因此將全部內存內容保存到Flash不可行。
　　（2） 記錄時間要求盡量短
　　嵌入式系統一般有復位響應時間盡量短的要求，有的嵌入式操作系統復位重啟時間不超過2s，而上述幾種可用于Linux系統的內核崩潰轉儲機制耗時均不可能在30s內。寫Flash的操作也很耗時間，實驗顯示，寫2MB數據到Flash耗時達到400ms之多。
　　（3） 要求能夠支持特定的硬件平臺
　　嵌入式系統的硬件多種多樣，上面提到的四種機制均是針對X86平臺提供了較好的支持，而對于其他體系的硬件支持均不成熟。
　　由于這些難點的存在，要將上述四種內核崩潰轉儲機制中的一種移植到特定的嵌入式應用平臺是十分困難的。因此，針對上述嵌入式系統的三個特點，本文介紹一種基于特定平臺的嵌入式Linux內核崩潰信息記錄機制LCRT（Linux Crash Record and Trace），為定位嵌入式Linux系統中軟件故障和解決軟件故障提供輔助手段。
　　1 Linux內核崩潰的分析
　　分析Linux內核對于運行期間各種“陷阱”的處理可以得知，Linux內核對于應用程序導致的錯誤可以予以監控，在應用程序發生除零、內存訪問越界、緩沖區溢出等錯誤時，Linux內核的異常處理例程可以對這些由應用程序引起的異常情況予以處理。當應用程序產生不可恢復的錯誤時，Linux內核可以僅僅終止產生錯誤的應用程序，其他應用程序仍然可以正常運行。
　　
　　如果Linux內核本身或者新開發的Linux內核模塊存在bug，產生了“除零”，“內存訪問越界”、“緩沖區溢出”等錯誤，同樣會由Linux內核的異常處理例程來處理。Linux內核通過在異常處理程序中判斷，如果發現是“嚴重的不可恢復”的內核異常，則會導致“內核恐慌”（kernel panic），即Linux內核崩潰。圖1所示為Linux內核對異常情況的處理流程。
　　2 LCRT機制的設計與實現
　　通過對Linux內核代碼的分析可知，Linux內核本身提供了一種“內核通知機制”［7-8］，并預定義了“內核事件通知鏈”，使得Linux內核擴展開發人員可以通過這些預定義的內核事件通知鏈在特定的內核事件發生時執行附加的處理流程。通過對Linux內核源代碼的研究發現，對于上文中提到的“嚴重不可恢復的內核異常”，預定義了一個通知鏈和通知點，使得在發生Linux內核崩潰之后，可以在Linux內核的panic函數中預定義的一個“內核崩潰通知鏈”［7］上掛接LCRT機制來獲得Linux內核崩潰現場的一些信息并記錄到非易失性存儲器中，以便分析引起Linux內核崩潰的原因。