Directory
1: Introduction
2: How to crawl and analyze log
3: How to determine the problem point
Introduction system stability is mainly to solve the system crash restart. There are two parts: Android/kernel kernel analysis required files and tools: Mtklog, Vmlinux, GAT tools, parsing vmlinux scripts.
Vmlinux Path: alps\out\target\product\k55v1_64_op01_pre\obj\kernel_obj
Parsing the Vmlinux script
ARM 32-bit version: prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/
ARM 64-bit version: prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/
Log crawl
1: If the normal boot, through the *#* #3646633 #*#* crawl Mtklog, the exception will be generated when the folder aee**, such as
2: If the boot is not normal, you need to crawl serial log. In addition, the default is to open the serial port, you can modify the code:
Alps\kernel-3.10\drivers\misc\mediatek\mtprof\mt_printk_ctrl.c
NT Mt_need_uart_console = 0;->1
3: If the ADB can be normal, but cannot drive, you can use the ADB command to crawl the relevant log. USR version can only crawl Logcat
Identify problem points
Case 1: Can boot up and die on some interfaces.
----This situation, there are several steps: Press the Power key first to see if you can wake up normally. If the power key reacts, then plug in the USB to see if the ADB can be detected normally, if the ADB can be detected normally, it can be seen through the ADB shell getevent whether the TP driver has no reporting point.
Case 2 Boot Card dead, press power key did not respond.
----need to crawl mtklog to see if there is a log folder to generate AEE, some words need to be resolved by GAT tool. Steps are as follows: 1: computer-side Open application Gat-linux-x86_64-3.1501.1.c\gat-linux-x86_64-3\modules\mediateklogview\mediateklogview
2: Open the AEE directory inside the file, such as "db.fatal.06.ke.dbg", can be directly dragged in.
Case 3 does not boot, you need to crawl serial log analysis.
Simple analysis steps: 1: Crawl serial LOG[MTK baud rate needs to be set to 921600]
2: Confirm that the PC pointer refers to the specific function and the specific function
In Alps/prebuilts/gcc/linux-x86/aarch64-linux-anroid-4.9/bin$./aarch64-linux-android-addr2line-e Vmlinux-f-C 0xffffffc0009f62a4
Identify specific files and line numbers
Alps/prebuilts/gcc/linux-x86/aarch64-linux-anroid-4.9/bin$./aarch64-linux-android-objdump-d Vmlinux
3: Sometimes kernel see the exception, but not necessarily is the kernel problem, it is possible that the top of the initiative to send a reboot, such as the command, can be seen in the log similar printing:
Case 4:watchdog Timeout
Case 5 HW reboot
Hardware reboot Genesis: MT6592 platform Chip has a external watch dog, the software every 30 seconds to kick, if not kicked, will trigger the software watch dog timeout restart;
If the software has a time limit (30 seconds) to kick this external watch dog, but for hardware reasons, external watch dog is not kicked in time, then this external watch dog will wait up to 60 seconds, After 60 seconds, the hardware reboot will be triggered directly, which is called hardware reboot
As for what hardware causes can not be mentioned in time external Watch Dog, the most common one is bus hang, such as unreasonable read and write registers will cause bus hang, and some are hardware design unreasonable, or hardware failure caused the machine to die, Or some hardware device instability, resulting in hardware reboot if the read-write register caused the bus hang, and then trigger hardware reboot, generally in the last PC and last kmsg will be reflected in, Every time the last PC or the last print out a few of the logs are the same or similar if the hardware is unreasonable or hardware failure or hardware instability, this in the end of the PC and finally kmsg there is no regularity, this case, is generally compared to the previous project, see Before the project has appeared? If the previous project is stable, and now the project has hardware reboot, then compare the previous project with the current project on the hardware differences, and then through the hardware experiment to clarify the problem
Stability analysis of MTK platform system