Suspend问题:
1 .不断在后台自动休眠/唤醒,而屏幕又不亮:
该问题是android上层的alarm list问题, 偶尔出现这个现象是正常的。但是如果频繁出现则有问题,找andorid engineer check下alarm list。
2.休眠后,按唤醒源没有任何反应,一句log都没有输出:
这个问题往往是唤醒源不对,即新增的唤醒源没有加入唤醒源中,致使系统无法唤醒。还有就是检查32k晶振是否起振。如果起振,各路电是否按预期恢复了。
3.待机唤醒缓慢:
首先查看下kernel log,查看哪个driver在resume的时候用的时间过多。其次,关闭kernel log可以省掉0.5s resume时间。
4.resume唤醒后在亮屏后或者接近亮屏后死机,这个很多时候和wifi有关。请关闭wifi进行排除煲机。
5.suspend过程中死机,并且连ICE无法stop。
这个原因往往是某个模块在suspend时候gate off后,其它模块由于中断或者什么原因又去访问该模块资源,造成死机,这个一般发生在多媒体部分,如VPU这类的很多模块在共用资源的时候发生。
6.Resume的log停在”restart arm”后就没了,往往也是ddr的问题,需要检查ddr1.5v和ddr自身的稳定性。
Reboot问题
1.随机死机在kernel的启动过程中:
a)分析异常log看是否能找出原因,如果没有异常log打出,则连上ICE去dump log: info os-log。
b)测量死机现场的各路电是否正常,包括vcck,AO_EE,ddr1.5, 3.3v。防止发生PMU引起的跌落问题。如果是瞬间跌落又恢复了当然看不到。
c)排除vcck问题,通过vcck的动态调压表格把vcck定在最高值,并进行reboot煲机,如果不死后,则需要重新调整vcck表格。
d)排除ddr稳定性,可以降频DDR试试,并查看DDR纹波。
e)特定平台出现随机死机,且以上条目都排除后,则需要排查pll patch问题(针对M8/M8baby)。确保该patch已经打入。
2.偶尔死在uboot中,出现ucl解压失败。
该问题一般是ddr问题。
3.reboot准备关机的时候死机
这个问题往往和一些driver的shut_off的call back有关,需要注意log的位置或者连ICE,一般能看到我们想要的信息。
我们需要#define CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART这个config来看更多reboot前的log信息。但是打开这个config也会有一定的风险,会出现console的输出清理死锁问题。#define CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART这个config是否打开,包括defconfig的和code中的两个地方。
关于watchdog开关问题
3.10:
amlogic-watchdog{
compatible = "amlogic,aml-wdt";
status = "okay";
one-second=<0x100000>;
min_timeout=<1>;
max_timeout=<41>;
default_timeout=<5>;
reset_watchdog_method=<1>;//0:sysfs,1:kernel
reset_watchdog_time=<2>;
shutdown_timeout=<10>;
};
status = "okay"; "okay" :enable this driver,"disable":disable this driver 默认 disable
one-second=<0x100000>; watch dog 计时1s 的count 数目。
min_timeout=<1>; watch dog 的最小超时时间
max_timeout=<41>;watch dog 的最大超时时间
default_timeout=<5>;watch dog 默认超时时间
reset_watchdog_method=<1>;//0:sysfs,1:kernel 选择 通过上层喂狗还是kernel 喂狗
reset_watchdog_time=<2>; kernel喂狗的时间间隔
shutdown_timeout=<10>;关机的时候 设置watch dog 超时时间
目前aml watch dog 属于硬件watch dog覆盖的死机种类(kernel 喂狗的方式):
硬件死机:
1 Unable to handle kernel NULL pointer dereference at virtual address 00000000
测试方法:
int *p=NULL;
*p=2;
2 硬件死机,例如bus上的死机。
软件死机 硬件watch dog 无法覆盖,可以打开kernel的相关宏,可以解决部分软件死机的状况:
1 spin_lock 死锁:
CONFIG_LOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_PANIC_TIMEOUT=2
如果发生 spin_lock 死锁,系统20s 后dump stack 2秒后重启系统。
2 mutex 死锁 ,kernel 空间的while(1) 死循环
CONFIG_DETECT_HUNG_TASK=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_PANIC_TIMEOUT=2
120 秒后dump stack 2秒后重启系统
对于kernel,只是多开了几个线程,安兔兔 实测 对跑分没有影响。
3.0 boot moniter
CONFIG_BOOT_MONITOR=y 即可