- 论坛徽章:
- 1
|
看了kdump - A kexec based dumping mechanism (Paper) - Vievek Goyal et al, OLS 2005这篇paper
简单做个总结
1. crash capture kernel的位置是配置时硬编码指定的,相应的production kernel启动时要通过crashkernel参数将对应内存保留出来
2. crash capture kernel可以直接加载到保留内存区域,准备崩溃时派上用场
3. crash capture kernel的大小有个限制,kexec工具通过memmap=exactmap参数限制capture kernel的大小,该操作是自动进行的,
用户不需要关心
这样就可以根据保留区域的起始位置和内核大小判断出backup region的位置
4. crash capture kernel启动时并没有关闭设备,这表示DMA可能还在运行,为避免冲突,不使用前16MB启动crash capture内核
但是还需要前640KB的信息,这部分信息会复制到backup region
具体何时复制并不是太清楚,但是由于production kernel配置了kexec支持,又使用了crashkernel参数,又知道crash kernel大小的上限,
这就可以计算出backup region的位置,可以在系统启动后就先将启动需要的系统信息等复制到backup region;但是论文中描述的backup region大小至少为16M
(参考2.2A Brief History of Kdump Development),要是在系统启动时就复制会丢失掉系统崩溃时的该部分的信息;前1MB的物理布局不是太清楚,
猜想虽然linux启动时覆盖一部分,但是启动需要的那部分关于系统硬件的信息没有被破坏,后来也没有被覆盖,因此可以在系统崩溃时复制。实际根据论文中3.3节
3.3 Post Crash Processing的描述,复制到backup region应该是在系统崩溃后进行的
5. kexec使用的内存不必连续,但是/proc/vmcore使用的内存要求连续,这样kdump使用的也就是连续内存了
6. CPU寄存器信息以ELF note section format存放,每个CPU状态信息占用1KB
7. 崩溃时系统执行关闭操作
->保存CPU状态(每个CPU占用1KB)
->purgatory代码进行完整性检测并复制前640KB信息到backup region
->capture kernel执行
这里感觉论文中描述的有些混乱,前面讲要复制16MB,后面又只提到复制前640KB(3.3 Post Crash Processing)。姑且理解为着重强调吧
8. 系统映像编码为ELF Core Header进行保存,这样既压缩了存储,又便于根据ELF格式信息进行调试
9. ELF core header包含处理器寄存器信息、RAM布局信息和backup region;RAM布局信息从/proc/iomem中获取
类型PT_LOAD的header描述内存信息,包括物理内存布局和线性区域的信息
PT_NOTE类型的header描述CPU状态信息
PT_LOAD类型的header描述backup region信息
(kdump时系统好像变忙了,估计要对内核映像和内存信息进行细致分析;具体这部分信息如何构造估计要好好看看实现代码了。
我这里只是为了了解kdump的工作流程,哪位要是了解可以给讲讲)
10. crash capture kernel启动后获取保留的映像信息,可以通过/proc/vmcore或者/dev/oldmem访问
[ 本帖最后由 openspace 于 2009-12-21 18:24 编辑 ] |
|