yqj2011的专栏

KE概念Android OS由3层组成，最底层是kernel，上面是native bin/lib，最上层是java层：任何软件都有可能发生异常，比如野指针，跑飞、死锁等等。异常发生在kernel层，我们就叫它为KE（kernel exception），同理，发生在native就是NE，java层就是JE。这篇文章仅关注底层的KE。KE类别kernel

[DESCRIPTION]MT6589T上如果使用FHD 大尺寸的LCD，应该使用xxhdpi的资源。现在系统里只有xhdpi的资源，整体显示效果都偏小。 如下：  [SOLUTION]问题的root cuae是由于系统没有指定ro.sf.lcd_density的值，则系统会根据屏幕分辨率范围，指定默认density，即320 (xhdpi)，而正确值应

内容[KEYWORDS]Flash Combo；eMMC Combo；Flash兼容[DESCRIPTION]    Flash combo可以简单分为两个部分，一个是DRAM的combo，同一份load中兼容若干颗ID/Type/Size不同的Flash，在开机过程preloader阶段，正确识别主板上使用的Flash，进行EMI时序的配置；另一种是ROM的com

异常现场：当你在SYS_KERNEL_LOG里看到如下log，那么就属于BUG at __schedule_bug一类问题了[14005.496163]-(5)[1020:AudioOut_2]BUG: scheduling while atomic: AudioOut_2/1020/0x00000002[14005.496257]-(5)[1020:AudioOut_

异常现场：当你在SYS_KERNEL_LOG里看到如下log，那么就属于BUG at __get_vm_area_node一类问题了[ 271.881362]-0)Internal error: Oops: 96000045 [#1] PREEMPT SMP......[ 280.012666]-0)PC is at __get_vm_area_node.isra.

异常现场：在__exp_main.txt和SYS_KERNEL_LOG里看到如下log：死机位置在函数dpm_wd_handler()中，是这里的BUG()触发了Exception [  341.525222] 2)PC is at dpm_wd_handler+0x2c/0x30[  328.440667] 2)[57] bus device_suspen

dpm_drv_timeout()和dpm_wd_handler()一样，请参考《BUG at dpm_wd_handler》章节

异常现场：当你在SYS_KERNEL_LOG里看到如下log，那么就属于BUG at check_bytes_and_report一类问题了：[ 492.558572]-(0)[1163:system_server]=============================================================================[ 4

异常现场：在__exp_main.txt和SYS_KERNEL_LOG里看到如下log：死机位置在函数dpm_wd_handler()中，是这里的BUG()触发了Exception [ 21.758078]-(1)[155:bat_thread_kthr]Kernel BUG at c0660080 [verbose debug info unavailable

内容[DESCRIPTION]CTS报告中反馈设备信息需要修改：默认如下：QVGA240x3202.6 - 3.0 Small screenLow density (120)  ldpiWQVGA240x400 3.2 - 3.5Normal screenLow densit

什么是Crash？   当linux系统内核发生崩溃的时候，可以通过KEXEC+KDUMP等方式收集内核崩溃之前的内存，生成一个转储文件vmcore。内核开发者通过分析该vmcore文件就可以诊断出内核崩溃的原因，从而进行操作系统的代码改进。那么Crash就是一个被广泛使用的内核崩溃转储文件分析工具。    前面讲过gdb调试方法，但gdb始终是调试native的工具，不支持ker

内容[DESCRIPTION]当kernel发生异常时，会在重启后生成对应的db，用GAT的logviewer可以解开，如果是普通的KE或HWT，并且存在SYS_MINI_RDUMP或者SYS_COREDUMP，则可以借助gdb/crash进一步debug，否则只能查看log分析问题的可能性了。 [SOLUTION]以下两个方法都需要对应的vmlinux，详

kernel space在分析KE前，你要了解kernel内存布局，才知道哪些地址用来做什么，可能会是什么问题。目前智能机已进入64bit，因此就存在32bit布局和64bit布局，下面一一讲解。ARM32bit kernel布局这是一张示意图（有些地址可能会有差异）整个地址空间是4G，kernel被配置为1G，程序占3G。任何程序都有TEXT（可执

kernel log最初学编程时，大家一定用过printf()，在kernel里有对应的函数，叫printk()。最简单的调试方法就是用printk()印出你想知道的信息了，而前面章节讲到oops/panic时，它们就通过printk()将寄存器信息/堆栈信息打印到kernel log buffer里。了解kernel log对问题的调试将非常重要，这里有专门的课程介绍，请

什么是ram console？    请参考：MediaTek On-Line> Quick Start> Deep in MTK Turnkey Solution Logging Tools系统重启时关键信息    ram console除了保持last kmsg外，还有重要的系统信息，这些非常有助于我们调试。这些信息保存在ram console的头部ram_

CPU异常捕获对于野指针、跑飞之类的异常会被MMU拦截并报告给CPU，这一系列都是硬件行为，具体请看：MediaTek On-Line> Quick Start> 深入分析Android native exception框架> 流程-异常处理在上面章节里的内核异常处理流程，有一处不同，走到arm_notify_die()后，判断是kernel mode就直接调用die()了，而

经过前面的流程，走到了die()函数，该函数主要输出便于调试的寄存器信息/堆栈信息等重要资料，我们通过log分析KE就是分析这些资料，因此要知道整个流程。die() => panic()的大致流程如下：在学习这些流程时，建议结合代码和KE的log一起看，你就知道log里那些信息在代码哪处打印出来的了。die()总流程    先从die()入手，看下die()总流程：

流程走到panic()就里死（异常重启）不远了，关键的信息已输出到kernel log。那么panic()做了什么呢？panic()流程    panic()有标志性的log输出，大致如下：因此我们也可以通过搜索关键字Kernel panic查找是否有panic发生。 panic通知链    panic()会调用栈通知链上的回调函数同

有时die()/panic()流程不一定能正常走完，可能走到某一步又发生了异常，则就形成了嵌套，这种情况，我们一般不会关注后面的异常，而是关注最开始的那个异常。    为了避免异常嵌套，在发生第2次异常时，我们就拦截下来，我们在3个地方用于拦截nested panic：do_PrefetchAbort()do_DataAbort()do_undefinstr()拦截

为什么要用ramdump？虽然debug方法有多种，但是都有其局限性。拿Logging来讲，Logging应该算是轻量级的Debug工具，并且在linux kernel默认就是打开的，在内核出现异常的时候我们可以很方便的得到下面这些信息：出现问题前的log, log时间的长度取决于编译内核时配置的log buffer的大小。问题发生时的call stack, 即当时的函数调用层次关

源码路径：             kernel-3.18/arch/arm/boot/dts/mt6580.dtsi              kernel-3.18/drivers/misc/mediatek/video/common/mtkfb.c             kernel-3.18/drivers/misc/mediatek/video/mt6580/primary