Android系统高通平台Kernel Watchdog

本文深入探讨了Android系统在高通平台上的Kernel Watchdog实现,包括Device Tree中的定义、核心数据结构struct msm_watchdog_data、初始化过程以及详细的工作流程。当喂狗定时器超时,系统会执行中断处理并可能触发硬件重启来确保系统稳定性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


Watchdog 概念
Watchdog主要应用于嵌入式系统,用于系统出现严重故障(如内核死锁,进入死循环,CPU跑飞等)不能恢复时,在无人为介入的情况下可以自动重新启动系统。
在传统Linux 内核下, watchdog的基本工作原理是:当watchdog启动后(即/dev/watchdog 设备被打开后),如果在某一设定的时间间隔内/dev/watchdog没有被执行写操作, 硬件watchdog电路或软件定时器就会重新启动系统。
Watchdog根据实现方式又可以分为硬件watchdog和软件watchdog。硬件watchdog必须有硬件电路支持,设备节点/dev/watchdog对应真实的物理设备。软件watchdog通过通过内核定时器来实现,/dev/watchdog并不对应真实的物理设备。
硬件watchdog比软件watchdog有更好的可靠性。软件watchdog最大的优势是成本低,因此在可靠性要求不是很高一般民用产品被广泛使用。硬件watchdog的优势是可靠性高,因此在对可靠性要求严格的工业产品中被广泛使用。
但是在高通平台Android系统中,watchdog的实现有所不同,稍后我们会分析,这里只需知道其并没有提供/dev/watchdog。
当然在系统出现严重故障不能恢复时触发Watchdog,重启系统,仅仅是一个补救措施,虽然有效,但是过于简单粗暴,用户体验不佳 解决问题的最好方法是不让问题发生,因此我们需要针对watchdog进行和分析,尽量不让问题不发生。
注意Android系统中还有一套watchdog实现,也是使用软件实现的,用于检测SystemServer中各Service是否正常运行。大家不要搞混了。
如没有特别说明,本文后续提到的watchdog都特指高通平台Android系统kernel中watchdog。

Watchdog的实现

2.0 Device Treewatchdog的定义

       wdog: qcom,wdt@17817000 {
              compatible = "qcom,msm-watchdog";
              reg = <0x17817000 0x1000>; // 没有查到对应寄存器的说明
              reg-names = "wdt-base";
              interrupts = <0 3 0>, <0 4 0>; // 狗叫和狗咬的中断,由于目前的实现是狗叫的同时就进行狗咬,所以只用到了狗叫的中断
              qcom,bark-time = <11000>; // 超过 11 秒没有喂狗,连叫带咬,系统重启
              qcom,pet-time = <10000>; // 10 秒喂狗一次
              qcom,ipi-ping; // 喂狗时需要 ping 一下系统中的其他 cpu ,确保所有 cpu 都处于正常状态
              qcom,wakeup-enable; // 看门狗具有唤醒系统的能力,如果不具备唤醒能力的话,需要在系统睡眠时关闭看门狗,唤醒时再重新打开看门狗
              qcom,scandump-size = <0x40000>; // ramdump 相关
       };

2.1核心数据结构struct msm_watchdog_data

Watchdog 的显示在 drivers/soc/qcom/watchdog_v2.c 源文件中。
  struct msm_watchdog_data {
       unsigned int __iomem phys_base; // 对应 dt 中的 reg
       size_t size;
       void __iomem *base; // 将的 phy_base 映射到虚拟地址空间
       void __iomem *wdog_absent_base;
       struct device *dev; // 指向 watchdog device
       unsigned int pet_time; // 对应 dt 中的 qcom,pet-time
       unsigned int bark_time; // 对应 dt 中的 qcom,bark-time
       unsigned int bark_irq; // 狗叫中断
       unsigned int bite_irq; // 狗咬中断
       bool do_ipi_ping; // 对应 dt 中的 qcom,ipi-ping
       bool wakeup_irq_enable; // 对应 dt 中的 qcom,wakeup-enable
       unsigned long long last_pet; // 记录上次喂狗时间
       unsigned min_slack_ticks;
<think>好的,我现在需要处理用户关于Android高通平台异常重启日志关键字的问题。首先,用户的问题集中在如何查找相关的日志关键字,特别是针对高通平台的异常重启情况。我需要结合之前提供的引用内容,尤其是引用1、2、3中的信息,同时可能还需要补充一些高通平台特有的日志关键字。 首先,用户提到的引用1主要涉及Android系统稳定性问题的日志抓取方法,比如ANR日志、墓碑日志、内核日志等。这些是通用的日志来源,但用户特别关注的是高通平台的异常重启,可能需要更具体的模块或关键字。引用2提到如何获取高通的通信日志,需要开启开发者权限和USB调试,这可能涉及到高通特定的日志工具或模块,比如QXDM或QCAT。引用3中的日志示例包含am_destroy_activity和sf_frame_dur等,虽然这些可能与Activity生命周期或SurfaceFlinger相关,但可能不是直接的高通重启关键字。 接下来,我需要思考高通平台异常重启的可能原因。异常重启可能涉及内核崩溃(如kernel panic)、硬件看门狗触发、Modem相关的问题(特别是高通平台通常处理通信模块),或者系统服务崩溃等。因此,对应的日志可能出现在不同的部分,如内核日志、系统日志、Modem日志等。 对于日志关键字,首先考虑常见的系统崩溃标识,比如"Reboot"、"Shutdown"、"Crash"、"Fatal"等。然后是高通特有的模块或工具,比如Watchdog(看门狗)触发重启,可能的关键字是"Watchdog"或"KERNEL PANIC"。此外,高通的Modem相关日志可能有特定的错误码或模块标识,比如"Subsystem crashed"或"MODEM/SSR"。 用户可能需要分步骤指导如何抓取这些日志,所以需要结合引用1中的方法,比如使用logcat抓取不同缓冲区的日志,以及adb命令获取内核日志、ANR、tombstones等。同时,引用2提到的高通商用终端看通信LOG的方法,可能需要使用QXDM工具,但用户可能没有提到这个工具,所以可能需要简要提及,但主要依赖adb命令。 另外,异常重启的日志可能出现在不同部分。例如,内核日志中的"Kernel panic"或"Watchdog bark",系统日志中的"SYSTEM_RESTART"或"CRITICAL",以及tombstones中的崩溃信息。高通的SSR(Subsystem Restart)机制相关日志可能包含"subsys-restart"或"SSR"等关键字。 需要检查用户提供的引用3中的日志是否有相关关键字,比如例子中的am_destroy_activity可能与Activity销毁有关,可能不是重启的直接原因,但如果有连续的Activity销毁后系统重启,可能需要结合其他日志分析。不过主要的关键字可能不在这个例子中。 总结需要列出的关键字可能包括: - 内核相关:Kernel panic, Watchdog, CPU crash, Hardware Error - 系统事件:SYSTEM_RESTART, BOOT_REASON, Shutdown request - 高通特定:Subsystem crashed, SSR, MODEM FATAL - 日志文件:/sys/devices/system/edac/mc/mc0/counters, /data/tombstones, last_kmsg 另外,用户可能需要知道如何获取这些日志,比如使用adb命令抓取logcat的不同缓冲区(main、system、kernel),以及获取dmesg、last_kmsg,检查tombstones目录等。同时,可能需要结合高通工具如QXDM来获取更详细的Modem日志,但用户可能更倾向于使用adb命令。 最后,需要组织这些信息,分点列出关键日志关键字和对应的抓取方法,确保用户能够逐步查找和分析。同时,生成相关问题,比如如何分析重启原因、如何抓取高通Modem日志等。</think>在Android高通平台分析异常重启问题时,需重点关注以下日志关键字及抓取方法: ### 一、关键日志关键字 1. **硬件看门狗触发** - `Watchdog bark`(看门狗计数器溢出) - `KERNEL PANIC`(内核级崩溃) - `CPU crash`(CPU异常) - `Hardware Error`(硬件错误)[^1] 2. **系统级重启标识** - `SYSTEM_RESTART`(系统主动重启) - `Shutdown request`(关机请求触发重启) - `BOOT_REASON: watchdog`(重启原因为看门狗) 3. **高通平台特有模块** - `subsys-restart`(子系统重启) - `SSR:`(SubSystem Restart事件) - `MODEM/SSR`(基带子系统崩溃) - `Subsystem crashed: modem`(Modem崩溃)[^2] 4. **内核日志关键线索** - `Fatal error detected`(致命错误) - `Unexpected IRQ trap`(异常中断) - `Unable to handle kernel paging request`(内存访问错误)[^1] ### 二、日志抓取方法 1. **内核日志** ```bash adb shell dmesg | grep -E "Watchdog|KERNEL|crash" adb pull /proc/last_kmsg # 获取上次内核崩溃日志 ``` 2. **系统事件日志** ```bash adb logcat -b events -v time | grep "boot_reason" ``` 3. **高通Modem日志** - 需通过高通工具QXDM抓取`QXDMLog`(需授权) - 通过`adb logcat`过滤高通专有标签: ```bash adb logcat | grep -E "SSR|subsys" ``` 4. **墓碑日志分析** ```bash adb pull /data/tombstones # 包含Native层崩溃堆栈 ``` 5. **系统ANR日志** ```bash adb pull /data/anr # 检查是否有关联性ANR事件[^1] ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值