當 Linux Kernel 出現 BUG 的時候，後走入 panic flow，這個時候由於 Kernel 出現了嚴重的問題，adbd 也無法響應 adb 連接請求，這個時候想透過讀取 Kernel Log Buffer 來看 Kernel Log 是不可能的。那怎麼辦？
由於 Console Log 是不需要下任何命令就可以查看的，所以可以抓取 UART Log 分析，但是抓 UART Log 就要飛線，就會比較麻煩，有沒有一種簡單的方法可以讓我們知道系統大概發生了什麼事情呢？那就是 RAM Console Log。
- 下圖所示是 RAM Console 的工作原理。
其大致的工作流程如下：
- 當系統開機初始化好 RAM Console Buffer 的時候就會開始進行 Logging。
- 一旦系統發生嚴重異常就會發生重啓。
- 重啓後系統啓動又會開始初始化 RAM Console Buffer，在初始化 RAM Console Buffer 之前 Buffer 裏面還保存了重啓前的 Log 信息，在初始化的時候可以先將重啓前的 Log 備份到另外一個 Buffer。
- 備份的 Buffer 可以通過 cat /proc/last_kmsg 來訪問其中的內容。
通過上述的機制我們就可以在重啓後通過 /proc/last_kmsg 來查看重啓前發生了什麼事情。
應用場景
RAM Console 主要可以幫助我們理清兩件事情：
- 系統是否發生了重啓。因爲 /proc/last_kmsg 只有重啓之後纔會存在，所以只要 /proc/last_kmsg 存在我們就知道系統重啓過了。（不是所有的重啓都是異常重啓）
- 如果系統重啓了，我們可以根據 /proc/last_kmsg 的內容查看重啓前系統都做了什麼事情。
當然我們在 RAM Console header 裏面還記錄了 CPU hotplug 的情況以及 Hardware Watchdog Timeout Flow 的執行情況，以幫助 Debug 問題。
查看 系統重啓前的kernel log，cat /proc/last_kmsg或者cat /sys/fs/pstore/console-ramoops，必須系統重啓才存在這個log，這裏也可以看出系統重啓的原因。