I’ve learned a few things about debugging suspend and Resume on Android and Linux.
Hope you can have some help, (below did not write Android special, is Linux general).
1. no_console_suspend
Add no_console_suspend to the kernel start parameter. This is essential because the kernel cannot see anything from the serial port after console suspend is disabled. Most crashes occur during suspend/ Resume and you can view the kernel Panic information through the serial port to know what is wrong. You can’t see it when resume is wrong, or suspend to console is far behind.
2. initcall_debug
You may not know which driver is suspend/resume error, so you may want to add some debugging information to see which driver is suspend/resume error. Otherwise, you may not see much useful information. The kernel already does this (though not very humanly).
Echo 1 > / sys/module/kernel/parameters/initcall_debug echo 9 > / proc/sys/kernel/printk initcall_debug the first command is open, This is common in all kernel systems. You can also use initcall_debug to enable this parameter by default.
Because these messages are at the KERN_DEBUG level, you need to raise the prinTK level to see them, otherwise you won’t be able to see them when suspend/resume dies.
3. suspend_test
This method can be used to loop suspend/resume the way software like RTC does. Although it is not sufficient for Android (you need to emulate a POWER_KEY), it is useful for debugging Driver stability. Don’t think that just because you can suspend a few times, you can pass thousands of tests. Suspend is 5 seconds to wakeup with RTC, and for Android, 5 seconds to automatically go back to sleep, but for generic Linux, you have to write a script to let it go back to sleep. Maybe this tool is useful rTCwakeup.
Usage:
Build a kernel that does this. Make menuconfig
CONFIG_PM_DEBBUG=y
CONFIG_PM_TEST_SUSPEND=y
These two options
Burn the new kernel and turn on the things you need to test, such as WIFI and 3G
echo “core” > /sys/power/pm_test
echo “mem” > /sys/power/state
This way, it will cycle to sleep and wake up.
4. wakelock
It is the turn of Android debugging, Android and Power related to the biggest is wakelock, sometimes encounter sleep, or sleep at the end of the problem, is caused by wakelock, or wakelock users caused.
How to debug, use two:
echo 15 > /sys/module/wakelock/parameters/debug_mask
echo 15 > /sys/module/userwakelock/parameters/debug_mask
15 is the hexadecimal F, and in Wakelock all debug messages are turned on, at least for now. If you run out of time, you may have to enter 255.
This allows you to see how the kernel and frameworks layers operate, apply, and release wakelock. It is ok to see whether the application and release are paired. Note: : Wakelock has a timeout value, which means that the wakelock is automatically released after how many milliseconds. For these wakelock, application and release may not be correct.
5. power.0
Sometimes you will see system suspend to the end, then power.0 suspend fails, and then the whole system resumes again. This is android specific, because power.0 is the last callback that Android registers to suspend. It checks for any wakelock before suspend. It then returns -eBUSY and causes the entire suspend to fail. The way to debug this problem is to turn on the above wakelock debug message and see which guy is applying for wakelock and then kill it.
The error message looks something like this:
pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11
PM: Device power.0 failed to suspend late: error -11
6. earlysuspend
Forget about this guy, android is another PM related big thing, can also be added:
echo 15 > /sys/module/earlysuspend/parameters/debug_mask
Print relevant debug information, such as the earlysuspend to be called, etc.
7. suspend/resume time.
Sometimes you need to debug suspend/resume too slowly. One way is to use initcall_DEBUG and type in the prinTK timestamp and see which one is slow.
But this will make your life boring 🙂
I have a patch specially used to debug this problem, but Upstream does not accept it, saying that this torture method is necessary, but you can use it if you want to use it.
Address here: www.spinics.net/lists/linux…
After installing the PATCH, select PM_DEBUG and SUSPEND_DEVICE_TIME_DEBUG in the KERNEL.
then
Echo microsecond > /sys/power/device_suspend_time_threshold
Such as
echo 50000 > /sys/power/device_suspend_time_threshold
Note that this is microseconds… It types drivers that are slow while suspend/resume and you kill them…