云栖梦泽
林渡
Blog
  • 首页
  • 我的视界
    • 人世间
      • 世间风声
      • 人间烟火
    • 壹句话
    • 云外光影
      • 动物与植物
      • 美食
      • 生活气息
      • 人物
    • 文章归档
      • 技术分享
      • 视频类型
      • 音频类型
      • 图文类型
      • 图片类型
  • 「内核宇宙」
    • 灵感工坊
      • 灵感风暴
      • 与AI共生
      • 开源项目推荐
    • 底层漫游
      • Android稳定性
      • Linux内存管理
      • Linux进程调度
      • Linux内核
      • ARM体系架构
      • LRDP2
      • 技术分享
  • 璀璨星河
    • 公告
    • 轻言
    • 应用舱
    • 众星
    • 豆瓣
    • 足迹
    • 走心评论
    • 林渡的网盘
  • 留言板
  • 关于
    • 捐赠者名单
    • 关于我
    • 一些声明
      • 站点声明
      • 隐私政策
    • 网站看板
  • 欢迎订阅!

欢迎来到云栖梦泽,为您导读全站动态
  • 路人甲不掉线 6小时前前留言 bringup 阶段把 SELinux 直接设成 permissive 然后还遇到 kernel panic,这种情况我之前也踩过,不过当时没想到会是 zram 驱动的问题。文中这条时间线很关键:uzram.ko 加载 -> zram0 容量变化 -> mkswap 调用 -> UBSAN 报错,把现场还原得很清楚。感觉以后排查类似问题,先看 UBSAN 日志 + 反汇编,比盲目改代码稳多了。能不能顺便分享下你那个 kernel-panic-killer 工具的大致实现?
  • 林渡 6日前前留言 不好意思哈,公司使用的,不开源
  • jxc 1周前前留言 请问可以开源吗?
  • 林渡 1周前前留言 我用的是chatgpt-image-2制作的封面图
  • 林渡 2周前前留言 哈哈,谢谢你们!
  • TTT 3周前前留言 11111,有人看,每分每刻。
  • TTT 2026-06-10前留言 感谢分享😚
  • 林渡 2026-06-08前留言 Hi,这个涉及到我司客户的设计方案,只对我司内部员工开放
  • 狗黄他满满 2026-06-02前留言 请问这个可以看嘛😁
  • 林渡 2026-06-01前留言 用 gpt image 2绘制的
2026 年 7 月
日一二三四五六
1234
567891011
12131415161718
19202122232425
262728293031
« 6 月  
最近文章
  • 2026-07-15 [linux内存管理] 第 047 篇 Linux 内存回收(Memory Reclaim)总体架构
  • 2026-07-11 [Android稳定性] 第65篇 SELinux 设置为 permissive 模式后出现的 kernel panic
  • 2026-07-03 再看《孩子王》观后感:当AI成为每个人的“字典”之后
  • 2026-06-01 [Android稳定性] 第64篇 blk_mq_tags Use-After-Free 导致系统级 I/O 死锁
  • 2026-06-01 [Android稳定性] 第63篇 EROFS 解压缩页面 Use-After-Free 导致 Kernel Panic
  • 2026-05-06 [开源项目] GitNexus + Claude Code 配置与使用指南
  • 2026-04-10 [linux内存管理] 第046篇 Page Cache脏页回写机制深入分析
  • 2026-04-01 AI时代笔记工作流:构建下一代知识管理引擎
  • 2026-03-24 认知加速度:AI时代最残酷的鸿沟,正在此刻拉开
  • 2026-03-20 Linux 内核崩溃分析报告 - AI
  • 2026-03-11 AI时代的思考:内核稳定性工程师离失业还有多久?
  • 2026-03-06 [linux内存管理] 第045篇 per-CPU变量的静态与动态分配
  • 2026-03-04 [linux内存管理] 第044篇 per-CPU基础知识以及per-CPU分配器的初始化
  • 2026-03-02 [Android稳定性] 第62篇 内核访问与tee共享的内存数据异常造成内存越界
  • 2026-02-28 [LRDP2] 解析插件之logcat
  • 2026-02-26 [linux内存管理] 第043篇 page cache 脏页跟踪机制
  • 2026-02-26 向 Linux 内核社区提交 patch 实操要点
  • 2026-02-06 基于 QEMU 与 VSCode 的 Linux 内核调试环境搭建指南
  • 2026-02-06 「纵朝生暮死,亦当惊鸿」
  • 2026-02-04 [linux内存管理] 第042篇 Linux内核Page Cache机制深入分析
热门文章
  • 2024-11-22 高通android启动代码流程分析(SBL->ABL)
  • 2026-01-29 📢 致读者的一封信:关于运营、初心与一份邀请
  • 2026-05-06 [开源项目] GitNexus + Claude Code 配置与使用指南
  • 2024-12-15 [Android稳定性] 第000篇 Android稳定性系列开篇
  • 2025-07-21 高通以及MTK平台内核单独编译ko的原理
  • 2025-08-27 [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区
  • 2025-09-04 琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证
  • 2025-07-10 [Linux进程调度] 第001篇 一篇文章全面了解Linux进程调度
  • 2026-01-08 【深入内核】中断真的不能睡眠吗?
  • 2025-06-25 [Android稳定性] 第052篇 [方法篇] HMI项目中如何使用QCAP解析minidump?
  • 2025-06-18 [linux内存管理] 第027篇 Linux ARM64 虚拟地址布局
  • 2024-12-15 [Android稳定性] 第001篇 [方法篇] 高通Android平台稳定性分析介绍
  • 2025-01-14 [Android稳定性] 第017篇 [方法篇] 高通watchdog分析流程
  • 2025-11-03 [linux内存管理] 第000篇 Linux内存管理系列开篇
  • 2025-06-09 【深入内核】linux ftrace详解
  • 2024-11-29 [linux内存管理] 第009篇 reserved-memory详解
  • 2024-12-18 [Android稳定性] 第004篇 [原理篇] minidump的原理介绍
  • 2025-10-23 利用 Claude Code 探索 Linux 内核奥秘
  • 2025-06-16 [Android稳定性] 第049篇 [问题篇] 软中断霸占CPU导致watchdog无法及时喂狗
  • 2025-08-05 [Android稳定性] 第057篇 [方法篇] 高通平台使能ftrace的方法
热门标签
  • 内核线程 1
  • 价值观 1
  • 内核开发 3
  • 生产力工具 1
  • Linux内核 12
  • init进程 1
  • 理想与现实 1
  • 人生态度 1
  • 人生意义 1
  • 精神追求 1
  • 性能优化 1
  • 生活美学 1
  • 内核栈 1
  • 任务优先级 0
  • 反思 1
  • 个人成长 1
  • 时间管理 1
  • 自我认知 1
  • 烟火气 1
  • 任务管理 1
  • Static Keys 1
  • 进程调度 1
  • 动态分支 1
  • 寄存器 1
  • idle进程 1
  • 高效工作 1
  • 页面管理 1
  • minidump 3
  • kmalloc 2
  • 脏页 2
74843° 194 15 275
当您评论及浏览文章且浏览器未禁止COOKIE时,会为您显示最近10条回复及前20篇文章的浏览记录。
在万物之间穿行,也在自我之间渡过。

你好,
我是林渡

    • 4周前

      想通了,工具是我的,能力是我的,公司只是一段时间的甲方。

    • 2026-06-03

      太痛了😭

    • 2026-05-15

      我爱白嫖!

    • 2026-04-20

      这段时间我写博文的速度也慢下来了,因为我在思考,思考在这个AI时代下技术博客还有没有必要存在? 从我个人角度来说,我其实也不愿意看那些长篇大论的技术文章,也是随手丢给 AI 看一眼,让它帮我总结提炼出关键!而我遇到的那些坑,其实 AI 也比我更加的懂,更加的全面,那我还有必要写嘛?

    • 查看更多瞬间动态
  • [灵感风暴] Charger Property Engine 设计方案 2025-12-23 评论 林渡
      灵感风暴
      自适应刷新
    [灵感风暴] Charger Property Engine 设计方案

    聚焦智能设备BMS中I2C通信瓶颈,提出结合属性缓存与自适应刷新机制的创新方案,通过缓存属性并动态调整TTL,有效减少I2C访问冲突和通信负担。自适应算法根据属性变化及噪声门限、窗口振幅智能控制刷新频率,提升系统实时性与稳定性,同时引入并发控制与总线熔断机制,确保关键数据高效、安全传输。

    [linux内存管理] 第034篇 slab内存分配器之kmalloc全面详解 2025-12-16 1 条 林渡
      Linux内存管理
    [linux内存管理] 第034篇 slab内存分配器之kmalloc全面详解

    深入解析Linux内核中kmalloc的内存池体系,详解其在高效分配小至中等连续物理内存块中的核心作用。文章重点说明kmalloc通过预先创建多种尺寸的slab内存池,有效应对频繁的通用及专属内存分配需求,并结合源码分析创建流程、类型划分及对应场景,帮助开发者理解内核内存分配机制的高效性与灵活性。

    [linux内存管理] 第033篇 深度解析 slab 内存池回收内存以及销毁全流程 2025-12-16 1 条 林渡
      Linux内存管理
    [linux内存管理] 第033篇 深度解析 slab 内存池回收内存以及销毁全流程

    copyright_author: bin的技术小屋 copyright_author_href:

    [linux内存管理] 第032篇 使用trace32分析slab cache 2025-12-11 评论 林渡
      Android稳定性
      slabtrace32
    [linux内存管理] 第032篇 使用trace32分析slab cache

    以实际dump为例,文章用trace32深入解析了Linux slab cache的内部逻辑,带你逐层解读kmalloc-64实例中的数据结构,从kmalloc_caches和kmem_cache到per-CPU区与节点node的内存组织和管理特性。

    [linux内存管理] 第031篇 内核启动早期的slab分配器的自举 2025-12-09 5 条 林渡
      Linux内存管理
      slabbootstrap
    [linux内存管理] 第031篇 内核启动早期的slab分配器的自举

    梳理Linux内核启动早期内存管理的四个阶段,文章深入分析了slab分配器自举的“鸡生蛋”难题:分配器本身依赖尚未初始化的自身结构体。详细解读slab分配器如何通过静态变量及多层自举逻辑,巧妙解决这一循环依赖困境,进而实现对象级缓存的高效分配与初始化,为内核后续稳定运行打下坚实基础。

    [linux内存管理] 第030篇 深入理解 slab cache 内存分配全链路实现 2025-11-17 评论 林渡
      Linux内存管理
      内核开发内存分配slab
    [linux内存管理] 第030篇 深入理解 slab cache 内存分配全链路实现

    通过内核源码深入解析slab cache的内存分配机制,文章以task_struct为例详解fastpath和slowpath的分配流程,阐释了kmem_cache在多CPU和NUMA架构下的高效对象分配策略,以及如何通过本地CPU缓存、空闲对象链和慢速路径保证性能和并发安全。

    [Android稳定性] 第060篇 [问题篇] storage corruption导致的死机 2025-11-07 评论 林渡
      Android稳定性
      存储损坏
    [Android稳定性] 第060篇 [问题篇] storage corruption导致的死机

    一台售后机器频繁重启,日志分析定位到kernel在同一代码处异常crash,且product分区未损坏。无论刷super单镜像还是整包软件,问题都复现,确认是存储损坏(storage corruption)导致。后续将通过UFS交叉验证和检测,进一步排查硬件问题,以寻找更深层次故障原因。

    [Android稳定性] 第059篇 [问题篇] 内核内存区域重叠导致的页表映射错误 2025-10-30 3 条 林渡
      Android稳定性
      内存管理页表映射phys_to_virtioremap
    [Android稳定性] 第059篇 [问题篇] 内核内存区域重叠导致的页表映射错误

    基线升级后引入高通baseline代码导致设备在重启时死机,问题定位至内核mtdoops_do_dump模块。通过dmesg日志和trace32调试发现,关键内存地址pte为空,导致系统在访问p_hdr结构时出现页表异常。分析详细还原故障场景,为后续修复提供技术依据,展示了系统性排查和调试过程的专业

    [Android稳定性] 第059篇 [问题篇] 内核内存区域重叠导致的页表映射错误
    查看完整文章 评论

    问题背景

    1. 在一次基线升级后(引入高通baseline的代码),开机重启会进入死机模式

    2. 基线升级前的软件没有问题

    问题分析

    dmesg日志分析

    [  397.719194][    T1] mtdoops: mtdoops_do_dump start , count = 279 , page = 6, reason = 5, dump_count = 1
    [  397.733201][    T1] mtdoops: mtdoops_do_dump pmsg paddr = 0x000000000677a9c7 
    [  397.733228][    T1] Unable to handle kernel paging request at virtual address ffffff8000e00000
    [  397.733234][    T1] Mem abort info:
    [  397.733240][    T1]   ESR = 0x0000000096000007
    [  397.733246][    T1]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  397.733253][    T1]   SET = 0, FnV = 0
    [  397.733260][    T1]   EA = 0, S1PTW = 0
    [  397.733265][    T1]   FSC = 0x07: level 3 translation fault
    [  397.733271][    T1] Data abort info:
    [  397.733276][    T1]   ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
    [  397.733283][    T1]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [  397.733289][    T1]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [  397.733295][    T1] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000a9c9f000
    [  397.733302][    T1] [ffffff8000e00000] pgd=180000097ff78003, p4d=180000097ff78003, pud=180000097ff78003, pmd=180000097ff73003, pte=0000000000000000
    [  397.733323][    T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP
    [  397.734277][    T1] Hardware name: Qualcomm Technologies, Inc. Kunzite QRD (DT)
    [  397.734283][    T1] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  397.734291][    T1] pc : mtdoops_do_dump+0x1a0/0x2cc [mtdoops]
    [  397.734323][    T1] lr : mtdoops_do_dump+0x1a0/0x2cc [mtdoops]
    [  397.734351][    T1] sp : ffffffc0823abba0
    [  397.734358][    T1] x29: ffffffc0823abbc0 x28: ffffff883b9c8000 x27: ffffff879a608c20
    [  397.734370][    T1] x26: ffffffc082262000 x25: ffffff883b9c8000 x24: ffffffc0820bae18
    [  397.734382][    T1] x23: ffffffc07c898000 x22: 0000000000000001 x21: ffffffc0823abcd8
    [  397.734393][    T1] x20: ffffffc07c8981a8 x19: ffffff8000e00000 x18: ffffffc082389058
    [  397.734404][    T1] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000004
    [  397.734415][    T1] x14: ffffff88f5300000 x13: 0000000000000003 x12: 0000000000000003
    [  397.734426][    T1] x11: 00000000fffeffff x10: c0000000fffeffff x9 : c92068df22ab7800
    [  397.734438][    T1] x8 : c92068df22ab7800 x7 : 205b5d3130323333 x6 : 372e37393320205b
    [  397.734449][    T1] x5 : ffffffc0822e579f x4 : ffffffc081580cfc x3 : 0000000000000000
    [  397.734460][    T1] x2 : 0000000000000000 x1 : ffffffc0823ab950 x0 : 0000000000000039
    [  397.734471][    T1] Call trace:
    [  397.734478][    T1]  mtdoops_do_dump+0x1a0/0x2cc [mtdoops 0e68315fd17942ad7985f5125ce422a1f47288bf]
    [  397.734517][    T1]  mtdoops_reboot_nb_handle+0x2c/0x40 [mtdoops 0e68315fd17942ad7985f5125ce422a1f47288bf]
    [  397.734534][    T1]  notifier_call_chain+0x90/0x174
    [  397.734549][    T1]  blocking_notifier_call_chain+0x48/0x78
    [  397.734559][    T1]  kernel_restart+0x28/0x114
    [  397.734570][    T1]  __arm64_sys_reboot+0x1b0/0x288
    [  397.734580][    T1]  invoke_syscall+0x58/0x114
    [  397.734593][    T1]  el0_svc_common+0xac/0xe0
    [  397.734603][    T1]  do_el0_svc+0x1c/0x28
    [  397.734613][    T1]  el0_svc+0x38/0x68
    [  397.734625][    T1]  el0t_64_sync_handler+0x68/0xbc
    [  397.734635][    T1]  el0t_64_sync+0x1a8/0x1ac
    [  397.734645][    T1] Code: cb080128 b2596113 aa1303e1 951e72aa (b9400261) 
    [  397.734652][    T1] ---[ end trace 0000000000000000 ]---

    我们可以确定的是代码死在了mtdoops_do_dump+0x1a0

    trace32恢复现场

    PC位于B9400261处,这儿的ldr w1,[x19]

    这里的x19也就是p_hdr的地址

    而这个地址从dmesg中可以看到pte为空

    [  397.733302][    T1] [ffffff8000e00000] pgd=180000097ff78003, p4d=180000097ff78003, pud=180000097ff78003, pmd=180000097ff73003, pte=0000000000000000

    级别

    值

    状态

    说明

    PGD

    180000097ff78003

    ✅ 有效

    页全局目录项有效

    P4D

    180000097ff78003

    ✅ 有效

    四级目录项有效

    PUD

    180000097ff78003

    ✅ 有效

    页上层目录项有效

    PMD

    180000097ff73003

    ✅ 有效

    页中间目录项有效

    PTE

    0000000000000000

    ❌ 无效

    页表项为空

    在ARM64页表机制中:

    • PTE为0表示该页表项为空

    • 没有建立虚拟地址到物理地址的映射

    这点也可以用trace32查询该地址得到:

    代码追踪

    我们需要得到p_hdr的由来,查看他是否经过了映射!

    static void mtdoops_do_dump(struct kmsg_dumper *dumper,
    			    enum mtd_dump_reason reason)
    {
    //...
    	pmsg_buffer_start = phys_to_virt(
    		(cxt->pmsg_data.mem_address + cxt->pmsg_data.mem_size)-
    		cxt->pmsg_data.pmsg_size);
    
    	p_hdr = (struct pmsg_buffer_hdr *)pmsg_buffer_start;
    	pr_err("mtdoops_do_dump pmsg paddr = 0x%p \n",
    			pmsg_buffer_start);
    //...

    从代码里我们可以看到p_hdr结构体pmsg_buffer_hdr指针,指向pmsg_buffer_start

    而pmsg_buffer_start是通过phys_to_virt将cxt->pmsg_data.mem_address转换成虚拟地址后,经过计算得来

    static int mtdoops_pmsg_probe(struct platform_device *pdev)
    {
    	struct mtdoops_context *cxt = &oops_cxt;
    	struct resource *res;
    	u32 value;
    	int ret;
    
    	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    	if (!res) {
    		pr_err("failed to locate DT /reserved-memory resource\n");
    		return -EINVAL;
    	}
    	cxt->pmsg_data.mem_size = resource_size(res);
    	cxt->pmsg_data.mem_address = res->start;
    
    	pr_err( "pares mtd_dt, mem_address =0x%llx, mem_size =0x%lx \n",
    			cxt->pmsg_data.mem_address, cxt->pmsg_data.mem_size);
    	pr_err( "pares mtd_dt, pmsg_size =0x%lx, console-size =0x%lx \n",
    			cxt->pmsg_data.pmsg_size, cxt->pmsg_data.console_size);

    而

    cxt->pmsg_data.mem_address = res->start;

    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

    从原理上来讲,驱动匹配后,获取到设备树里的内存资源,然后通过phys_to_virt转换成虚拟地址后,这个是没有问题的!

    并且一个很关键的信息:

    1. 基线升级之前代码没有问题

    2. 基线升级的代码中mtdoops.c源码没有改动

    所以现阶段只能怀疑是设备树的这段内存出现了问题!因为使用phys_to_virt转换虚拟地址,必须保证这段内存是线性内存区域!


    mtdoops使用的内存区域,是reserved memory,也即是ramoops,这段地址是线性区域

    &reserved_memory {	
        //...
        ramoops_mem: ramoops@80D00000 {
    		compatible = "ramoops";
    		reg = <0x0 0x80D00000 0x0 0x200000>;
            record-size = <0x40000>;
    		pmsg-size = <0x100000>;
            console-size = <0x80000>;
    	};
        //...
    };

    继续检查dmesg日志,因为开机时会打印所有的reserved_mem的region

    [    0.000000][    T0] OF: reserved mem: OVERLAP DETECTED!
    [    0.000000][    T0] pvm_fw_region@80c01000 (0x0000000080c01000--0x0000000080e01000) overlaps with ramoops@80D00000 (0x0000000080d00000--0x0000000080f00000)
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000ff800000, size 4 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node vm_comm_mem_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000ff800000..0x00000000ffbfffff (4096 KiB) map reusable vm_comm_mem_region
    [    0.000000][    T0] OF: reserved mem: 0x00000000fec00000..0x00000000ff7fffff (12288 KiB) map non-reusable mem_dump_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000fcc00000, size 32 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000fcc00000..0x00000000febfffff (32768 KiB) map reusable linux,cma
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000fc000000, size 12 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node adsp_heap_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000fc000000..0x00000000fcbfffff (12288 KiB) map reusable adsp_heap_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000fa400000, size 28 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node audio_cma_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000fa400000..0x00000000fbffffff (28672 KiB) map reusable audio_cma_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000fa000000, size 4 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node sdsp_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000fa000000..0x00000000fa3fffff (4096 KiB) map reusable sdsp_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000f7800000, size 40 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node secure_cdsp_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000f7800000..0x00000000f9ffffff (40960 KiB) map reusable secure_cdsp_region
    [    0.000000][    T0] OF: reserved mem: 0x000000097ffff000..0x000000097fffffff (4 KiB) nomap non-reusable debug_kinfo_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x000000097ec00000, size 16 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node va_md_mem_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x000000097ec00000..0x000000097fbfffff (16384 KiB) map reusable va_md_mem_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000f1c00000, size 92 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node non_secure_display_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000f1c00000..0x00000000f77fffff (94208 KiB) map reusable non_secure_display_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000f0800000, size 20 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node qseecom_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000f0800000..0x00000000f1bfffff (20480 KiB) map reusable qseecom_region
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000e7800000, size 16 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node qseecom_ta_region, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000e7800000..0x00000000e87fffff (16384 KiB) map reusable qseecom_ta_region
    [    0.000000][    T0] OF: reserved mem: 0x0000000080600000..0x000000008063ffff (256 KiB) nomap non-reusable xbl_dtlog_region@80600000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080640000..0x00000000807fffff (1792 KiB) nomap non-reusable xbl_ramdump_region@80640000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080800000..0x000000008085ffff (384 KiB) nomap non-reusable aop_image_region@80800000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080860000..0x000000008087ffff (128 KiB) nomap non-reusable aop_cmd_db_region@80860000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080880000..0x000000008089ffff (128 KiB) nomap non-reusable aop_config_region@80880000
    [    0.000000][    T0] OF: reserved mem: 0x00000000808a0000..0x00000000808dffff (256 KiB) nomap non-reusable tme_crash_dump_region@808a0000
    [    0.000000][    T0] OF: reserved mem: 0x00000000808e0000..0x00000000808e3fff (16 KiB) nomap non-reusable tme_log_region@808e0000
    [    0.000000][    T0] OF: reserved mem: 0x00000000808e4000..0x00000000808f3fff (64 KiB) nomap non-reusable uefi_log_region@808e4000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080900000..0x0000000080afffff (2048 KiB) nomap non-reusable smem_region@80900000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080b00000..0x0000000080bfffff (1024 KiB) nomap non-reusable cpucp_fw_region@80b00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080c00000..0x0000000080c00fff (4 KiB) nomap non-reusable chipinfo_region@80c00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080c01000..0x0000000080e00fff (2048 KiB) nomap non-reusable pvm_fw_region@80c01000
    [    0.000000][    T0] OF: reserved mem: 0x0000000080d00000..0x0000000080efffff (2048 KiB) map non-reusable ramoops@80D00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000082a00000..0x0000000082cfffff (3072 KiB) nomap non-reusable wlan_fw_region@82a00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000083600000..0x00000000843fffff (14336 KiB) nomap non-reusable hyp_region@0x83600000
    [    0.000000][    T0] OF: reserved mem: 0x0000000084b00000..0x00000000852fffff (8192 KiB) nomap non-reusable camera_region@84b00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000085300000..0x0000000086bfffff (25600 KiB) nomap non-reusable wpss_region@85300000
    [    0.000000][    T0] OF: reserved mem: 0x0000000086c00000..0x00000000893fffff (40960 KiB) nomap non-reusable adsp_region@86c00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000089400000..0x0000000089dfffff (10240 KiB) nomap non-reusable cdsp_region@89400000
    [    0.000000][    T0] OF: reserved mem: 0x0000000089e00000..0x0000000089e0ffff (64 KiB) nomap non-reusable ipa_fw_region@89e00000
    [    0.000000][    T0] OF: reserved mem: 0x0000000089e10000..0x0000000089e19fff (40 KiB) nomap non-reusable ipa_gsi_region@89e10000
    [    0.000000][    T0] OF: reserved mem: 0x0000000089e1a000..0x0000000089e1bfff (8 KiB) nomap non-reusable gpu_microcode_region@89e1a000
    [    0.000000][    T0] OF: reserved mem: 0x000000008bc00000..0x000000009a1fffff (235520 KiB) nomap non-reusable mpss_region@8bc00000
    [    0.000000][    T0] OF: reserved mem: 0x000000009a200000..0x000000009a8fffff (7168 KiB) nomap non-reusable video_region@9a200000
    [    0.000000][    T0] OF: reserved mem: 0x00000000a6e00000..0x00000000a6e3ffff (256 KiB) nomap non-reusable xbl_sc_region@a6e00000
    [    0.000000][    T0] OF: reserved mem: 0x00000000a6f00000..0x00000000a6ffffff (1024 KiB) nomap non-reusable global_sync_region@a6f00000
    [    0.000000][    T0] OF: reserved mem: 0x00000000b8000000..0x00000000baafffff (44032 KiB) map non-reusable splash_region
    [    0.000000][    T0] OF: reserved mem: 0x00000000e0600000..0x00000000e09fffff (4096 KiB) nomap non-reusable cpusys_vm_region@e0600000
    [    0.000000][    T0] Reserved memory: created CMA memory pool at 0x00000000e0c00000, size 76 MiB
    [    0.000000][    T0] OF: reserved mem: initialized node trust_ui_vm_region@e0c00000, compatible id shared-dma-pool
    [    0.000000][    T0] OF: reserved mem: 0x00000000e0c00000..0x00000000e57fffff (77824 KiB) map reusable trust_ui_vm_region@e0c00000
    [    0.000000][    T0] OF: reserved mem: 0x00000000e8800000..0x00000000e88fffff (1024 KiB) nomap non-reusable tz_stat_region@e8800000
    [    0.000000][    T0] OF: reserved mem: 0x00000000e8900000..0x00000000e8f7ffff (6656 KiB) nomap non-reusable tags_region@e8900000
    [    0.000000][    T0] OF: reserved mem: 0x00000000e8f80000..0x00000000e947ffff (5120 KiB) nomap non-reusable qtee_region@e8f80000
    [    0.000000][    T0] OF: reserved mem: 0x00000000e9480000..0x00000000efc7ffff (106496 KiB) nomap non-reusable trusted_apps_region@e9480000

    我们可以看到这段异常点:

    [    0.000000][    T0] OF: reserved mem: OVERLAP DETECTED!
    [    0.000000][    T0] pvm_fw_region@80c01000 (0x0000000080c01000--0x0000000080e01000) overlaps with ramoops@80D00000 (0x0000000080d00000--0x0000000080f00000)

    这个pvm_rw_region的内存区域和ramoops的内存区域发生重叠!!

    查询改动

    而这段区域被设置为非映射区域

    问题根因

    直接原因

    • 三级页表转换错误(level 3 translation fault)

    • 页表项为空,没有建立虚拟地址到物理地址的映射

    • 任何访问该地址的操作都会触发页错误

    根本原因

    [    0.000000][    T0] OF: reserved mem: OVERLAP DETECTED!
    [    0.000000][    T0] pvm_fw_region@80c01000 (0x0000000080c01000--0x0000000080e01000) overlaps with ramoops@80D00000 (0x0000000080d00000--0x0000000080f00000)
    • 两个驱动声明了重叠的物理内存区域

    • 内核无法为重叠区域建立一致的页表映射

    解决方案

    重新规划pvm_fw_region和ramoops的内存区域,避免重叠

    关键技术知识点总结

    物理地址与虚拟地址映射

    直接映射 (线性映射)

    c

    // ARM64典型配置
    #define PAGE_OFFSET     0xffff000000000000
    虚拟地址 = PAGE_OFFSET + 物理地址

    适用场景: 常规内核内存访问

    动态映射

    c

    // 保留内存、设备内存等特殊区域
    void *ioremap(phys_addr_t offset, size_t size);
    void *memremap(phys_addr_t offset, size_t size, unsigned long flags);

    适用场景:

    • 设备寄存器访问

    • 保留内存区域

    • 非连续物理内存

    内存类型

    推荐映射方法

    注意事项

    常规内核内存

    phys_to_virt

    仅限直接映射区域

    设备寄存器

    ioremap

    设置正确的缓存属性

    保留内存

    ioremap/memremap

    检查设备树配置

    DMA缓冲区

    dma_alloc_coherent

    保证缓存一致性

    设备树内存管理

    reserved memory声明

    reserved-memory {
        region@address {
            reg = <0x0 base_address 0x0 size>;
            no-map;          // 内核不创建映射
            reusable;        // 内核可临时使用
        };
    };

    内存属性

    • no-map: 内核不创建线性映射,必须手动ioremap

    • reusable: 内核可在驱动未加载时使用该内存

    • alignment: 内存对齐要求

    内核分析利器crash的编译指南 2025-10-27 评论 林渡
      技术分享
      Linux内核crashgithub actions
    内核分析利器crash的编译指南

    crash是一款基于GDB、专为Linux内核崩溃转储文件分析而设计的开源工具,补足了GDB无法读取内核核心信息的不足。文章详解crash的手动编译安装流程,并重点介绍利用GitHub Action实现自动化编译和发布,极大简化部署环节,高效便捷,适合开发者快速上手与持续集成。

    利用 Claude Code 探索 Linux 内核奥秘 2025-10-23 1 条 林渡
      技术分享
      Claude CodeLinux内核
    利用 Claude Code 探索 Linux 内核奥秘

    Claude Code高效助力Linux内核学习,文章详细介绍其在Windows系统上的安装流程及环境变量设置,并对API KEY获取及费用问题给出第三方解决方案。通过配置和使用Claude-code-router,可灵活切换API服务,支持针对不同目录乃至全局的内核源码智能分析,大幅提升开发和学习

    1 … 4 5 6 … 19
  • 简述
    在万物之间穿行,也在自我之间渡过。
    liuqi20328@gmail.com
    生涯
  • 行业嵌入式
  • 职业Linux/Android内核工程师
  • 人生
  • 生活角色浪子、父母的娃、我夫人的老公
  • 社会角色公司职员、中华人民共和国公民
  • 类型
  • 星座 ♊双子座
  • 生肖 🐖猪
  • 血型O
  • 数据
  • 发表文章184篇
  • 发表评论74个
  • 星球加热64986度
  • 最近的心情能量
      愉快 沮丧
    • 😐 不喜不悲 ,当时发表在「[灵感风暴] Charger Property Engine 设计方案」
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第034篇 slab内存分配器之kmalloc全面详解」
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第033篇 深度解析 slab 内存池回收内存以及销毁全流程」
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第032篇 使用trace32分析slab cache」
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第031篇 内核启动早期的slab分配器的自举」
  • 地图数据来源于高德地图
  • intj 建筑师
    intj 建筑师
    • 外向内向
    • 远见现实
    • 理性感受
    • 评判展望
    • 坚决起伏
  • 了解更多信息
今天是云栖梦泽·

2024-11-11

随机阅读「[Android稳定性] 第65篇 SELinux 设置为 permissive 模式后出现的 kernel panic」
阅读 项目在 bringup 阶段发现,将手机 SELinux 设为 permissive 后系统会在进入 Android 前死机。通过 fulldump 与内核日志可见 panic 原因是 UBSAN 报告的数组越界,触发点位于 uzram 模块的 zram_submit_bio。借助自研工具 kernel-panic-killer,AI 自动还原异常路径:反汇编发现 zram_submit_bio 中通过 current_algo 计算压缩算法索引,逻辑为 algo = current_algo; 访问 zram->comps[algo - 1]。由于 current_algo 默认为未初始化的
壹行随十人
  • 星风之痕
  • 且听书吟
  • 山海云栈
  • 谜叶象限
  • 博客集市
  • iSeekLife
  • 迷鹿屋
  • 山海寻川
  • 轻雅阁
  • 风记星辰
云栖梦泽版权所有 · 架构于Halo及为您增强体验的THYUU/星度主题
苏ICP备2025185582号-1 苏ICP备2025185582号-1 苏公网安备32060102321049号 苏公网安备32060102321049号 BlogsClub BlogsClub 笔墨迹 笔墨迹