云栖梦泽
林渡
Blog
  • 首页
  • 我的视界
    • 人世间
      • 世间风声
      • 人间烟火
    • 壹句话
    • 云外光影
      • 动物与植物
      • 美食
      • 生活气息
      • 人物
    • 文章归档
      • 技术分享
      • 视频类型
      • 音频类型
      • 图文类型
      • 图片类型
  • 「内核宇宙」
    • 灵感工坊
      • 灵感风暴
    • 底层漫游
      • Android稳定性
      • Linux内存管理
      • Linux进程调度
      • Linux内核
      • ARM体系架构
      • LRDP2
      • 技术分享
  • 璀璨星河
    • 公告
    • 应用舱
    • 众星
    • 豆瓣
    • 足迹
    • 走心评论
    • 林渡的网盘
  • 留言板
  • 关于
    • 捐赠者名单
    • 关于我
    • 一些声明
      • 站点声明
      • 隐私政策
    • 网站看板
  • 欢迎订阅!

欢迎来到云栖梦泽,为您导读全站动态
  • 林渡 2日前前留言 工具我更新了,但是小米在线解析的,那个只支持小米内网的
  • ktxck 2日前前留言 确实都打不开,但你文章里提到的那个小米解析网站也打不开,实在没办法了,我现在正试着用pcat看看
  • 林渡 2日前前留言 你说的是minidump_linux_unzip 和 拆分脚本吧?这两个你应该用不到的,这个是我们客户定制的,应该不会适用于你们项目
  • 林渡 2日前前留言 哪里呀?不是这篇文章里的吧?
  • ktxck 2日前前留言 26年4月,文章提到的工具链全部失效了,想问一下这里面有hv层的详细日志吗光靠搜索没乱码的地方只能读到 ... (正常hv层内容启动) ... 4 344.470102 WDT bite: now_ticks 4915389, last_pat 3932438, from VM 3 4 344.471089 Abort: Watchdog bite from PC 0xffffffd6c6e3802c, FP 0xffffff97c0050eb0 4 344.471148 WDT: Triggering NS Watchdog Bite
  • 林渡 1周前前留言 有时候会直接修改page cache页数据,不走页表,那写保护就无效了。回写线程清除 PG_dirty 时,它赌的是:这个页在回写期间不会被修改。如果这个赌注输了(即 PG_dirty 在 I/O 完成前又被设置了),内核需要在 I/O 完成后重新入队回写。关键就在 redirty_page_for_writeback:这个函数会重新设置 PG_dirty + PAGECACHE_TAG_DIRTY,让这个页重新出现在下次回写的队列里。这样就能兜住 GUP 或 do_wp_page 产生的并发脏写。
  • Melokc 1周前前留言 回写这块我之前一直对一些细节很疑惑,就某个细节谈一下疑惑&看法。之前最疑惑的一点就是,为什么是在回写之前把dirty标志清掉?为什么不等待完全回写完毕之后,页面真正干净了,再抹掉标志位呢。甚至在shrink流程下,writeback之前还会释放PG_locked,摆明着在回写过程中卸下防备,等着页面被更改。现在的理解是,页在wb场景下,虽然设置了pte写保护,但仍旧有可能触发do_wp_page(),让这个页变脏,这时候回写之前抹掉dirty的好处就体现了,回来之后又发现自己是dirty的,说明又被改写了。甚至可能不是用户态触发缺页导致的dirty,可能是内核直接GUP导致的dirty(这个隐约记得在哪个文件里看到过相关注释,但当时没有记录,在懊恼了)
  • 林渡 1周前前留言 其实方法已经给了,重要的就是利用AI,让claude code代替人去理解代码架构,你只需要把你的需求以自然语言告诉claude code。
  • 林渡 1周前前留言 哈哈,我也觉得付费阅读很反感,所以基本上不会考虑的,改成打赏支持,能够抵一部分服务器成本就可以了。这个博客主要还是分享以及让自己回顾一下自己的知识点。 打赏支持页面就是一个单独的html页面,没有使用插件
  • 寻境者·唐 1周前前留言 这种模式挺好,当然当你积累到一定能量的时候,能够输出更多高水平高质量的文章时,是可以结合付费阅读的,虽然我本人挺反感这样的模式。 另外你这个打赏支持页面功能很不错,用什么插件实现的吗?
2026 年 4 月
日一二三四五六
1234
567891011
12131415161718
19202122232425
2627282930
« 3 月  
最近文章
  • 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机制深入分析
  • 2026-02-03 [linux内存管理] 第041篇 缺页异常之 do_swap_page:从 swap entry 到完整 swap-in 全流程
  • 2026-02-03 [灵感风暴] GKI 升级不再靠人肉:Aegis 自动风险分级与测试建议生成
  • 2026-02-02 [linux内存管理] 第040篇 文件映射与匿名映射
  • 2026-01-31 [Android稳定性] 第61篇 UFS异常导致卡开机logo
  • 2026-01-30 [linux内存管理] 第039篇 用户态内存映射malloc和mmap详解
  • 2026-01-29 [linux内存管理] 第038篇 深入剖析AArch64架构下的do_page_fault缺页异常处理
热门文章
  • 2024-11-22 高通android启动代码流程分析(SBL->ABL)
  • 2025-07-21 高通以及MTK平台内核单独编译ko的原理
  • 2025-08-27 [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区
  • 2024-12-15 [Android稳定性] 第000篇 Android稳定性系列开篇
  • 2025-06-25 [Android稳定性] 第052篇 [方法篇] HMI项目中如何使用QCAP解析minidump?
  • 2025-06-18 [linux内存管理] 第027篇 Linux ARM64 虚拟地址布局
  • 2026-01-29 📢 致读者的一封信:关于运营、初心与一份邀请
  • 2025-06-09 【深入内核】linux ftrace详解
  • 2024-11-29 [linux内存管理] 第009篇 reserved-memory详解
  • 2025-08-23 [linux内存管理] 第029篇 谁把folio的函数定义“藏”起来了?
  • 2025-01-14 [Android稳定性] 第017篇 [方法篇] 高通watchdog分析流程
  • 2024-12-15 [Android稳定性] 第001篇 [方法篇] 高通Android平台稳定性分析介绍
  • 2025-06-04 [Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
  • 2025-08-05 [Android稳定性] 第057篇 [方法篇] 高通平台使能ftrace的方法
  • 2025-11-03 [linux内存管理] 第000篇 Linux内存管理系列开篇
  • 2025-10-23 利用 Claude Code 探索 Linux 内核奥秘
  • 2024-12-18 [Android稳定性] 第004篇 [原理篇] minidump的原理介绍
  • 2025-08-19 【深入内核】ARM64下的内核栈
  • 2025-09-11 【深入内核】理解Linux Static Keys和jump label机制
  • 2025-07-30 [Android稳定性] 第054篇 [方法篇] 高通平台如何解析ADSP Crash?
热门标签
  • 内核线程 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
42750° 188 14 255
当您评论及浏览文章且浏览器未禁止COOKIE时,会为您显示最近10条回复及前20篇文章的浏览记录。
在万物之间穿行,也在自我之间渡过。

你好,
我是林渡

    • 1日前

      当AI替我写完代码、润色文案、整理思路,我差点忘了自己也曾能徒手解构问题,也曾深入底层逻辑去研究代码。而如今直到token额度用尽,屏幕显示额度“0%”,只能安静的等待着额度刷新,我在电脑前呆愣住——原来不知不觉间,我的能力已经悄悄托管给了AI。额度归零的那一刻,我突然不会“自己”干活了。 这场浪潮

    • 2026-03-17

      只是简单的创建了一下今日任务清单+沉淀一篇文章要点+探索obsidian插件 就花了5.87元,现在的api还是太贵了啊

    • 2026-03-03

      给博客增加了一个项目展示页,还是挺好看的了。 链接:应用舱

    • 2026-02-26

      “本来以为AI抢不走我分析内核宕机的活儿,毕竟得懂内核、会crash。 今天看到这个MCP服务……好了,感觉我的饭碗也开始‘宕机’了……AI 进化太快了,感觉离失业更近一步了......

    • 查看更多瞬间动态
  • [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服务,支持针对不同目录乃至全局的内核源码智能分析,大幅提升开发和学习

    [Linux进程调度] 第002篇 Linux下0号进程的前世(init_task进程)今生(idle进程) 2025-09-18 评论 林渡
      Linux进程调度
      Linux内核进程调度init进程idle进程内核线程
    [Linux进程调度] 第002篇 Linux下0号进程的前世(init_task进程)今生(idle进程)

    Linux下有三个特殊进程:idle(PID=0)、init(PID=1)和kthreadd(PID=2)。idle是系统首个进程,由静态定义的init_task演变而来,是唯一未通过fork/kernel_thread产生的进程,运行在内核态,每个处理器单元独立一个,负责系统空闲时执行节能循环。init由idle创建,完成初始化后进入用户空间,成为所有用户进程祖先,最终转为守护进程。kthreadd亦由idle创建,始终运行于内核空间,负责管理和调度所有内核线程,是其父进程。idle通过rest_init函数创建init和kthreadd后演变为idle,不参与调度,仅在运行队列为空时执行cpu_idle_loop。

    【深入内核】理解Linux Static Keys和jump label机制 2025-09-11 5 条 林渡
      Linux内核
      Linux内核性能优化Static Keys动态分支内核开发
    【深入内核】理解Linux Static Keys和jump label机制

    在Linux内核高频路径中,likely/unlikely宏帮助提升分支预测准确率,但随着判断增多,分支预测失败和cache压力导致性能瓶颈。为彻底消除分支带来的损耗,内核引入static keys和jump label机制,通过运行时动态替换代码段,实现零开销切换分支。

    高效工作的秘诀:时间管理 2025-09-05 评论 林渡
      人间烟火
      时间管理高效工作任务管理生产力工具
    高效工作的秘诀:时间管理

    在快节奏生活中,高效时间管理是提升工作效率和生活质量的关键。通过明确目标、合理排序优先级、专注当前任务并灵活应对变化,可显著减少焦虑。结合Google Calendar、Todoist等工具和番茄工作法,制定每日计划、分解任务、设定时间边界,有效避免过度安排与拖延。科学的时间管理不仅助力高效工作,更是一种生活态度!

    琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证 2025-09-04 评论 林渡
      人间烟火
      理想与现实生活美学人生态度烟火气精神追求
    琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证

    “琴棋书画诗酒花”承载了对诗意生活的向往,而“柴米油盐酱醋茶”则是真实生活的基石。文章探讨了理想与现实的平衡,强调在琐碎中发现美好,在平凡中融入浪漫。通过茶的沉静和酒的浓烈跨越生活两端,真正的生活韵味蕴藏于酸甜苦辣交织的日常。以心存情调面对现实,既能享受水墨画般的悠然,也能静观人间烟火的丰盈。

    琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证
    查看完整文章 评论

    人在年轻的时候,
    莫不是希望这一生就是琴棋书画诗酒花。
    可终究,还是逃不过柴米油盐酱醋茶。
    ——网易云音乐热评墙《茶酒伴》

    琴棋书画诗酒花的理想

    年轻的时候,总觉得人生应该是充满诗意的。琴棋书画诗酒花,不仅是一种生活方式,更像是一种精神向往。抚琴可安魂,弈棋能静心,书画寄情怀,诗酒醉流年,花间一壶酒,人生不胜欢。这样的日子,不染半点世俗纷扰,像一幅水墨画般柔和又悠长。

    这种状态之所以迷人,是因为它承载了人对自由和美好的全部幻想。我们渴望拥有创造的闲暇与精神的丰盈,仿佛只要躲进书房,推开窗便能看见人世间最美的风景。

    柴米油盐酱醋茶的现实

    然而,随着年龄的增长,我们慢慢发现,理想固然美好,但现实却总是在不经意间敲醒你。柴米油盐酱醋茶,才是日复一日绕不开的日常。柴火代表生活的温度,米与油是餐桌的基础,盐与酱是味觉的平衡,醋与茶则在酸与苦中调和人生的滋味。

    它们看似普通,却紧紧牵动着一家人的生活节奏。在柴米油盐的烟火气中,我们学会了为家人早起熬粥,也练就了在市场里精打细算的本事。那些曾经觉得索然无味的小事,最终成为支撑生活的支柱。

    理想与现实的平衡

    有趣的是,“琴棋书画诗酒花”与“柴米油盐酱醋茶”并不是对立的两极,而更像是人生的两个维度。理想提供方向,现实给予力量。缺一不可。

    • 在琐碎中寻找诗意:下班后泡一壶好茶,也许就是柴米油盐里的琴棋书画。

    • 在美好中接纳平凡:旅行归来,依旧能从温热的家常菜中感到幸福。

    • 让精神与胃口都得到满足:一首诗配一杯咖啡,一顿饭后读几页书。

    学会让理想与现实交织,才能既不失生活的质感,也不失心灵的宽度。

    茶酒伴:在酸甜苦辣间对话

    网易云音乐热评墙上的那句——“人在年轻的时候,莫不是希望这一生就是琴棋书画诗酒花,可终究,还是逃不过柴米油盐酱醋茶”,恰如其分地描绘出成长的本质。茶酒伴,一字茶平和沉静,一字酒热烈奔放,像极了人生两端的呼应。

    茶,提醒我们在忙碌中保持清醒;酒,则教会我们在疲惫时拥抱欢愉。人生的味道,正是在这冷暖之间变得厚重且绵长。

    如何活成自己的模样

    真正的生活高手,不是拒绝现实,而是能在柴米油盐中弹起琴,在酱醋茶香里写下诗。可以忙完工作,转身去画廊看看油画;也可以在节日的厨房里和家人齐心协力做一桌饭。

    想要兼得琴棋书画诗酒花与柴米油盐酱醋茶,不妨试试以下方法:

    • 在日程中为自己保留半小时的精神时光,无论是读书、写字还是发呆。

    • 将家务当作艺术来完成,摆盘、调味也能像作画一样精致。

    • 用节日或仪式感,为平凡的生活加点浪漫佐料。

    结语

    有人说,年轻是诗,年长是散文。但当琴棋书画诗酒花遇上柴米油盐酱醋茶,人生便能写成一部长篇——既有高潮的诗句,也有平淡的叙事段落。理想与现实彼此依托,我们终会发现,柴米油盐里也暗藏着琴棋书画的风雅。

    茶与酒作伴,花与柴同放,这才是最真实、最丰盈的人间烟火。

    透视人生的意义:活出属于自己的答案 2025-09-04 1 条 林渡
      人间烟火
      人生意义自我认知个人成长价值观反思
    透视人生的意义:活出属于自己的答案

    每个人的人生意义源自独特的生命体验,无法以单一答案概括。从自我认知入手,明确内心需求,再通过行动和创造赋予生命价值。在接受无常中成长,于人际关系中找到归属感,并通过持续反思调整方向。人生的意义并非固定,而是在探索与实践中逐渐沉淀,关键是倾听内心、珍视当下,让生命绽放独特光芒。

    [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区 2025-08-27 8 条 林渡
      Android稳定性
      readbackQFIL
    [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区

    本文介绍了如何将机器进入9008模式以及通过configuration选择对应的Device type类型。在edl模式下刷机,需要选择机器对应版本并拆包镜像文件。同时,文章强调了回读分区时,如果机器已熔丝签名,必须使用未签名的版本中的prog_firehose_ddr.elf文件。最后,详细展示了如何使用tools进行分区回读操作。

    [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区
    查看完整文章 评论

    机器进入9008模式

    1. 工厂版本使用adb reboot edl命令

    2. 开发版本、稳定版本进入fastboot模式,使用fastboot oem edl命令

    通过configuration选择对应的Device type类型

    2025/08/halo_7fm4lbh.png

    选择下载模式

    按照edl模式刷机选择机器对应版本,工厂版本需要将对应GN、GL、IN对应镜像拷贝到版本里面,使用命令进行拆包:python checksparse.py -i rawprogram0.xml

    2025/08/halo_m49fwv3.png

    注意:如果需要回读分区的机器已经熔丝签名了,则必须使用一个没有熔丝签名的版本中的 prog_firehose_ddr.elf

    选择tools进行回读

    1. 选择Partition Manager

    1. 选择OK

    回读分区

    1. 选择对应的分区,右键选择Manage Partiotion Data

    1. 选择Read Data

    1. 分区对应回读保存目录

    1 … 4 5 6 … 18
  • 简述
    在万物之间穿行,也在自我之间渡过。
    liuqi20328@gmail.com
    生涯
  • 行业嵌入式
  • 职业Linux/Android内核工程师
  • 人生
  • 生活角色浪子、父母的娃、我夫人的老公
  • 社会角色公司职员、中华人民共和国公民
  • 类型
  • 星座 双子座
  • 生肖 猪
  • 血型O
  • 数据
  • 发表文章178篇
  • 发表评论66个
  • 星球加热38252度
  • 最近的心情能量
      愉快 沮丧
    • 不喜不悲 ,当时发表在「[Android稳定性] 第060篇 [问题篇] storage corruption导致的死机」
    • 有点愉快 ,当时发表在「[Android稳定性] 第059篇 [问题篇] 内核内存区域重叠导致的页表映射错误」
    • 非常愉快 ,当时发表在「内核分析利器crash的编译指南」
    • 不喜不悲 ,当时发表在「利用 Claude Code 探索 Linux 内核奥秘」
    • 不喜不悲 ,当时发表在「[Linux进程调度] 第002篇 Linux下0号进程的前世(init_task进程)今生(idle进程)」
  • 地图数据来源于高德地图
  • intj 建筑师
    intj 建筑师
    • 外向内向
    • 远见现实
    • 理性感受
    • 评判展望
    • 坚决起伏
  • 了解更多信息
今天是云栖梦泽·

2024-11-11

随机阅读「[Android稳定性] 第007篇 [问题篇] 中断风暴导致panic」
阅读 问题摘要:系统日志显示irq 193存在异常,其action为0,表明中断未被注册,导致中断被送至`handle_bad_irq`处理。经查询,该中断对应gpio 93,且在设备树中该gpio被用于wusb3801的中断和复位功能。去除相关配置后,系统恢复正常。
壹行随十人
  • 迷鹿屋
  • 且听书吟
  • 秘柯絮语
  • 世上云川
  • 山海运维
  • 问心斋
  • 谜叶象限
  • 菲兹克斯喵
  • 星风之痕
  • 山海云栈
云栖梦泽版权所有 · 架构于Halo及为您增强体验的THYUU/星度主题
苏ICP备2025185582号-1 苏ICP备2025185582号-1 苏公网安备32060102321049号 苏公网安备32060102321049号 BlogsClub BlogsClub 笔墨迹 笔墨迹