![[Android稳定性] 第047篇 [问题篇] Unexpected kernel BRK exception at EL1](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/06/halo_ityiau2.webp?x-oss-process=image/resize,w_800,m_lfit)
2周前
评论
[Android稳定性] 第047篇 [问题篇] Unexpected kernel BRK exception at EL1
当前文章内容已隐藏，评论后可见。
2周前
评论
【深入内核】linux ftrace详解
Ftrace（Function Tracer）是Linux内核自带的轻量级跟踪框架，用于记录内核内部事件和函数调用，帮助开发者分析系统执行路径、时序瓶颈和异常行为。Ftrace支持多种trace类型，包括function、function_graph、blk等，可以通过静态插桩和动态插桩两种方式实现。Ftrace可以通过配置内核参数和挂载debugfs文件系统来使能，并通过trace目录下的文件进行操作和管理。常见的trace event包括sched_switch、sched_wakeup、power/suspend_resume等，可以用于调试和分析系统性能和延迟问题。
![[音乐分享] 莫失莫忘](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/06/halo_giinbwi.png?x-oss-process=image/resize,w_800,m_lfit)
3周前
评论
[音乐分享] 莫失莫忘
这篇文章介绍了几个角色在夏日中的梦想与愿望，他们各自有着不同的目标和追求，有的渴望成为英雄，有的希望守护家园，还有的只想要简单快乐的生活。这些梦想充满了青春的气息和对未来的憧憬。
3周前
1 条
高通平台xbl启动流程补充
这篇文章介绍了高通Android设备在启动过程中的XBL（eXtensible Boot Loader）阶段的详细启动流程。通过流程图和日志分析的方式，对XBL阶段的执行步骤进行了逐一解读，帮助理解从SBL到ABL之后的关键启动环节。
测试评论访问功能
![[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场？](https://halo-1259291793.cos.ap-shanghai.myqcloud.com/2025/06/a1dmnee.png?imageView2/0/w/800)
3周前
评论
[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场？
这篇文章介绍了使用hansei工具解析AOP/RPM以及使用trace32恢复AOP现场的过程，包括工具的获取、安装依赖库、执行工具、恢复前的准备工作以及恢复操作。
![[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00](https://halo-1259291793.cos.ap-shanghai.myqcloud.com/2025/06/lbivwl4.png?imageView2/0/w/800)
3周前
评论
[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
在测试DDR TT和Reboot测试专项过程中，机器出现了多次dump，且dump根因相同。通过分析panic现场，发现是由于UFS初始化失败导致的。具体来说，是在`ufshcd_complete_dev_init`函数中，对`fDeviceInit`标志的轮询超时，导致无法挂载必要的分区，最终引发panic。 为了进一步定位问题，我们在`ufshcd_complete_dev_init`函数中添加了debug patch，增加了时间戳计算和日志输出。通过新的dump分析，发现异常发生在轮询`fDeviceInit`标志的过程中，时间从2.25秒突然跳到了7.15秒，中间没有日志输出，表明存在长时间阻塞。 通过trace32分析，发现一个名为`kworker/6:1`的线程出现了明显的异常，执行时间长达4386毫秒。进一步分析该线程的栈和寄存器信息，发现其最后一次执行的函数是`kfree_rcu_monitor()`，即用于回收内存的后台回调。结合CPU栈分析，发现大部分CPU都在执行串口输出相关的函数，如`qcom_geni_serial_poll_tx_done`。 综合以上分析，根本原因是UFS函数执行时被高优先级的串口输出调度出去。串口输出在持锁状态下运行，不允许调度，直到输出结束；同时，阻塞式串口写函数会主动spin等待硬件完成，长时间占用CPU，导致UFS函数无法正常执行，最终引发panic。