- 論壇徽章:
- 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可以直接加載到保留內存區(qū)域，準備崩潰時派上用場
3. crash capture kernel的大小有個限制，kexec工具通過memmap=exactmap參數限制capture kernel的大小，該操作是自動進行的，
用戶不需要關心
這樣就可以根據保留區(qū)域的起始位置和內核大小判斷出backup region的位置
4. crash capture kernel啟動時并沒有關閉設備，這表示DMA可能還在運行，為避免沖突，不使用前16MB啟動crash capture內核
但是還需要前640KB的信息，這部分信息會復制到backup region
具體何時復制并不是太清楚，但是由于production kernel配置了kexec支持，又使用了crashkernel參數，又知道crash kernel大小的上限，
這就可以計算出backup region的位置，可以在系統(tǒng)啟動后就先將啟動需要的系統(tǒng)信息等復制到backup region；但是論文中描述的backup region大小至少為16M
（參考2.2A Brief History of Kdump Development），要是在系統(tǒng)啟動時就復制會丟失掉系統(tǒng)崩潰時的該部分的信息；前1MB的物理布局不是太清楚，
猜想雖然linux啟動時覆蓋一部分，但是啟動需要的那部分關于系統(tǒng)硬件的信息沒有被破壞，后來也沒有被覆蓋，因此可以在系統(tǒng)崩潰時復制。實際根據論文中3.3節(jié)
3.3 Post Crash Processing的描述，復制到backup region應該是在系統(tǒng)崩潰后進行的
5. kexec使用的內存不必連續(xù)，但是/proc/vmcore使用的內存要求連續(xù)，這樣kdump使用的也就是連續(xù)內存了
6. CPU寄存器信息以ELF note section format存放，每個CPU狀態(tài)信息占用1KB
7. 崩潰時系統(tǒng)執(zhí)行關閉操作
->保存CPU狀態(tài)（每個CPU占用1KB）
->purgatory代碼進行完整性檢測并復制前640KB信息到backup region
->capture kernel執(zhí)行
這里感覺論文中描述的有些混亂，前面講要復制16MB，后面又只提到復制前640KB（3.3 Post Crash Processing）。姑且理解為著重強調吧
8. 系統(tǒng)映像編碼為ELF Core Header進行保存，這樣既壓縮了存儲，又便于根據ELF格式信息進行調試
9. ELF core header包含處理器寄存器信息、RAM布局信息和backup region；RAM布局信息從/proc/iomem中獲取
類型PT_LOAD的header描述內存信息，包括物理內存布局和線性區(qū)域的信息
PT_NOTE類型的header描述CPU狀態(tài)信息
PT_LOAD類型的header描述backup region信息
（kdump時系統(tǒng)好像變忙了，估計要對內核映像和內存信息進行細致分析；具體這部分信息如何構造估計要好好看看實現代碼了。
我這里只是為了了解kdump的工作流程，哪位要是了解可以給講講）
10. crash capture kernel啟動后獲取保留的映像信息，可以通過/proc/vmcore或者/dev/oldmem訪問
[ 本帖最后由 openspace 于 2009-12-21 18:24 編輯 ] |
|
免費注冊
發(fā)表于 2009-12-21 14:47
發(fā)表于 2010-01-03 11:02
