TWI599877B

TWI599877B - 作業系統發生核心崩潰情況下讀取完整核心日誌之方法

Info

Publication number: TWI599877B
Application number: TW101150936A
Authority: TW
Inventors: 陳業新; 卞永才
Original assignee: 英華達股份有限公司
Priority date: 2012-11-08
Filing date: 2012-12-28
Publication date: 2017-09-21
Also published as: TW201418979A; CN103809989B; US9262283B2; CN103809989A; US20140129875A1

Description

作業系統發生核心崩潰情況下讀取完整核心日誌之方法

本發明係關於在作業系統發生核心崩潰後，讀取核心日誌的方法，尤指一種中央處理單元被進行復位重置後，即能完整導出核心日誌的方法。

按，由於Linux具有自由軟體(Free Software)與開放原始碼(Open Source)等特性，意即，只要使用者或企業是遵循GNU通用公眾授權條款(GNU General Public License，簡稱GNU GPL或GPL)的內容，便能夠自由地使用Linux核心(或稱為Linux內核)的所有底層原始碼，亦能夠自由地修改系統軟體與再發布修改後的系統軟體。由於Linux能供使用者(企業或個人)自由地對其進行最大程度的定制，因此，Linux能成為各種開放或封閉式系統的平台，且應用於中間件(Middleware)或嵌入式系統(Embedded system)上，故，目前有眾多電子產品(如：電腦、智慧型手機、導航系統)的系統軟體是採用Linux核心所開發設計完成，例如Android系統即為其一代表性作品。

一般言，在Linux核心運行的過程中，若應用程式發生非致命的執行時期錯誤(nonfatal runtime errors)時，Linux核心能對前述的錯誤情況予以處理，且允許應用程式執行完畢後，再產生錯誤結果訊息，但當發生硬體錯誤(如：irq conflict、bad block、high temperature)，或是應用程式發生除零(Divide By Zero)、記憶體訪問越界(Access Denied)、緩衝區溢位(Buffer Overflow)等不可恢復的錯誤(或稱，致命錯誤(fatal error))時，則可能會造成核心崩潰(KERNEL PANIC)，令Linux核心無法正常運行，進而發生當機情況。因此，使用者通常需讀取核心日誌的內容，以能瞭解核心崩潰的發生原因，進而順利解決問題。所謂的「核心日誌」係指，Linux核心於運行時，其會記錄系統的執行過程資訊，並將該等執行過程資訊保存在一個內部緩衝區中，記錄內容大抵包括：事件發生的日期與時間、發生此事件的主機名稱或來源IP、啟動此事件的服務名稱或函式名稱、該訊息的實際資料內容...等，以供使用者能藉由「核心日誌」的內容，得知終端裝置的各個軟、硬體的工作狀態。

承上所述，在未發生核心崩潰的情況下，使用者能使用「cat/proc/kmsg」命令輸出核心日誌，以查看Linux核心的運行狀況。但若系統發生核心崩潰的情況時，則可能造成前述「cat/proc/kmsg」命令無法輸出完整的核心日誌，令使用者無法正確地判斷出發生核心崩潰的原因。因此，針對核心崩潰的情況，Linux核心本身提供了panic機制與kdump機制，茲就前述兩種機制簡單說明如下：

(1)panic機制：當核心崩潰的情況發生時，由於Linux核心不知目前的程序該如何執行下一步驟，因此，其會將此時所能獲取到的所有資訊顯示出來，但實際上，顯示內容多寡會因造成核心崩潰的各種原因有所差異。舉例而言，當核心崩潰的類型是hard panic，使用者能使用「/var/log/messages」命令取得堆疊追蹤(stack trace)訊息；又，使用者尚能搜索應用程式日誌，以取得各個應用程式的運作過程；最後，使用者能自行記錄終端裝置之螢幕上所顯示之dump資訊。另，當核心崩潰的類型是soft panic，Linux核心會產生一個包含核心符號(kernel symbols)數據的dump資訊，該dump資訊會記錄於/var/log/messages中，又，使用者能透過ksymoops工具生成ksymoops檔案，以將核心符號數據轉換成可供判讀的資料。

(2)kdump機制(即，核心崩潰轉儲機制)：當核心崩潰的情況發生時，會啟動kexec程式，將作業系統的當前核心(即，發生核心崩潰的核心，後續稱前一個核心)引導至另一個備份核心。此時，前一個核心運行時的記憶體鏡像內容，會被保存至/proc/vmcore中，使用者能透過「cp」命令或「scp」命令，將vmcore檔複製至磁片上，並在重啟作業系統後，透過分析工具對vmcore檔進行分析，查找出導致前一個核心發生核心崩潰的原因。

綜上所述可知，無論是panic機制或kdump機制，均需先行對Linux核心進行相關設定，且使用者亦需額外下達多個命令，才能取得核心日誌，造成使用上的不便利性。因此，如何設計出一種更為方便的輸出核心日誌之方法，令使用者不需對系統核心進行繁複的額外設定，即成為相關業者之重要課題。

有鑑於現有輸出核心日誌的方法，均需對系統核心進行相關設定，造成使用上的困擾，尤其對於一些經驗不足的使用者而言，更是有著極大的不便性，因此，發明人經過長久努力研究與實驗，終於開發設計出本發明之一種作業系統發生核心崩潰情況下讀取完整核心日誌之方法，以期藉由本發明而能提供使用者一種更為方便輸出核心日誌的方法，大幅提高使用上的便利性。

本發明之一目的，係提供一種作業系統發生核心崩潰情況下讀取完整核心日誌之方法，主要能降低輸出核心日誌的複雜度，且能保持核心日誌的完整性，以便於使用者能在作業系統的核心崩潰(KERNEL PANIC)後，藉由閱讀核心日誌的內容而迅速地解決問題。該方法係應用於一終端裝置(如：電腦、智慧型手機)上，該終端裝置包括一中央處理單元及一記憶體單元，該記憶體單元係與該中央處理單元相電氣連接，且至少包括一核心運作區、一核心緩衝區、一日誌備份區及一用戶資料區，其中該核心運作區內儲存有一系統核心(System Kernel)，該方法能使中央處理單元藉由系統核心執行一作業系統，以驅動該終端裝置上的其它硬體；嗣，在中央處理單元執行該作業系統的狀態下，會針對執行過程的資訊，產生一核心日誌，並將該核心日誌分別儲存至該核心緩衝區及該日誌備份區中，當該中央處理單元被復位重置後，其會執行一核心模塊(Kernel Object)初始化程序，並將該核心日誌輸出至該用戶資料區，該核心日誌包括該中央處理單元被復位重置之前，運行該系統核心的完整資訊。如此，使用者僅需對中央處理單元進行復位重置(如：透過中央處理單元的重置腳位(Reset Pin)進行硬體重置)，便能夠將該核心日誌導出至該用戶資料區，以便使用者能藉由分析該核心日誌的內容，得知發生核心崩潰的原因。

為便貴審查委員能對本發明目的、技術特徵及其功效，做更進一步之認識與瞭解，茲舉實施例配合圖式，詳細說明如下：

本發明係一種作業系統發生核心崩潰情況下讀取完整核心日誌之方法，在一較佳實施例中，請參閱第1圖所示，一終端裝置1包括一中央處理單元10及一記憶體單元12，其中該終端裝置1能夠為個人電腦(Personal Computer，簡稱PC)、筆記本型電腦(Notebook，簡稱NB)、智慧型手機(Smartphone)、導航裝置(navigation device)、平板電腦(Tablet computer)或個人數位處理器(Personal Digital Assistant，簡稱PDA)等。另，請參閱第1及2圖所示，該記憶體單元12能夠為一快閃記憶體(Flash Memory)，並與該中央處理單元10相電氣連接，以能接收該中央處理單元10傳來的資料，且能傳送其內儲存的資料至該中央處理單元10。該記憶體單元12至少包括一核心運作區121、一核心緩衝區123、一日誌備份區125及一用戶資料區127(UserData)。

在此特別一提者，不同的作業系統(如：UNIX系統、Linux系統、FreeBSD系統)運用至不同的終端裝置時，會依實際需求規劃不同的分區。以智慧型手機搭配Android系統為例，依目前Android系統而言，其大致會劃分為下列各個分區：(1)hboot分區：主要作用為引導啟動終端裝置1，以能檢測終端裝置1的硬體訊息，並尋找作業系統所規劃的各個分區；(2)radio分區：主要作用為驅動通訊硬體，以使終端裝置1能進行通訊作業(如：撥打電話、發送簡訊)；(3)recovery分區：主要為儲存恢復作業系統所需的備份資料；(4)boot分區：主要為系統核心的儲存位置；(5)system分區：主要為內建程式的儲存位置；(6)cache分區：主要為系統緩存區；及(7)userdata分區：主要用以儲存使用者資料。

因此，復請參閱第1及2圖所示，本發明所述的各個分區，乃是使用上位名詞敘述各個分區的作用，其中核心運作區121、核心緩衝區123及用戶資料區127，均為習知分區，例如：核心運作區121能為hboot分區、recovery分區、boot分區與system分區的統稱，核心緩衝區123為cache分區，用戶資料區127則為userdata分區。其中核心運作區121主要是指系統核心正常運作時所需使用的多個分區，至於核心緩衝區123與用戶資料區127則是因本發明的方法中，需對該二分區123、127進行另外步驟，故才未劃分至核心運作區121 中，合先陳明。另，本發明之日誌備份區125並非是習知分區，而是在記憶體單元12中額外開闢一專用內存區域，因此，當作業系統發生核心崩潰(KERNEL PANIC)時，日誌備份區125不會受到核心崩潰影響而毀損。

復請參閱第1及2圖所示，其中該核心運作區121內儲存有系統核心122(System Kernel)，該中央處理單元10能藉由該系統核心122執行一作業系統，以驅動該終端裝置1上的其它硬體(如：光碟機、顯示卡、藍牙模組...等)，在中央處理單元10執行該作業系統的狀態下，其會針對執行過程的資訊，產生一核心日誌，又，該中央處理單元10會如同習知作法般，將核心日誌儲存至該核心緩衝區123中，因此，若在Linux系統中，使用者便能使用「cat/proc/kmsg」命令，自核心緩衝區123輸出核心日誌，以查看Linux核心的運行狀況。此外，本發明之中央處理單元10，尚會將核心日誌儲存至額外開闢的日誌備份區125中，意即，本發明之核心日誌會同時存在於核心緩衝區123與日誌備份區125中。

另，請參閱第1及3圖所示，該日誌備份區125中包括一數據讀寫標記區1251、一數據起始區1253、一數據結束區1255及一實際數據區1257，其中該數據讀寫標記區1251設有一狀態指標，該狀態指標至少包括三種狀態，第一是寫入狀態，第二是讀取狀態，第三則是未知狀態。所謂的未知狀態是針對寫入狀態、讀取狀態而言，在該實施例中，當狀態指標的數值為「0xbeefbeef」代表寫入狀態，當狀態指標的數值為「0xfaceface」則代表讀取狀態，至於不屬於前述數值者，便歸屬於未知狀態。當終端裝置1第一次開機、或是經正常關機程序後再開機時，該狀態指標均會為未知狀態，且中央處理單元10能依作業系統的使用需求，將狀態指標設定為寫入狀態或讀取狀態；當狀態指標為寫入狀態時，中央處理單元10能將核心日誌寫入至該實際數據區1257，且該核心日誌在該實際數據區1257中的起始位置，會被記露於數據起始區1253中，以形成一起始位置數值，又，該核心日誌在該實際數據區1257中的結束位置，則會被記露於數據結束區1255中，以形成一結束位置數值；當狀態指標為讀取狀態時，中央處理單元10僅能自該實際數據區1257中讀取出核心日誌，且其會依起始位置數值及結束位置數值，自實際數據區1257中讀取符合該等位置數值的核心日誌內容。

再者，復請參閱第1~3圖所示，當使用者第一次開啟終端裝置1時，或者是將正常關機的終端裝置1開啟時，中央處理單元10會執行一核心模塊(Kernel Object)初始化程序，並讀取狀態指標，當其判斷出該狀態指標為未知狀態後，會將狀態指標設定為寫入狀態，以能在後續執行作業系統時，於該實際數據區1257中寫入核心日誌。當作業系統發生核心崩潰(KERNEL PANIC)時，使用者能對中央處理單元10採用硬體重置(hard reset)的方式，即將中央處理單元10的重置腳(reset PIN)短路，此時，該中央處理單元10會執行該核心模塊初始化程序，並讀取狀態指標，當其判斷出該狀態指標為寫入狀態後，即代表作業系統未經過正常關機程序，狀態指標才並非為未知狀態。因此，中央處理單元10會將該狀態指標設定為讀取狀態，且自數據起始區1253與數據結束區1255中，讀取起始位置數值與結束位置數值，嗣，該中央處理單元10便會根據起始位置數值與結束位置數值，自實際數據區1257中讀取出核心日誌，並儲存至用戶資料區127，之後，中央處理單元10會重新將狀態指標設定為寫入狀態，以便後續執行作業系統時，能於日誌備份區125中寫入核心日誌。另，假設當中央處理單元10將該狀態指標設定為讀取狀態，但尚未完整讀取出核心日誌時，又再次發生核心崩潰，則中央處理單元10經過硬體重置後，同樣會再次執行該核心模塊初始化程序。又，當其判斷出該狀態指標為讀取狀態後，其會直接根據起始位置數值與結束位置數值，自實際數據區1257中讀取出核心日誌，且在其將核心日誌儲存到用戶資料區127後，會將狀態指標設定為寫入狀態。

請參閱第1~4圖所示，其中第4圖係為本發明之核心模塊初始化程序的部份腳本內容與中文注解，其中「printk2glog.ko」係為核心模塊初始化程序的名稱，但業者亦可依自身需求更改該名稱。另，「0x100000」係為日誌備份區125的容量大小，「0x2FE00000」則表示日誌備份區125的起始地址，在該實施例中日誌備份區125的容量為1M位元(Byte)，可隨著微電子技術的精進，導致記憶體單元12容量大增的情況下，業者亦能夠提高日誌備份區125的容量。「glog.txt」為核心日誌的名稱，在該實施例中，中央處理單元10會以每次讀取4K位元的容量大小，依序讀取出實際數據區1257之核心日誌的內容，至於最後生成之核心日誌(即， glog.txt)的大小，便是依起始位置數值及結束位置數值而定。在此聲明者，由於本發明之日誌備份區125的容量大小為1M位元，若作業系統寫入的核心日誌容量超過1M位元時，則最後寫入的核心日誌內容，會覆蓋最早寫入的核心日誌內容，意即，起始位置數值會等於結束位置數值+1，如此，即可避免起始位置數值等於結束位置數值，造成中央處理單元10所輸出的核心日誌內容不正確。

承上所述，為能明確揭露前述之較佳實施例的整體方法，以下茲僅就本發明之中央處理單元10執行核心模塊初始化程序的主要處理流程，進行說明，請參閱第1~3及5圖所示：(301)執行核心模塊初始化程序，進入步驟(302)；(302)讀取狀態指標，進入步驟(303)；(303)判斷狀態指標是否為未知狀態，若是，進入步驟(304)，若否，進入步驟(305)；(304)設定狀態指標為寫入狀態，並針對執行作業系統過程的資訊，產生核心日誌，且將該核心日誌分別儲存至核心緩衝區123及日誌備份區125中；(305)判斷狀態指標是否為寫入狀態，若是，進入步驟(306)，若否，進入步驟(307)；(306)設定狀態指標為讀取狀態，進入步驟(307)；及(307)讀取日誌備份區125中的核心日誌，並將該核心日誌儲存至用戶資料區127，進入步驟(304)。

綜上所述可知，復請參閱第1~3圖所示，當中央處理單元10被硬體重置後，此時，狀態指標不會恢復成未知狀態，因此，中央處理單元10會自動地將日誌備份區125的核心日誌，儲存至用戶資料區127中，故，使用者僅需自用戶資料區127中輸出核心日誌，便能夠查閱中央處理單元10被硬體重置之前，作業系統的運作情況，得知發生核心崩潰的原因。而不會如同習知方式(如：panic機制與kdump機制)般，需透過複雜設定才能取得核心日誌。另，誠如前述，由於本發明的日誌備份區125是在記憶體單元12中額外開闢設置，並非是原有作業系統(如：Linux系統)的習知分區，因此，在作業系統發生核心崩潰時，不會影響到日誌備份區125，故能保證核心日誌的完整性。

再者，復請參閱第1~3圖所示，雖然前述實施例中，是以中央處理單元10被硬體重置為例，但在其它實施例中，業者能夠在作業系統上安裝一監控程式(如：watchdog)，當該監控程式發現作業系統出現異常時，其能傳送一復位訊號至中央處理單元10，該中央處理單元10在接收到該復位訊號後，便會執行前述步驟(301)~(307)。故可知，無論是使用者直接對中央處理單元10進行硬體重置，或者是監控程式對中央處理單元10傳送復位訊號，皆代表中央處理單元10被復位重置的情況。因此，只要中央處理單元10被復位重置後，會執行執行核心模塊初始化程序，並由額外開闢設置的日誌備份區125讀取出核心日誌，再將該核心日誌儲存至用戶資料區127，即應屬本發明所述及之方法。

在此特別一提者，本發明之實施例所用語彙僅供敘述之用，不應視為本發明之限制，熟悉本發明相關技藝之人士當能在掌握本發明之主要技術特徵後，自行利用其他近似結構、裝置及系統加以實現，從而達成本發明之目的，因此，本發明所主張之權利範圍，並不侷限於此，按凡熟悉該項技藝人士，依據本發明所揭露之技術內容，可輕易思及之等效變化，均應屬不脫離本發明之保護範疇，再者，雖然本發明之實施例與圖式中，乃繪製了分區格式內容與腳本內容，但僅為方便說明，並得以供一般大眾或本技藝之從業人員，迅速領略本發明揭露內容之本質與要旨，而並非僅限定為上述的記載內容或方式，合先陳明。

1‧‧‧終端裝置

10‧‧‧中央處理單元

12‧‧‧記憶體單元

121‧‧‧核心運作區

122‧‧‧系統核心

123‧‧‧核心緩衝區

125‧‧‧日誌備份區

1251‧‧‧數據讀寫標記區

1253‧‧‧數據起始區

1255‧‧‧數據結束區

1257‧‧‧實際數據區

127‧‧‧用戶資料區

2‧‧‧部份腳本內容與中文注解

301~307‧‧‧步驟

第1圖係本發明之終端裝置的硬體方塊圖；第2圖係本發明之記憶體單元的分區示意圖；第3圖係本發明之日誌備份區的示意圖；第4圖係本發明之核心模塊初始化程序的腳本內容；及第5圖係本發明之中央處理單元讀取核心日誌的流程圖。

301~307‧‧‧步驟

Claims

一種作業系統發生核心崩潰情況下讀取完整核心日誌之方法，該方法係應用於一終端裝置上，該終端裝置包括一中央處理單元及一記憶體單元，該記憶體單元係與該中央處理單元相電氣連接，且至少包括一核心運作區、一核心緩衝區、一日誌備份區及一用戶資料區，其中該核心運作區內儲存有一系統核心，該日誌備份區包括一實際數據區、一數據讀寫標記區、一數據起始區及一數據結束區，其中，該實際數據區係能儲存一核心日誌，該數據讀寫標記區內設有一狀態指標，在該狀態指標被設定為寫入狀態的情況下，該中央處理單元能將該核心日誌寫入至該實際數據區，在該狀態指標被設定為讀取狀態的情況下，該中央處理單元則僅能讀取該實際數據區中已寫入的該核心日誌，該數據起始區係對應於該核心日誌被寫入至該實際數據區的起始位置，該數據結束區則對應於該核心日誌被寫入至該實際數據區的結束位置，該方法能使該中央處理單元執行下列步驟：藉由該系統核心執行一作業系統，以驅動該終端裝置上的其它硬體；在執行該作業系統的狀態下，會針對執行過程的資訊，產生該核心日誌，並將該核心日誌分別儲存至該核心緩衝區及該日誌備份區中；在該中央處理單元被復位重置的情況下，執行一核心模塊初始化程序；讀取該日誌備份區中的該核心日誌；及將該核心日誌儲存至該用戶資料區，該核心日誌包括該中央處理單元被復位重置之前，運行該系統核心的完整資訊。
如請求項1所述之方法，其中該中央處理單元在執行該核心模塊初始化程序後，會執行下列步驟，以讀取該日誌備份區中的該核心日誌：讀取該狀態指標，並判斷該狀態指標的狀態為何；判斷出該狀態指標為寫入狀態後，將該狀態指標設定為讀取狀態；及讀取該起始位置數值與該結束位置數值，且依據該等位置數值，讀取該實際數據區中的該核心日誌。
如請求項1所述之方法，其中該中央處理單元在執行該核心模塊初始化程序後，會執行下列步驟，以讀取該日誌備份區中的該核心日誌：讀取該狀態指標，並判斷該狀態指標的狀態為何；及判斷出該狀態指標為讀取狀態後，讀取該起始位置數值與該結束位置數值，且依據該等位置數值，讀取該實際數據區中的該核心日誌。
如請求項2或3所述之方法，其中該中央處理單元被復位重置的情況，係為該中央處理單元被採用硬體重置的方式。
如請求項2或3所述之方法，其中該作業系統尚安裝一監控程式，在該監控程式傳送一復位訊號至中央處理單元後，該中央處理單元會被復位重置。
如請求項4所述之方法，在該中央處理單元將該核心日誌輸出至該用戶資料區後，其會將該狀態指標設定為寫入狀態。
如請求項5所述之方法，在該中央處理單元將該核心日誌輸出至該用戶資料區後，其會將該狀態指標設定為寫入狀態。