[MTK] 深入了解Logging Tools 之 last_kmsg

last_kmsg

讲 last_kmsg 首先就要再讲 RAM Console。在 Kernel Log 章节我们有讲过 Kernel Log 除了输出到 Kernel Log Buffer 以外还会输出到 Console，在 MTK Turnkey 方案里面 Log Console 有两个，一个是 UART Console，一个是RAM Console。

RAM Console 设备驱动同样在 RAM 里面实现了一个 Ring Buffer。那为何有了 Kernel Log Buffer 还要再另外实现一个 RAM Console 的 Buffer 呢？是否多此一举？对于这个问题首先要搞清楚 RAM Console 设计的初衷。

举一个例子，重启问题的分析。当 Linux Kernel 出现 BUG 的时候，后走入 panic flow，这个时候由于 Kernel 出现了严重的问题，Native 程序全部都无法运行，adbd 也无法响应 adb 连接请求，这个时候想透过读取 Kernel Log Buffer 来看 Kernel Log 是不可能的。那怎么办？

由于 Console Log 是不需要下任何命令就可以查看的，所以可以抓取 UART Log 分析，但是抓 UART Log 就要飞线，就会比较麻烦，有没有一种简单的方法可以让我们知道系统大概发生了什么事情呢？那就是 RAM Console Log。

下图所示是 RAM Console 的工作原理。

其大致的工作流程如下：

1. 当系统开机初始化好 RAM Console Buffer 的时候就会开始进行 Logging，关于如何 Logging
   的部分可以再参考一下 printk 那幅图。
2. 一旦系统发生严重异常就会发生重启。
3. 重启后系统启动又会开始初始化 RAM Console Buffer，在初始化 RAM Console Buffer 之前 Buffer
   里面还保存了重启前的 Log 信息，在初始化的时候可以先将重启前的 Log 备份到另外一个 Buffer。
4. 备份的 Buffer 可以通过 cat /proc/last_kmsg 来访问其中的内容。

通过上述的机制我们就可以在重启后通过 /proc/last_kmsg 来查看重启前发生了什么事情。

应用场景

RAM Console 机制在 MTK Turnkey 方案中是一直打开的，它主要可以帮助我们理清两件事情：

1. 系统是否发生了重启。因为 /proc/last_kmsg 只有重启之后才会存在，所以只要 /proc/last_kmsg
   存在我们就知道系统重启过了。（不是所有的重启都是异常重启）
2. 如果系统重启了，我们可以根据 /proc/last_kmsg 的内容查看重启前系统都做了什么事情。

当然我们在 RAM Console header 里面还记录了 CPU hotplug 的情况以及 Hardware Watchdog Timeout Flow 的执行情况，以帮助 Debug 问题。（如果想了解相关的信息还请联系我们）

设计限制

last_kmsg 能够保存的信息比较少，这主要受制于 Internal SRAM 的大小。那为什么一定要放在 Internal SRAM 呢？

• 在早期的平台，如 MT6589，系统重启的时候会将 DRAM 内容复位，这导致了 RAM Console Buffer 无法放在外部 DRAM。
• Internal SRAM 位于 CPU 内部，是比较稳定的 module，可以 Cover 到 DRAM 不稳定的问题。所以虽然在 MT6572 以及之后的平台可以支持重启的时候保持住 DRAM 的内容，但是也没有在外部 DRAM 来实现 RAM Console。

所以，last_kmsg 的内容通常都会很少，约 7KB 左右，用来作为 Debug 问题时候的参考。

误区与疑问

为什么在 mtklog 目录下也会有 last_kmsg 文件？

last_kmsg 在分析重启问题的时候可以作为一个参考，所以如果在 mtklogger 里面打开了 MobileLog 之后，每次 MobileLog 启动的时候都会将 /proc/last_kmsg 抓取到 mtklog 目录下面去。

我在 mtklog 目录看到了 last_kmsg，系统发生了异常么？

通过前面的描述我们知道存在last_kmsg 表示系统重启过，但是重启并不意味着异常。举个例子，我们执行 adb reboot 也会存在 last_kmsg。或者在长按电源键的对话框里面实现了 Reboot 菜单，这样的重启属于正常重启，但是同样都会有 last_kmsg.

请不要把 last_kmsg 和 异常重启 画等号！

mtklog 目录下有很多 last_kmsg，系统重启了很多次么？

mobile log 每启动一次都会抓一次 last_kmsg，所以当看到很多 last_kmsg 时有可能仅仅是 mobilelog 停止/启动了很多次而已。

按last_kmsg 是 debug 重启问题，尤其是系统莫名其妙重启问题的一种辅助手段，但是也请不要将 last_kmsg 与异常重启问题画上等号。