Linux - Kernel panic

Kernel panic的意思是指，OS遇到了一個內部的錯誤，這個錯誤並沒辦法被安全的修復起來，而導致沒辦法繼續運行，可能必須重新啟動才行。有點像Windows 的藍屏死機。

而造成Kernel panic的原因，大多是是擴充記憶體出現問題，但亦有可能是其他硬體產生。在嵌入式系統環境下，可用的memory空間往往不夠，因此一旦kernel編譯出來，必需要去指定該用多少空間，不然一旦超出範圍，就一下子就當了。

Note:

以我這次遇到的狀況是版子上電壓偏差過大(ex. 原本腳位是3.3V的設計，但實際用電表量後只剩下2.2V)，所以導致CPU無法R/W FLASH導致問題產生。

Reference:

[1] http://ccu-cs-os2009s-495410074.blogspot.tw/2009/06/kernel-panic.html

Priority scheduling

每一個process都有一個priority，system會從priority的開始優先處理。若一直有高priority的process要執行的話，則可能會造成low priority的process永遠不會被執行到，造成indefinite blocking or starvation。

Priority Scheduling可以是preemptive or non-preemptive。若是preemptive，則新到process若其priority比正在跑之process高則取代它執行；若是後者則放在ready queue中等待執行

indefinite blocking也可能發生在用LIFO(Last In First Out)的scheduling中

Solution:這可以用aging或者Dynamic Priority, Floating Priority來解決
/* aging: 系統每隔一段時間，將待在系統內時間很長，卻又未能完成工作的process，逐漸調高其priority，因此，在有限的時間內，其優先權可以升到最高，進而可取得資源完成工作 */


Reference:
[1]http://www.csie.ntnu.edu.tw/~swanky/os/chap4.htm

Race condition

在shared memory[1]溝通方式下，若未對共享變數提供任何互斥存取控制(or同步)機制，則執行的結果(共享變數之值)會依process執行次序不同而有所不同


解決Race condition有幾種方法，1)Disable Interrupt，2)Critical Section Design


1)Disable Interrupt：
Process在對共享變數進行存取之前，先Disable Interrupt(i.e. 發出system call請求OS執行)，如此可以確保Process在對其共享變數存取期間不受任何其他processes干擾(or preemption)。直到完成此敘述後才Enable Interrupt

優點：簡單
缺點：僅適用於uni-processor環境，但不適用於multi-processors下
/* 因為要disable all cpu的 interrupt非常耗費時間及資源，system performance很差 */

2)Critical Section Design：
對共享變數進行Lock control，process一旦取得對此共享變數之存取權，在其尚未完成工作時，Lock決不會打開直到完成，才會打開Lock讓其他process存取。

/* 點我延伸討論Critical Section Design */

Reference:
[1] shared memory：
一組process透過對share variables之存取，達到彼此溝通之目的。OS沒有提供額外支援(Global)，僅提供memory space而已，此種方式Programmer負擔重，必須確保共享變數之互斥存取機制(or同步)，以確保正確性。Race condition為shared memory下可能產生的問題之一，另外一個可能問題是Data Inconsistency，執行的結果不如預期。

[2] OS課本/教材

Critical Section/Mutex/Semaphore

Critical section(臨界區間)指的是一個存取共用資源（例如：共用裝置或是共用記憶體）的程式片段，而這些共用資源又無法同時被多個執行緒存取的特性[1]

Critical section design必須要滿足三個特性：
1)Mutual exclusion
2)Progress
3)Bounded waiting


1)Mutual exclusion
同一時間點，絕不允許有多個(大於兩個)processes在各自的C.S.內活動，亦即當有一process在自己的C.S.內活動，其他想進入各別C.S.內的processes必須等待，直到該process離開C.S.

2)Progress
I：不想進入C.S.的process絕不能阻礙其他processes進入C.S. (i.e.絕不參與進入C.S.的決策過程)
II：決定哪個processes可以進入C.S.的決策時間是有限的(i.e. No Deadlock)

3)Bounded waiting
自process提出申請進入C.S.到其獲准進入C.S.的這段等待時間是有限的。/* 即n個process欲進入C.S.，則任何一process至多等待(n-1)次後，即可進入C.S */



multi-tasking system中要解決Critical section問題就有Mutex以及Semaphore兩種方法
1)Mutex
Mutex基本就像是把key，當有process想要access一個共用的resource時會先去取得進入這個resource的"Key"，當這個key被前一個process給hold住的時候就只能wait

2)Semaphore
雷同Mutex，但是把它擴大為可以同時有N個人擁有key並能access共用的resource

Reference:

[1]http://zh.wikipedia.org/wiki/%E8%87%A8%E7%95%8C%E5%8D%80%E6%AE%B5

Interrupt and Exception

Interrupt 和 exception 是兩種改變系統執行程式順序的方式，分別透過不同的元件觸發。當 interrupt 或 exception 被觸發時，系統會經由查表找到相對應的處理程式（ ISR: Interrupt Service Routine，或稱 interrupt handler ），並中斷原本在執行的程式，讓 CPU 執行 ISR 的內容，之後才再轉回原來的程式中。這是多工（ multi-tasking ）環境中常常用到的技術。

在此， interrupt 指的是由硬體發出的中斷訊號，而 exception 指的是由軟體或系統所產生的中斷訊號。


Exception 則依照發生的場合可以分為兩種類型： 程式執行錯誤或例外事件，前者是發生在程式執行錯誤時，如被除數為零、 overflow 等；後者則像是 system call 等作業系統所提供的服務。
 
 
Reference:
[1] http://opencsl.openfoundry.org/Lab06_interrupt_exception.rst.html
 
--
/* Note: 去面試考到這個，但太久沒看OS全部都忘光，好慘 - -*/