林渡 - 云栖梦泽

[Android稳定性] 第032篇 [原理篇] 高通平台 OCP & 组合键 Warm Reset 机制详解

本文深入探讨了Qualcomm平台Android系统中两种底层重启方式：OCP（过电流保护）触发的Warm Reset和通过组合键+Timer配置触发的Warm Reset。OCP是一种硬件保护机制，能监测供电轨是否过电流并执行Warm Reset。该重启不经过软件，重启后无last_kmsg记录。组合键+Timer配置则通过PMIC硬件监控按键状态，独立于软件，配置在Android启动后仍生效。两种重启方式均适合用于调试。

[Android稳定性] 第031篇 [原理篇] Linux内核内存检测工具KASAN

Kasan（Kernel Address Sanitizer）是一个动态检测内存错误的工具，主要功能是检查内存越界访问和使用已释放的内存等问题。Kasan集成在Linux内核中，随Linux内核代码一起发布，并由内核社区维护和发展。在Android内核开发中，Android包括内核地址排错程序(KASan)。KASan是内核与编译时修改的组合，形成了一个插桩系统，可以实现更简单的bug发现和根本原因分析。KASan可以检测内核中许多类型的内存违规行为，包括堆栈、堆和全局变量中的出界读取和写入操作，并可检测释放后再使用和双重释放错误。

[Android稳定性] 第030篇 [问题篇] I2C bus hang 导致锁线程阻塞导致卡死

本文分析了测试过程中出现的ANR问题，通过分析bugreport日志，发现大量内核线程卡在“不可中断睡眠”状态，表明线程正在等待I/O操作。进一步分析发现，问题可能出在电池/充电控制相关驱动上，因为涉及I²C通信和电源管理的模块出现异常。此外，fg_read_volt函数在I²C读失败后，会尝试重试，但可能因为互斥锁或I2C总线问题导致永久阻塞，进而引发系统内多个线程进入D状态。根本原因可能是I²C传输超时导致regmap_raw_read函数卡住或失败，进而导致fg_read_word和fg_read_volt函数卡住或多次失败，最终引发线程风暴。可能的原因包括硬件层面的I²C总线锁死、Fuel Gauge芯片异常、电池连接问题，以及软件层面的I²C驱动问题、多线程并发访问问题、I²C错误处理问题等。

[Android稳定性] 第029篇 [问题篇] 数组越界导致Unexpected kernel BRK exception at EL1

### 文章摘要在高低温测试中，两例设备死机问题指向charger模块。分析日志发现，问题源于`status_change_work`函数中的数组越界，可能与bitflip问题相关。解决方案建议增加兼容性代码，确保`cyclecount`值在0到800之间，防止异常值导致数组越界。

[Android稳定性] 第028篇 [问题篇] 可靠性滚筒测试中高概率自动关机问题记录

**摘要：** 委外实验室AS2/AS4/AS5在滚筒测试中出现自动关机问题，惠州实验室AS1、AS3无此现象。分析发现LDO7触发OCP保护导致异常。验证方案将LDO7的OCP设置从LPM模式改为NPM模式，测试结果显示问题解决。

[Android稳定性] 第027篇 [问题篇] 数组越界导致Unexpected kernel BRK exception at EL1

**摘要：** 在正常测试过程中，手机电池温度达到35度时，手机进入dump状态。问题分析显示，在`pd_policy_manager`模块的`usbpd_pm_workfunc`函数中出现了内核崩溃。进一步分析发现，`usbpd_pm_sm`函数在处理状态转换时，由于状态数组`pm_str`未包含`PD_PM_STATE_FC2_HOLD`，导致数组越界访问，引发崩溃。解决方案建议在`pm_str`数组中添加`PD_PM_STATE_FC2_HOLD`状态。

[linux内存管理] 第023篇 watermark详解

本文探讨了 Linux 内存管理中的水位机制，特别是 `zoned page frame allocator` 如何使用水位来控制内存分配和回收。文章首先介绍了 `struct zone` 结构体和三种水位 `WMARK_MIN`、`WMARK_LOW` 和 `WMARK_HIGH` 的概念及其作用。随后，文章详细分析了水位的初始化过程，包括计算 `min_free_kbytes`、更新内存区水位、刷新内存区统计阈值和初始化低内存保留等步骤。接着，文章讨论了快速分配和慢速分配中的水位检测机制，以及 `kswapd` 和内存规整过程中的水位检测。最后，文章强调了调整内存水位的重要性，以及如何根据不同业务场景进行优化。

[Android稳定性] 第026篇 [方法篇] 在windows平台安装Linux ramdump parser工具

本文介绍了在Windows环境下安装Python工具、获取Linux ramdump parser工具、编写解析脚本、编译工具链以及增加local_setting.py配置文件的过程。首先，安装Python并使用pip安装必要的库。接着，获取开源和专有的Linux ramdump parser工具并进行整合。然后，编写解析脚本并运行。此外，还需下载并整合gdb、nm和objdump工具链，最后在指定目录下增加local_setting.py文件以指定工具链路径。

[Android稳定性] 第025篇 [问题篇] KASAN slab-out-of-bounds内存越界问题

本文分析了在运行kasan版本corgi: 4967550时出现的死机问题，问题概率为4/7。通过分析dmesg日志，确定问题类型为slab-out-of-bounds，问题函数为usbpd_mi_vdm_received_cb，越界地址为ffffff808d6c0a60。通过trace32工具恢复现场，定位到死机原因为for循环中的数组越界访问。最终，通过修改循环次数为rx_msg->data_len/sizeof(u32)，成功解决问题。

[linux内存管理] 第22篇 buddy内存管理之慢速分配

**本文分析了 Linux 内核中慢速内存分配路径 `__alloc_pages_slowpath`，该路径在快速分配失败时被触发。慢速分配尝试通过多种手段获取内存，包括内存回收、内存压缩和唤醒 kswapd 线程等**。 **主要步骤如下**： 1. **判断是否允许直接回收内存**：根据 GFP 标志判断是否可以进行直接内存回收。 2. **判断是否为高成本请求**：根据请求的 order 和 migratetype 判断是否为高成本请求。 3. **尝试直接内存压缩**：在高成本请求或无法访问预留内存的情况下，尝试进行直接内存压缩。 4. **唤醒 kswapd 线程**：唤醒 kswapd 线程进行内存回收。 5. **尝试再次分配内存**：根据新的分配标志和 zonelist 尝试再次分配内存。 6. **直接内存回收**：如果允许直接回收内存，则尝试进行直接内存回收。 7. **再次尝试分配内存**：在内存回收后再次尝试分配内存。 8. **尝试内存压缩**：如果直接内存回收失败，则尝试进行内存压缩。 9. **处理 CPU 集合更新**：检查 CPU 集合是否更新，并进行相应的处理。 10. **启动 OOM 杀手**：如果所有尝试都失败，则启动 OOM 杀手进程。 11. **重试分配**：如果 OOM 杀手进程有所进展，则重试分配。 **慢速分配路径的关键在于通过各种手段增加空闲内存，以便能够成功分配请求的内存**。 **总结来说，慢速分配路径是 Linux 内核中保证内存分配可靠性的重要机制，它通过多种手段应对内存不足的情况，确保系统能够正常运行**。

你好,

我是林渡