Crash加载ramdump报cpu_possible_mask异常问题

本文介绍了使用Crash工具调试ramdump过程中遇到的一个常见错误及其解决办法。文章详细解释了如何通过指定正确的DDR起始地址来解决问题,并展示了如何验证vmlinux与sysdump文件是否匹配。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在使用Crash调试ramdump的时候发现一个错误,这里记录下。

[ 另外需要说明一点是,首先要确保vimlinx跟sysdump是同一次编译生成的,可以这样确认:

$ strings vmlinux |grep "Linux version"
Linux version 3.10.65-ge5e31c1 (android@ubuntu) (gcc version 4.8 (GCC) ) #7 SMP PREEMPT Fri May 19 15:50:19 CST 2017

$ strings sysdump |grep "Linux version"
Linux version 3.10.65-ge5e31c1 (android@ubuntu) (gcc version 4.8 (GCC) ) #7 SMP PREEMPT Fri May 19 15:50:19 CST 2017

---- 如此可见以上vmlinux跟sysdump是匹配的,否则无法继续调试.  ]


$crash vmlinux sysdump


crash 7.1.3
Copyright (C) 2002-2014 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-elf-linux"...

crash: read error: kernel virtual address: c0629750 type: "cpu_possible_mask"

What happen ?


其实就是需要指定DDR起始地址就行了(各个平台定义不一样,可以查lk代码或者开机log看):

#define PHYS_OFFSET_ADDR            0x80000000

$crash -m phys_base=0x80000000 vmlinux sysdump


crash 7.1.3
Copyright (C) 2002-2014 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
NOTE: setting phys_base to: 0x80000000
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-elf-linux"...

please wait... (gathering task table data)
crash: invalid task address: e0776f40

crash: invalid task address: e0777480

crash: invalid task address: e0775a40
KERNEL: vmlinux
DUMPFILE: sysdump
CPUS: 4 [OFFLINE: 3]
DATE: Sun Jan 1 17:01:14 2017
UPTIME: 00:07:11
LOAD AVERAGE: 13.74, 10.87, 4.93
TASKS: 1136
NODENAME: localhost
RELEASE: 3.10.65-ge5e31c1
VERSION: #7 SMP PREEMPT Fri May 19 15:50:19 CST 2017
MACHINE: armv7l (unknown Mhz)
MEMORY: 1 GB
PANIC: "SysRq : Trigger a crash"
PID: 4591
COMMAND: "sh"
TASK: e8a24540 [THREAD_INFO: e8d7e000]
CPU: 2
STATE: TASK_RUNNING (SYSRQ)

crash>



<think>好的,用户想了解subsystem_ramdump的概念、用途以及如何使用。首先我需要明确什么是subsystem_ramdump。根据引用[3],ramdump是系统或子系统崩溃时保存的内存快照,用于离线分析问题。那么subsystem_ramdump应该是指针对特定子系统的ramdump,而不是整个系统。 接下来,用途方面,子系统的崩溃可能涉及特定模块,比如通信模块或图形处理单元。单独转储该子系统的内存有助于缩小分析范围,提高效率。引用[2]提到在/data分区下发现的ramdump文件夹,里面有很多.elf文件,这说明实际应用中ramdump会生成特定格式的文件供分析。 关于如何使用,引用[4]提到了通过命令触发dump,比如使用echo c > /proc/sysrq-trigger。不过这可能适用于整个系统。对于子系统,可能需要特定的触发方式,比如AT命令,如引用[1]中的at+qcfg="dumpenable",1来使能dump功能。用户可能需要配置相关参数,确保存储空间足够,引用[2]指出存储空间不足的问题,所以使用前需检查存储空间。 另外,生成subsystem_ramdump的步骤可能包括配置触发条件、执行触发操作、收集和分析dump文件。需要确保系统支持该功能,并且有足够的权限和工具进行分析。 可能还需要考虑不同子系统对应的不同命令或配置,以及如何解析生成的elf文件。例如,使用工具如crash或gdb来分析这些文件,帮助开发者定位问题根源。 总结,subsystem_ramdump主要用于捕获特定子系统的内存状态,帮助诊断崩溃原因,使用步骤包括配置、触发、收集和分析。同时要注意存储空间和权限问题。</think>### subsystem_ramdump 的概念与用途 **subsystem_ramdump** 是系统或子系统(如调制解调器、图形处理器等)发生严重错误(如崩溃、死锁)时,自动或手动触发的内存数据转储机制。其核心作用是为开发者提供异常发生时的内存快照,用于离线分析故障原因[^3]。 #### 核心作用 1. **精准定位子系统故障**:仅捕获特定子系统的内存数据(如通信模块、传感器控制单元),避免全系统转储的资源浪费。 2. **减少存储占用**:与全系统转储(通常数十GB)相比,子系统转储文件更小(如示例中单个文件约9.57GB[^2]),更适合嵌入式设备。 3. **兼容性分析**:通过对比不同版本子系统的转储文件(如新旧固件),可验证功能兼容性[^1]。 #### 使用流程 1. **配置使能** 通过AT指令激活转储功能(例如:`at+qcfg="dumpenable",1`),或修改内核参数: ```bash echo 1 > /sys/module/subsystem/parameters/enable_ramdump ``` 2. **触发转储** - **自动触发**:子系统崩溃时自动生成转储文件 - **手动触发**:通过调试接口强制生成 ```bash echo c > /proc/sysrq-trigger # 示例命令[^4] ``` 3. **文件提取** 转储文件通常存储在 `/data/ramdump/` 目录下,命名格式如 `ramdump_venus_2023-10-01_12-30-00.elf`[^2]。 4. **分析工具** 使用 `crash` 工具链或厂商提供的解析工具(如高通QRCT)分析ELF格式文件: ```bash crash vmlinux ramdump_venus_2023-10-01_12-30-00.elf ``` #### 典型问题处理 - **存储空间不足**:需确保 `/data` 分区预留至少10GB空间 - **转储失败**:检查子系统是否支持该功能,或尝试拉低PS_HOLD信号强制进入转储模式
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值