云栖梦泽
林渡
Blog
  • 首页
  • 我的视界
    • 人世间
      • 世间风声
      • 人间烟火
    • 壹句话
    • 云外光影
      • 动物与植物
      • 美食
      • 生活气息
      • 人物
    • 文章归档
      • 技术分享
      • 视频类型
      • 音频类型
      • 图文类型
      • 图片类型
    • 知识库
  • 「知识宇宙」
    • 灵感工坊
      • 灵感风暴
      • 与AI共生
      • 开源项目推荐
    • 底层漫游
      • Android稳定性
      • Linux内存管理
      • Linux内存管理
      • Linux进程调度
      • Linux内核
      • ARM体系架构
      • LRDP2
      • 技术分享
  • 璀璨星河
    • 公告
    • 知识库
    • 轻言
    • 众星
    • 豆瓣
    • 足迹
    • 走心评论
    • 林渡的网盘
  • 留言板
  • 关于
    • 捐赠者名单
    • 关于我
    • 一些声明
      • 站点声明
      • 隐私政策
    • 网站看板
  • 欢迎订阅!

欢迎来到云栖梦泽,为您导读全站动态
  • Jing Cheng 2日前前留言 😀
  • 林渡 4日前前留言 抱歉,隔了这么久才回复,其实从我自己实际的使用体验来看,两者的差别不是特别大。启用向量嵌入反而在索引的时候更耗时间,所以我一般都不启用向量嵌入!
  • 林渡 6日前前留言

    SyzForge 是一个开源系统,旨在将 Linux 内核 Bug 排查从分散的 syzbot 报告转化为结构化、可重复的工程流水线,通过三个 MCP 服务器(SyzLens、KernelLab、KernelMail)分别处理证据采集、内核复现和社区协作,让开发者更高效地完成 Bug 调查与修复。
    --🤖 AI 自动回复

  • 林渡 6日前前留言 @AI助手 一句话总结这个项目
  • 林渡 3周前前留言 随便写写的啊 - 。-
  • 12.. 3周前前留言 文章质量这么好,应该有编辑社找博主出书吧😁
  • 12.. 3周前前留言 我的看法跟博主一致, AI很强大。 在未来我认为AI会作为新一轮科技革命必然给社会带来巨大变革,同时会加大社会分化,砸了很多人的饭碗。
  • 12.. 3周前前留言 强👍
  • llx 3周前前留言 写得很详细,感谢分享
  • junlong 2026-08-20前留言 感谢
2026 年 9 月
日一二三四五六
12345
6789101112
13141516171819
20212223242526
27282930
« 8 月  
最近文章
  • 2026-09-08 [linux内存管理] 第 059 篇 /proc/slabinfo 详解
  • 2026-08-28 [linux内存管理] 第 058 篇 从虚拟内存到 Swap —— 交换子系统整体架构
  • 2026-08-25 SyzForge:把 syzbot 报告锻造成可复现的内核 Bug 调查流水线
  • 2026-08-24 [linux内存管理] 第 057 篇 OOM Kill 与 panic_on_oom —— 杀人的艺术与崩溃的抉择
  • 2026-08-24 [linux内存管理] 第 056 篇 OOM Reaper:异步解除映射的幕后英雄
  • 2026-08-24 [linux内存管理] 第 055 篇 OOM Killer 死亡名单算法
  • 2026-08-19 [linux内存管理] 第 054 篇 OOM触发 + Memory Reserve + out_of_memory 决策
  • 2026-08-14 [linux内存管理] 第 053 篇 OOM 整体流程:从内存耗尽到系统崩溃的完整链路
  • 2026-08-12 LoreMate:给 lore.kernel.org 装上 AI 阅读助手
  • 2026-08-12 AOSP 整机源码 Harness 工程探索
  • 2026-08-06 [linux内存管理] 第 052 篇 shrink_page_list:内存回收的“最后一道关口”
  • 2026-08-04 Monsoon Power Monitor MCP 工具介绍
  • 2026-07-28 [linux内存管理] 第 051 篇 内存回收核心 shrink_node
  • 2026-07-22 [linux内存管理] 第 050 篇 深度分析 direct reclaim 机制
  • 2026-07-20 [linux内存管理] 第 049 篇 深度分析 Linux kswapd 后台回收机制
  • 2026-07-16 [linux内存管理] 第 048 篇 从 alloc_pages() 开始:快慢路径下的内存回收策略
  • 2026-07-15 [linux内存管理] 第 047 篇 Linux 内存回收(Memory Reclaim)总体架构
  • 2026-07-11 [Android稳定性] 第065篇 SELinux 设置为 permissive 模式后出现的 kernel panic
  • 2026-07-03 再看《孩子王》观后感:当AI成为每个人的“字典”之后
  • 2026-06-01 [Android稳定性] 第064篇 blk_mq_tags Use-After-Free 导致系统级 I/O 死锁
热门文章
  • 2024-11-22 高通android启动代码流程分析(SBL->ABL)
  • 2026-01-29 📢 致读者的一封信:关于运营、初心与一份邀请
  • 2026-05-06 [开源项目] GitNexus + Claude Code 配置与使用指南
  • 2024-12-15 [Android稳定性] 第000篇 Android稳定性系列开篇
  • 2025-08-27 [Android稳定性] 第058篇 [方法篇] 高通平台使用QFIL回读分区
  • 2025-07-21 高通以及MTK平台内核单独编译ko的原理
  • 2026-04-01 AI时代笔记工作流:构建下一代知识管理引擎
  • 2025-09-04 琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证
  • 2025-07-10 [Linux进程调度] 第001篇 一篇文章全面了解Linux进程调度
  • 2025-06-16 [Android稳定性] 第049篇 [问题篇] 软中断霸占CPU导致watchdog无法及时喂狗
  • 2026-01-08 【深入内核】中断真的不能睡眠吗?
  • 2024-12-18 [Android稳定性] 第004篇 [原理篇] minidump的原理介绍
  • 2025-06-25 [Android稳定性] 第052篇 [方法篇] HMI项目中如何使用QCAP解析minidump?
  • 2025-11-03 [linux内存管理] 第000篇 Linux内存管理系列开篇
  • 2025-01-14 [Android稳定性] 第017篇 [方法篇] 高通watchdog分析流程
  • 2025-06-18 [linux内存管理] 第027篇 Linux ARM64 虚拟地址布局
  • 2024-12-15 [Android稳定性] 第001篇 [方法篇] 高通Android平台稳定性分析介绍
  • 2025-06-09 【深入内核】linux ftrace详解
  • 2026-03-24 认知加速度:AI时代最残酷的鸿沟,正在此刻拉开
  • 2024-11-29 [linux内存管理] 第009篇 reserved-memory详解
热门标签
  • 内核线程 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
101689° 210 15 298
当您评论及浏览文章且浏览器未禁止COOKIE时,会为您显示最近10条回复及前20篇文章的浏览记录。
在万物之间穿行,也在自我之间渡过。

你好,
我是林渡

    • 1周前

      之前公司组建了SSE的一个小team,主要就是各个模块的SE,专注于模块技术问题攻关,风险问题识别,需求下发等,我觉得还是蛮好的,最起码每个模块需要这样的专业人员来保证软件方案的准确性! 结果呢,一个模块来需求需要适配了(提供了参考change),leader呢不内部协调同模块的工程师去加急适配,现

    • 1周前

      模型能力越来越强,以前想做却没能力做的一些想法也慢慢自己实现了。但是我现在却发现这个时代最难的却是idea!我已经好久没有好的idea了,现在面对着codex的剩余额度,却不知道该干什么!

    • 2026-08-07

      蟹黄汤包和河豚还得是靖江的好吃! 南通的海鲜也是鲜到眉毛了!

    • 2026-07-20

      看了好久,还是狠心下手了小牛mt sport 2026款,以后可以下班送外卖了 - 。 -

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

    [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 评论 林渡
      人间烟火
      理想与现实生活美学人生态度烟火气精神追求
    琴棋书画诗酒花与柴米油盐酱醋茶的人生辩证

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

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

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

    琴棋书画诗酒花的理想

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

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

    柴米油盐酱醋茶的现实

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

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

    理想与现实的平衡

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

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

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

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

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

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

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

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

    如何活成自己的模样

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

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

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

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

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

    结语

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

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

    1 … 6 7 8 … 20
  • 简述
    在万物之间穿行,也在自我之间渡过。
    liuqi20328@gmail.com
    生涯
  • 行业嵌入式
  • 职业Linux/Android内核工程师
  • 人生
  • 生活角色浪子、父母的娃、我夫人的老公
  • 社会角色公司职员、中华人民共和国公民
  • 类型
  • 星座 ♊双子座
  • 生肖 🐖猪
  • 血型O
  • 数据
  • 发表文章200篇
  • 发表评论82个
  • 星球加热89914度
  • 最近的心情能量
      愉快 沮丧
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第031篇 内核启动早期的slab分配器的自举」
    • 😐 不喜不悲 ,当时发表在「[linux内存管理] 第030篇 深入理解 slab cache 内存分配全链路实现」
    • 😐 不喜不悲 ,当时发表在「[Android稳定性] 第060篇 [问题篇] storage corruption导致的死机」
    • 🙂 有点愉快 ,当时发表在「[Android稳定性] 第059篇 [问题篇] 内核内存区域重叠导致的页表映射错误」
    • 😁 非常愉快 ,当时发表在「内核分析利器crash的编译指南」
  • 地图数据来源于高德地图
  • intj 建筑师
    intj 建筑师
    • 外向内向
    • 远见现实
    • 理性感受
    • 评判展望
    • 坚决起伏
  • 了解更多信息
今天是云栖梦泽·

2024-11-11

随机阅读「linux内核源码解析03–启动代码分析之主内核页表创建」
阅读 Linux内核初始化过程中,会依次建立多种页表映射,以支持不同的内存访问需求。这些映射包括恒等映射、粗粒度内核镜像映射、fixmap映射、细粒度内核镜像映射、线性映射以及用户空间页表映射。文章详细解析了细粒度内核镜像映射和线性映射的创建过程,以及内核主页表的建立。此外,还介绍了伙伴系统的初始化,包括bootmem分配器的初始化、sparse内存模型初始化、zone数据结构初始化等。通过这些初始化过程,Linux内核为后续的内存管理和进程调度等操作奠定了基础。
壹行随十人
  • 博客集市
  • 星风之痕
  • 山海云栈
  • 且听书吟 - 诗与梦想的远方
  • 风记星辰
  • 山海寻川
  • 谜叶象限 - 每一片叶子,都是未完成的坐标系
  • 轻雅阁
  • 迷鹿屋
  • iSeekLife
云栖梦泽版权所有 · 架构于Halo及为您增强体验的THYUU/星度主题
苏ICP备2025185582号-1 苏ICP备2025185582号-1 苏公网安备32060102321049号 苏公网安备32060102321049号 BlogsClub BlogsClub 笔墨迹 笔墨迹