全志H64平台ANR重启问题分析

1. 问题背景

硬件:H64 DDR-1G Nand

系统: H64 Linux-3.10 Android 5.1 64位系统

2. 问题场景

(1)测试组测试Nand机器开机90秒,开机进入桌面后的10分钟内系统卡顿严重,

        android出现anr,且这个时候nand进程占用cpu非常高.

(2)  系统安装7~8个应用,然后android mokey测试,一段时间后,发现系统卡顿严重,

        出现anr, 这个时候nand线程占用很高.

3. 问题分析

(1)从Android logcat 分析

目前Anr error log中看到anr现场nand线程负很高,

nand13进程 78%, 14% 1499/nand3进程

全志H64平台ANR重启问题分析

内核态负载过高,导致用户态进程调度资源受限,

很容易引起卡顿问题,严重情况下卡死用户态系统重要进程.

从log中看到anr最终触发了WatchdogDaemon 看门狗超时:

08-27 21:41:15.754 E/AndroidRuntime( 2260): *** FATAL EXCEPTION IN SYSTEM PROCESS: FinalizerWatchdogDaemon 
08-27 21:41:15.754 E/AndroidRuntime( 2260): java.util.concurrent.TimeoutException: android.view.ViewRootImpl$W.finalize() timed out after 10 seconds

WatchdogDaemon 随后重启了Android系统:

全志H64平台ANR重启问题分析

(2)从内核kmsg信息分析

内核打印出现如下打印时,已经说明了android出现重启:

全志H64平台ANR重启问题分析

但是重启后,紧接着发现nand驱动一直打印异常log,

目前还不清楚打印出现的问题性质, 原因和严重性,需要分析下nand

全志H64平台ANR重启问题分析

4. 工具分析

以下是通过简单的工具抓取的一些问题线索

(1) monkey测试起来后,nand负载上升很快, 基本上2~3分钟后,系统卡主

全志H64平台ANR重启问题分析

(2)通过iostat命令简单的看下,发现nand分区产生大量的读操作,

同时和一台emmc机器同一个场景下拿到数据做对比如下:

从现有的数据来看,emmc和nand读性能差异很大,

nand性能差是否很大程度上造成了nand驱动线程负载过高?

全志H64平台ANR重启问题分析

(3)针对问题2中提到的nand 在处理大量的read操作,

从系统的栈状态来看,多数进程都在等待缺页预读取cache的过程中io_schedule,

filemap_fault产生了很多的read bio操作,

但是nand驱动看起来处理不过来,导致系统长时间卡主,所以需要分析下,

是nand性能不足 还是nand驱动处理异常?

全志H64平台ANR重启问题分析

 

上一篇:java – 在不同的机器上运行bazel远程执行程序测试


下一篇:如何在Xamarin中快速集成Android版认证服务-邮箱地址篇