![[Android稳定性] 第61篇 UFS异常导致卡开机logo](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/08/halo_bc7ukwe.jpg?x-oss-process=style/watermark&x-oss-process=image/resize,w_800,m_lfit)
1周前
[Android稳定性] 第61篇 UFS异常导致卡开机logo
高通平台项目在工厂老化测试中出现卡开机logo的棘手问题，设备无法通过USB或串口获取有效日志，通过强制fulldump分析发现，系统init进程自开机五秒后便持续处于D状态，导致系统无法正常启动。内核堆栈显示进程在等待PG_locked时失败，疑似死锁或关键进程卡死，经进一步排查，平台迅速定位UFS存储异常——UFS设备自开机五秒后未再触发中断。文章详解了如何从核心结构体如ufs_stats、ufs_hba入手，追溯设备树节点至具体驱动，指导工程师在dump文件中精确定位存储异常发生时间及其相关数据。通过系统性分析，为后续UFS问题跟进提供了清晰的技术路径和实际操作指引，展现了严谨的问题排查步骤。
2周前
Linux 中断线程化
文章深入解析Linux中断线程化机制及核心实现，详细讲解了struct irqaction结构体、关键flag如IRQF_ONESHOT和IRQTF_RUNTHREAD的作用，剖析了request_threaded_irq函数的注册流程及__setup_irq的内部逻辑。重点强调线程化中断带来的实时性保证和中断线屏蔽原理，具有丰富代码注释与流程分析，对理解内核中断管理与设备驱动开发极具参考价值
![[linux内存管理] 第029篇 谁把folio的函数定义“藏”起来了？](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/08/halo_lwibxfi.jpg?x-oss-process=style/watermark&x-oss-process=image/resize,w_800,m_lfit)
5月前
[linux内存管理] 第029篇 谁把folio的函数定义“藏”起来了？
这篇文章探讨了在阅读Linux内核代码时，如何解决一些函数定义难以找到的问题。作者遇到了folio_test_active()等函数无法找到定义的困惑，通过搜索发现这些函数是通过特殊的宏定义在page-flags.h文件中创建的。文章详细解释了PAGE_TYPE_OPS()和FOLIO_FLAG()宏的工作原理，以及如何通过这些宏定义函数。最终，作者成功理解了这些函数的定义方式，并总结说这种方法虽然特殊，但探索和理解的过程非常有意思。
![[linux内存管理] 第028篇 do_anonymous_page只处理私有映射吗?](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/08/halo_woensf8.jpg?x-oss-process=style/watermark&x-oss-process=image/resize,w_800,m_lfit)
6月前
[linux内存管理] 第028篇 do_anonymous_page只处理私有映射吗?
文章摘要：本文探讨了Linux内核中do_anonymous_page()函数的作用，解释了它为什么只处理私有匿名映射。通过分析do_pte_missing()、vma_is_anonymous()、vma_set_anonymous()等函数，以及mmap_region()函数中的逻辑，文章得出结论：在mmap()流程中，只有私有匿名映射的vm_ops会被设置为NULL，从而被do_anonymous_page()处理。其他类型的映射，如共享匿名映射和文件映射，其vm_ops不为空，因此不会被该函数处理。
![[Android稳定性] 第056篇 [问题篇] 记一例Kernel panic - not syncing: Attempted to kill init!](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/08/halo_nkcbuym.png?x-oss-process=style/watermark&x-oss-process=image/resize,w_800,m_lfit)
6月前
[Android稳定性] 第056篇 [问题篇] 记一例Kernel panic - not syncing: Attempted to kill init!
**问题现场**：系统出现大量I/O和read ERROR，初步怀疑与storage访问相关，进一步分析发现系统正在进行shutdown流程。 **初步分析**：系统当时正在走低电关机流程，且尝试访问磁盘数据时出现IO ERROR，怀疑是下电时序导致storage先下电，导致上层进程访问失败。 **平台回复**：charger相关函数检测到低电后直接调用kernel_power_off执行下电关机，跳过上层shutdown流程，导致上层访问存储设备失败，引发异常。 **解决方法**：删除底层shutdown操作，先走上层关机流程，避免问题发生。 **代码浅析**：正常情况下，上层先走完shutdown流程，再通过syscall让底层继续shutdown。 **补充**：在系统下电流程中，做好时序上的同步非常重要，避免出现竞态访问导致异常。
