Android稳定性 63篇

linux/android稳定性文章

[Android稳定性] 第022篇 [原理篇] kernel panic的死亡信息的由来 10月前查看 评论
[Android稳定性] 第022篇 [原理篇] kernel panic的死亡信息的由来

本文主要介绍了 Linux 内核稳定性问题中的“kernel panic”现象，并深入分析了其产生的原因、异常处理流程以及如何处理。文章以一个具体的异常案例为切入点，详细解释了异常信息的解读、异常向量表的查找、异常处理函数的执行过程，并最终揭示了 panic 报错信息的来源。文章还介绍了 oops_enter、console_verbose、__die、dump_backtrace 等关键函数的功能，以及 panic_on_oops 内核参数对 panic 流程的影响。通过本文的学习，读者可以更好地理解内核 panic 的产生机制，并掌握相应的调试方法。

[Android稳定性] 第021篇 [问题篇] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted 10月前查看 评论
[Android稳定性] 第021篇 [问题篇] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted

### 文章摘要 本文探讨了在Android系统中出现的一个内核崩溃问题，具体表现为`Kernel panic`错误，并深入分析了崩溃的原因。通过对内核日志和进程栈的解析，发现崩溃发生在`mi_binder_wait4_hook`函数中，由于栈帧指针`x29`发生`bitflip`错误，导致从错误的地址读取值，触发`__stack_chk_fail`函数，最终导致内核崩溃。文章详细介绍了如何通过分析汇编代码和进程栈来定位问题，并提出了可能的解决方案，即添加`nop`指令来防止`bitflip`问题。

[Android稳定性] 第020篇 [方法篇] crash实战：手把手教你使用crash分析内核dump 10月前查看 评论
[Android稳定性] 第020篇 [方法篇] crash实战：手把手教你使用crash分析内核dump

本文介绍了使用crash工具分析Linux内核崩溃（Kdump）的方法，重点针对手机领域。crash工具在处理大型dump文件时比trace32更加高效，因为它不会占用大量内存资源。文章还探讨了crash工具在恢复任务调用栈、查看局部变量值等方面的实用技巧，以及如何查找访问特定变量的线程。通过crash工具，开发者可以更有效地定位和解决内核崩溃问题，提高问题定位的效率。

[Android稳定性] 第019篇 [原理篇] QCOM 常见 reboot 类型流程梳理 10月前查看 评论
[Android稳定性] 第019篇 [原理篇] QCOM 常见 reboot 类型流程梳理

本文详细梳理了Android设备的三种重启类型：ADB重启、电源键重启（包括长按电源键直接重启和弹窗重启）以及panic重启。通过分析源代码，揭示了每种重启类型的流程，包括重启动作、事件处理、服务关闭、文件系统同步、内存清理等步骤。文章还探讨了重启前系统属性的处理流程，以及重启后如何从寄存器中获取重启原因，并传递给ABL阶段。最后，文章以高通项目为例，说明了重启流程中内核通知链的作用，以及重启后如何根据重启原因启动不同的系统模式。

[Android稳定性] 第016篇 [原理篇] 高通平台watchdog机制原理解析 10月前查看 评论
[Android稳定性] 第016篇 [原理篇] 高通平台watchdog机制原理解析

Watchdog是一种用于嵌入式系统的机制，当系统出现严重故障时，可以在无人为介入的情况下自动重新启动系统。它分为硬件和软件两种类型，硬件watchdog比软件watchdog有更好的可靠性。在高通平台Android系统中，watchdog的实现有所不同，本文主要介绍了高通平台Android系统中watchdog的种类、实现、初始化入口、通知链和主线程。

[Android稳定性] 第015篇 [问题篇] Unable to handle kernel NULL pointer dereference 11月前查看 评论
[Android稳定性] 第015篇 [问题篇] Unable to handle kernel NULL pointer dereference

系统出现死机，初步分析定位到问题为内核空指针引用，具体是在focaltech_spi模块的fts_power_usb_notifier_callback函数中。进一步通过trace32恢复现场发现，问题在于wq对象在函数执行过程中被销毁。根本原因是fts_data->ts_workqueue队列在fts_power_usb_notifier_callback执行过程中被销毁。

[Android稳定性] 第014篇 [问题篇] slab内存泄露 11月前查看 评论
[Android稳定性] 第014篇 [问题篇] slab内存泄露

**问题描述**: 系统出现Slab内存占用过高，初步分析发现`kmalloc-128`存在内存泄漏问题。日志分析显示`pd_dbg_info`函数申请内存次数远大于释放次数，怀疑存在内存泄漏。 **问题分析**: * **日志分析**: 通过分析`meminfo`和`slabinfo`日志，发现`kmalloc-128`内存占用持续增加，初步判断存在内存泄漏。 * **Slabtrace日志**: `pd_dbg_info`函数申请内存次数达到3761872，而释放函数`print_out_dwork_fn`只释放了224862次，存在大量内存未释放。 * **根本原因**: `pd_dbg_info`函数申请内存后，通过`print_out_dwork_fn`工作队列函数释放内存。由于`print_out_dwork_fn`会统计printed次数，超过`dbg_log_limit`后启动延迟队列，导致内存释放延迟，最终造成内存泄漏。 **解决方案**: * **调整`dbg_log_limit`**: 根据实际情况调整`dbg_log_limit`值，避免延迟队列启动，及时释放内存。 * **优化工作队列**: 优化`print_out_dwork_fn`工作队列，提高内存释放效率。 * **内存泄漏检测**: 使用内存泄漏检测工具，例如Valgrind，对代码进行检测和修复。 **总结**: 该问题是由于`pd_dbg_info`函数申请内存后，延迟释放导致的内存泄漏。通过调整`dbg_log_limit`、优化工作队列和进行内存泄漏检测，可以有效解决该问题。

[Android稳定性] 第013篇 [问题篇] page allocation failure: order:0内存分配失败的异常报错 11月前查看 评论
[Android稳定性] 第013篇 [问题篇] page allocation failure: order:0内存分配失败的异常报错

在工厂老化测试过程中，设备出现卡视频现象，但USB接口可以识别到ADB口。通过分析日志发现，设备频繁出现"page allocation failure"错误，且均为"order:0"，表明在分配一页大小的内存时失败。然而，系统配置中存在空闲的4KB内存，且内存分配标志为"GFP_NOWAIT|__GFP_NORETRY"，表示希望进行一个非阻塞的内存分配，而空闲的UMEH页面恰好符合这些条件。这表明内核在内存充足的情况下无法分配内存，原因可能在于erofs文件系统在执行解压缩时使用GFP_NOWAIT标签进行内存申请，减少分配page的压力，但可能存在系统内存水位线不满足要求的情况。