当 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，这里也可以看出系统重启的原因。