/proc/last_kmsg

/proc/last_kmsg

last_kmsg

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

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

其大致的工作流程如下：

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

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

应用场景

RAM Console 主要可以帮助我们理清两件事情：

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

当然我们在 RAM Console header 里面还记录了 CPU hotplug 的情况以及 Hardware Watchdog Timeout Flow 的执行情况，以帮助 Debug 问题。

Android的ram_console和last_kmsg

https://blog.csdn.net/hong_z_m/article/details/44890905

ram_console和last_kmsg是Android加入到kernel中的一个Debug功能。

实现：

      android要求平台提供一块固定的内存，作为ram_console的存储空间。然后通过“代码：register_console(&ram_console);”，将ram_console注册到printk输出的console_list中去，所以printk会时时向ram_console中输出kernel log。在ram_console头部有一个“代码：RAM_CONSOLE_SIG”的签名，每次android设备启动的时候，会check头部的签名是否正确。如果正确，那就会将ram_console中的内容保起来，生成一个/proc/last_kmsg的节点，用来查看上次最后的kernel log。如果不正确，就不会生成last_kmsg。

作用：

    ram_console和last_kmsg的作用是用来分析重启的原因。

    1. 如果是kernel panic造成的重启，则可以在last_kmsg中panic的现场。

    2. 如果人为的重启，则有机会在last_kmsg中找到一定线索。

    3. 如果没有last_kmsg，说明系统一定掉过电。可以作为分析重启原因的一个重要线索。

探索：

    那么问题来了，平台是如何为ram_console提供一块固定内存的呢？

    我们先来看MTK平台：

    MTK平台直接给了一个虚拟地址：CONFIG_MTK_RAM_CONSOLE_ADDR=0xF900DC00

    然后我们找到了：（说明MTK平台将SOC的SRAM中的64K映射到了kernel虚拟地址中的0xF9000000-0xF9010000）

    #define INTER_SRAM 0xF9000000
---------------------  
作者：微笑明明  
来源：CSDN  
原文：https://blog.csdn.net/hong_z_m/article/details/44890905  
版权声明：本文为博主原创文章，转载请附上博文链接！