Debug Android and Linux suspend and resume （中文）

最新推荐文章于 2024-10-18 15:21:27 发布

tron

最新推荐文章于 2024-10-18 15:21:27 发布

阅读量713

点赞数

分类专栏： android power专题文章标签： android linux frameworks patch 测试 google

android power专题专栏收录该内容

18 篇文章

订阅专栏

本文分享了调试Android和Linux下suspend和resume的经验，包括使用no_console_suspend避免失去控制台输出、利用initcall_debug和printk调整调试信息级别、通过suspend_test进行循环测试、借助wakelock和power.0解决睡眠问题、启用earlysuspend debug信息及优化suspend时间。

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

攒了一些关于调试Android和Linux下面的suspend 和 resume的经验，在这里和大家分享一下。

希望可以有些帮助，（下面没有写Android专用的，就是Linux通用的）。

1. no_console_suspend

在kernel启动参数里面加上no_console_suspend，这个是最基本的，因为kernel在把console suspend掉以后，不管里面出了什么事情，从串口上都看不到。大部分在suspend/resume时候的死机都可以通过串口看到kernel Panic的信息，这样才会知道是哪里出了问题。因为有的时候resume出错，或者suspend到很后面出错的console不加这个参数都看不到。

2. initcall_debug

这个也许知道的人不多，其实有的时候你不知道哪个driver在suspend/resume的时候出错的时候，很迷茫，就想在哪里加上一些调试信息来看看是哪里的driver，其实有些时候加的不合适的话，会看不到很多有用的信息。其实kernel本身已经有这样的功能了（只不过不是很人性化）。

echo 1 > /sys/module/kernel/parameters/initcall_debug echo 9 > /proc/sys/kernel/printk

第一条命令是打开initcall_debug，这个是所有的kernel都会有的，也可以在启动参数里面加initcall_debug来默认打开这个参数，这样可以调试系统启动。

因为这些信息都是KERN_DEBUG级别的，所以需要提高printk的级别才可以看到，要不然suspend/resume的时候死掉了，你就没有机会看到这些信息了。

3. suspend_test

这个方法可以用rtc这种软件的方式来做循环的suspend/resume，尽管对于Android这样并不是很足够，（你得模拟一个POWER_KEY上去才够），但是对于调试Driver的稳定性，还是有一定用处的。不要以为suspend了几次可以，那么就可以通过几千次的测试。这个suspend是5秒钟用RTC唤醒，然后对于Android, 5秒钟又会自动睡下去，但是对于通用Linux，你得写个小脚本来让他一会再睡下去，或许这个工具比较有用rtcwakeup（google rtcwakeup)。

使用方法：

编译一个有这个功能的kernel， make menuconfig 以后选上

CONFIG_PM_DEBBUG=y

CONFIG_PM_TEST_SUSPEND=y

这两个选项

烧写新的kernel，然后打开你需要测试的东东，比如WIFI，3G

echo "core" > /sys/power/pm_test

echo "mem" > /sys/power/state

这样，它就会循环休眠和唤醒了。

4. wakelock

轮到Android的调试了， Android里面和Power相关最大的就是wakelock, 有时候会碰到睡不下去，或者睡到最后弹起来的问题，就是wakelock引起的，或者说是wakelock的使用者引起的。

怎么调试呢，用一下两个：

echo 15 > /sys/module/wakelock/parameters/debug_mask

echo 15 > /sys/module/userwakelock/parameters/debug_mask

15是代表16进制的F，在wakelock里面就是把所有的debug信息打开，起码现在是。如果以后不够了，估计得输入255.

这样你能看到kernel和frameworks层对于wakelock的操作，申请和释放。这样看申请和释放成对否就可以了。注意： wakelock有一种是timeout的，就是说多少毫秒以后，会自动释放，对于这些wakelock，申请和释放可能是不成对的。。

5. power.0

有的时候你会看到系统suspend到了最后，然后遇到power.0 suspend失败，然后整个系统都又resume起来了。这个是android专有的，因为power.0是android注册到suspend最后的一个回调，它会在CPU进入suspend之前检查一下有没有wakelock，如果这时候还有没有释放的wakelock，那么它会返回-EBUSY然后导致整个suspend失败。调试这个问题的方法就是把上面wakelock的debug信息打开，然后看看是哪个家伙去申请了wakelock，然后干掉它。

这个错误的错误信息大概是这样的：