Solaris學習筆記(5)
作者: Badcoffee
Email: [email protected]
Blog: http://blog.csdn.net/yayong
2007年2月
本文介紹使用kmdb和mdb調試Solaris內核的基本方法，kmdb和mdb是Solaris默認安裝的內核模塊調試器，可以用於調試和定位內核模塊及驅動程序發生的錯誤。本文僅用於學習交流目的，錯誤再所難免，如果有勘誤或疑問請與作者聯繫。
關鍵詞：mdb/kmdb/panic/hung/crashdump/dump/kernel debug/Solaris/OpenSolaris
事後分析(Postmortem Debug)是目前主流的商業操作系統支持的特性之一，windows, Aix, Freebsd都支持CrashDump及事後分析，最近Linux也逐漸加入了Crashdump和分析工具的支持。瞭解內核開發的人都知道，很多內核的bug都是很難重現，或者說，是在某個特定條件下，在一個微小的時間窗口內纔可以重現；另外，在重要的商業客戶的生產環境中，不大可能提供給內核程序員調試這類crash或者hung的機會，因此，在客戶提供crash dump文件基礎上，進行事後分析就成了解決此類問題的唯一途徑。
內核開發，測試甚至使用中可能會遇到以下兩類極端情況：
系統crash － 例如，Windows的藍屏，Unix的panic，Linux的opps；
系統hung - 例如，大家通常說的死機；
1. 系統Crash的分類
System panics & bad traps
Watchdog resets
Dropping out (to boot PROM or bootstrap level)
關於Panic
1. 爲保證數據完整性，避免系統進入不可預知的錯誤，系統會panic()
2. panic()只會在內核空間調用，用戶程序觸發panic是可能的，但是隻是觸發而已。
3.系統也會因爲檢測到硬件不應該進入某種狀態而panic()，叫bad trap.
panic()的主要工作
1.dump內存到device(缺省是swap區).
2.dump CPU的所有寄存器到device.
3.重新啓動.
panic的過程包括
1. 打印實際panic的消息
2. 打印調用棧的backtrace
3. 內存Dump的消息
4. 嘗試Reboot
2. 關於hung
系統hung的分類
1. 死鎖(deadlock)問題
2. 系統資源耗盡
3. 硬件問題
發生hung怎麼辦？
1. 確認hung的現象，網絡服務/ping/console/是否可用？
2. 嘗試產生一個Crash Dump
如何產生Crash Dump?
1. SPARC系統下，嘗試激活OBP用sync命令產生crash dump;
2. x86系統如果啓動時加載了kmdb，可以激活kmdb產生crash dump;
x86上如何設置啓動時加載kmdb?
有兩種方法：
1. 修改grub的設置，加上 "-k", 然後reboot
# vi /boot/grub/menu.lst#---------- ADDED BY BOOTADM - DO NOT EDIT ----------title Solaris 10 11/06 X86root (hd0,0,a)kernel /platform/i86pc/multiboot -kmodule /platform/i86pc/boot_archive#---------------------END BOOTADM--------------------2.或者在啓動後，退到console模式，運行如下命令：
Welcome to kmdb
kmdb: unable to determine terminal type: assuming `vt100'
Loaded modules: [ crypto uppc ufs unix zfs krtld s1394 sppp nca uhci lofs
genunix ip usba specfs pcplusmp nfs random sctp cpu.AuthenticAMD.15 ]
[2]> :c
進入kmdb後，內核陷入斷點，要用:c來恢復系統運行。
x86下如何激活kmdb併產生crash dump？
kmdb如果已經加載，可以用SHIFT+F1+a通過鍵盤來激活;
如果console重定向到SP或者tip line，需要查一下發送break信號的字符序列；
kaif_enter+7: popfl
[3]>
出現提示符後，可以用$
nopanicdebug: 0 = 0x1
panic[cpu3]/thread=c29b9de0: BAD TRAP: type=e (#pf Page fault) rp=c29d9f1c addr=0 occurred in module "" due to a
NULL pointer dereference
sched: #pf Page fault
Bad kernel fault at addr=0x0
pid=0, pc=0x0, sp=0x202, eflags=0x10002
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>
cr2: 0 cr3: 1238c000
gs: 1b0 fs: 0 es: 160 ds: 160
edi: c22e0c80 esi: 20 ebp: c29d9f6c esp: c29d9f54
ebx: f9 edx: 0 ecx: c22e0c11 eax: fec8b7b0
trp: e err: 10 eip: 0 cs: 158
efl: 10002 usp: 202 ss: c29d9f74
c29d9e7c unix:die+a7 (e, c29d9f1c, 0, 3)
c29d9f08 unix:trap+1058 (c29d9f1c, 0, 3)
c29d9f1c unix:cmntrap+9a (1b0, 0, 160, 160, c)
c29d9f6c 0 (c29d9f7c, fe813ced,)
c29d9f74 genunix:kdi_dvec_enter+a (c29d9f88, fe813c8f,)
c29d9f7c unix:debug_enter+32 (0)
c29d9f88 unix:abort_sequence_enter+27 (0)
c29d9fb0 asy:async_rxint+1eb (c19c3d00, f9)
c29d9fd4 asy:asyintr+97 (c19c3d00, 0)
c29b9d5c unix:cmnint+1f7 (c29b01b0, c1600000,)
c29b9db8 unix:cpu_halt+f6 (0, 0, c29b9dd8, fe8)
c29b9dc8 unix:idle+dc (0, 0)
c29b9dd8 unix:thread_start+8 ()
syncing file systems... done
dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
100% done: 182452 pages dumped, compression ratio 6.00, dump succeeded
rebooting...
3. 關於savecore
savecore - 啓動時將panic()例程存在dump device(swap區)上的image保存成文件，存在指定的文件系統的目錄上。
用dumpadm(1M)可以查看dump device和crash dump的保存路徑;
在/var/crash/下，可以看到以下幾類文件：
unix.X 和 vmunix.X － crash dump文件，其中X是數字，是dump文件的序號
bounds － 用來記錄序號，確定下一次dump的序號
4. 常用kmdb和mdb命令
大部分kmdb和mdb的命令是一樣的，事後分析就是用mdb來檢查crash dump文件，找到系統crash或者hung的原因。
分析crash dump的第一步就是收集必要的信息：
1. 主機名(hostname)和操作系統版本
::satus
::showrev
2. 系統硬件信息(hardware configuration)
::prtconf
3. 模塊或驅動信息
::modinfo
4. Crash時系統消息緩衝區的消息
該消息緩衝區是ring buffer，有很多有價值的信息，可以知道系統crash時或者之前很長一段時間的系統消息。
::msgbuf
進一步分析，可能需要查看以下幾方面
1. 調用棧的backtrace
$c
::stack
::stackregs
2. 內核符號表
::nm
3. 反彙編
<內核函數>::dis
4. CPU寄存器
::regs
5. 調度隊列(dispatch queue)
::cpuinfo -v
6. 物理內存及slab子系統
::memstat
::kmastat
7. 系統中所有進程
::ps
8. 所有內核線程
::threadlist
9. 線程狀態
::thread
10. 某個內核線程調用棧
::findstack -v
::walk thread |::findstack -v
11. 同步對象的狀態
::mutex
<讀寫鎖的地址>::rwlock
12. 地址引用查找
<地址>::kgrep
<地址>::whatthread
5. 案例分析
剛買了臺Dell OptiPlex 740，因爲solaris還不支持板載的1000M網卡，所以只好到www.broadcom.com去下載了一個bcme的驅動來用。幾天後，發現在家遠程訪問機器時，某個特定的操作會引起系統重啓，通過查看系統日誌發現時系統panic了；
在我的桌面機上，現在可以找到4次panic的crash dump文件：
Dump content: kernel pages
Dump device: /dev/dsk/c0d0s1 (swap)
Savecore directory: /var/crash/palace
Savecore enabled: yes
# cd /var/crash/palace
# ls
bounds unix.0 unix.1 unix.2 unix.3 vmcore.0 vmcore.1 vmcore.2 vmcore.3
用mdb打開其中一個(序號0的crash dump)來查看：
Loading modules: [ unix genunix specfs dtrace cpu.AuthenticAMD.15 uppc pcplusmp scsi_vhci ufs ip hook neti sctp arp usba fctl nca lofs zfs random sppp crypto ptm md cpc fcip fcp logindmux ipc nfs audiosup ]
首先，查看消息緩衝區，看panic之前發生了什麼：
> ::msgbufMESSAGEdtrace0 is /pseudo/dtrace@0pseudo-device: zfs0zfs0 is /pseudo/zfs@0pseudo-device: devinfo0devinfo0 is /pseudo/devinfo@0xsvc0 at root: space 0 offset 0xsvc0 is /xsvc@0,0pseudo-device: rsm0rsm0 is /pseudo/rsm@0pseudo-device: pseudo1pseudo1 is /pseudo/zconsnex@1pcplusmp: asy (asy) instance 0 vector 0x4 ioapic 0x2 intin 0x4 is bound to cpu 1ISA-device: asy0panic[cpu0]/thread=ffffff0003cb9c80:BAD TRAP: type=e (#pf Page fault) rp=ffffff0003cb9000 addr=86 occurred in module "genunix" due to a NULL pointer dereference.......................................................................................................................sched:#pf Page faultBad kernel fault at addr=0x86pid=0, pc=0xfffffffffba189ff, sp=0xffffff0003cb90f0, eflags=0x10286cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>cr2: 86 cr3: 2c00000 cr8: c rdi: 66 rsi: 9 rdx: 66 rcx: 9 r8: 180 r9: fffffffec02023c8 rax: 0 rbx: 18 rbp: ffffff0003cb9100 r10: 2000 r11: 1 r12: fffffffec1dc8fb0 r13: 18 r14: fffffffec1dc9298 r15: fffffffec1dc9288 fsb: 0 gsb: fffffffffbc292d0 ds: 4b es: 4b fs: 0 gs: 1c3 trp: e err: 0 rip: fffffffffba189ff cs: 30 rfl: 10286 rsp: ffffff0003cb90f0 ss: 38ffffff0003cb8ee0 unix:die+c8 ()ffffff0003cb8ff0 unix:trap+135c ()ffffff0003cb9000 unix:cmntrap+e9 ()ffffff0003cb9100 genunix:ddi_dma_unbind_handle+f ()ffffff0003cb91a0 bcme:bcme_tx_sctgth+305 ()ffffff0003cb91f0 bcme:UM_SendPacketIntel+56 ()ffffff0003cb9230 bcme:UM_SendMBLKPacket+f2 ()ffffff0003cb9280 bcme:UM_SendPacketsMP+91 ()ffffff0003cb92a0 bcme:UM_ProcessSendPackets+66 ()ffffff0003cb92d0 bcme:UM_SendPacket+9e ()ffffff0003cb92f0 bcme:t3TxPacket+bb ()ffffff0003cb9320 bcme:bcme_wput+77 ()ffffff0003cb9390 unix:putnext+22b ()ffffff0003cb9470 ip:tcp_send_data+72a ()ffffff0003cb95a0 ip:tcp_send+a7b ()ffffff0003cb9680 ip:tcp_wput_data+77f ()ffffff0003cb97e0 ip:tcp_rput_data+2b99 ()ffffff0003cb9820 ip:tcp_input+4a ()ffffff0003cb98a0 ip:squeue_enter_chain+11d ()ffffff0003cb9990 ip:ip_input+96f ()ffffff0003cb99e0 ip:ip_rput+119 ()ffffff0003cb9a50 unix:putnext+22b ()ffffff0003cb9ac0 bcme:t3SendUp+2dd ()ffffff0003cb9ae0 bcme:t3ProcessRxPacket+98 ()ffffff0003cb9b10 bcme:bcme_recv+87 ()ffffff0003cb9b40 bcme:LM_RxPackets_Service+56 ()ffffff0003cb9b60 bcme:LM_ISR_ServiceSoftInt+29 ()ffffff0003cb9bc0 bcme:bcme_intr+30e ()ffffff0003cb9c20 unix:av_dispatch_autovect+78 ()ffffff0003cb9c60 unix:dispatch_hardint+2f ()ffffff0003c05ac0 unix:switch_sp_and_call+13 ()ffffff0003c05b10 unix:do_interrupt+9b ()ffffff0003c05b20 unix:cmnint+ba ()ffffff0003c05c10 unix:mach_cpu_idle+6 ()ffffff0003c05c40 unix:cpu_idle+c8 ()ffffff0003c05c60 unix:idle+10e ()ffffff0003c05c70 unix:thread_start+8 ()syncing file systems... 4 donedumping to /dev/dsk/c0d0s1, offset 860356608, content: kernel可以從panic的調用棧看出，這個panic和網絡有關，涉及的模塊有unix, bcme, ip, genunix；
操作系統版本：
Hostname: palace
Release: 5.11
Kernel architecture: i86pc
Application architecture: amd64
Kernel version: SunOS 5.11 i86pc snv_57
Platform: i86pc
我們知道，這臺機器是amd64 CPU, 操作系統是Solaris 11 build 57.
因爲bcme是硬件驅動，因此下面的信息有助於我們瞭解驅動的基本情況；
網卡信息(通過vendor id和device id: pciex14e4,167a, 可以查到網卡具體型號)：
fffffffec01f09b0 pciex14e4,167a, instance #0 (driver name: bcme)網卡驅動版本(v10.0.3)：
140 fffffffff7fd2000 1d3d0 1 bcme (Broadcom GbE Driver v10.0.3)
系統panic的消息已經告訴我們這是一個bad trap：
debugging crash dump vmcore.0 (64-bit) from palace
operating system: 5.11 snv_57 (i86pc)
panic message:
BAD TRAP: type=e (#pf Page fault) rp=ffffff0003cb9000 addr=86 occurred in module "genunix" due to a NULL pointer dereference
dump content: kernel pages only
這個bad trap實際上就是Page fault時，訪問了一個NULL指針，而且addr=86，已經很明顯不是一個合法的地址。
讓我們驗證一下，首先，查看調用棧的詳細信息：
ffffff0003cb9100 ddi_dma_unbind_handle+0xf(66)
ffffff0003cb91a0 bcme_tx_sctgth+0x305()
ffffff0003cb91f0 UM_SendPacketIntel+0x56()
ffffff0003cb9230 UM_SendMBLKPacket+0xf2()
ffffff0003cb9280 UM_SendPacketsMP+0x91()
ffffff0003cb92a0 UM_ProcessSendPackets+0x66()
ffffff0003cb92d0 UM_SendPacket+0x9e()
ffffff0003cb92f0 t3TxPacket+0xbb()
ffffff0003cb9320 bcme_wput+0x77()
ffffff0003cb9390 putnext+0x22b(fffffffec1954638, fffffffee22bf300)
ffffff0003cb9470 tcp_send_data+0x72a(fffffffec82452c0, fffffffee21e3650, fffffffee22bf300)
ffffff0003cb95a0 tcp_send+0xa7b(fffffffee21e3650, fffffffec82452c0, 4ec, 28, 14, 0, ffffff0003cb965c, ffffff0003cb9660,
ffffff0003cb9664, ffffff0003cb9618, 13a00be, 7fffffff)
ffffff0003cb9680 tcp_wput_data+0x77f(fffffffec82452c0, 0, 0)
ffffff0003cb97e0 tcp_rput_data+0x2b99(fffffffec82450c0, fffffffee2240f80, fffffffec1563f00)
ffffff0003cb9820 tcp_input+0x4a(fffffffec82450c0, fffffffee2240f80, fffffffec1563f00)
ffffff0003cb98a0 squeue_enter_chain+0x11d(fffffffec1563f00, fffffffee2240f80, fffffffee2240f80, 1, 1)
ffffff0003cb9990 ip_input+0x96f(fffffffec1b9f428, 0, fffffffee2240f80, 0)
ffffff0003cb99e0 ip_rput+0x119(fffffffec1954540, fffffffee2240f80)
ffffff0003cb9a50 putnext+0x22b(fffffffec19547d0, fffffffee2240f80)
ffffff0003cb9ac0 t3SendUp+0x2dd()
ffffff0003cb9ae0 t3ProcessRxPacket+0x98()
ffffff0003cb9b10 bcme_recv+0x87()
ffffff0003cb9b40 LM_RxPackets_Service+0x56()
ffffff0003cb9b60 LM_ISR_ServiceSoftInt+0x29()
ffffff0003cb9bc0 bcme_intr+0x30e()
ffffff0003cb9c20 av_dispatch_autovect+0x78(10)
ffffff0003cb9c60 dispatch_hardint+0x2f(10, 0)
ffffff0003c05ac0 switch_sp_and_call+0x13()
ffffff0003c05b10 do_interrupt+0x9b(ffffff0003c05b20, 1)
ffffff0003c05b20 _interrupt+0xba()
ffffff0003c05c10 mach_cpu_idle+6()
ffffff0003c05c40 cpu_idle+0xc8()
ffffff0003c05c60 idle+0x10e()
ffffff0003c05c70 thread_start+8()
mdb不但打出了函數名，而且有些函數的參數都得到了，其中ddi_dma_unbind_handle的參數是0x66，panic時，系統正在執行的指令時ddi_dma_unbind_handle+0xf，我們可以反彙編這個函數看看該指令是什麼？
> ddi_dma_unbind_handle::dis
ddi_dma_unbind_handle: pushq %rbp
ddi_dma_unbind_handle+1: movq %rsp,%rbp
ddi_dma_unbind_handle+4: subq $0x10,%rsp
ddi_dma_unbind_handle+8: movq %rdi,-0x8(%rbp)
ddi_dma_unbind_handle+0xc: movq %rdi,%rdx
ddi_dma_unbind_handle+0xf: movq 0x20(%rdx),%rsi
ddi_dma_unbind_handle+0x13: movq 0x98(%rsi),%rdi
ddi_dma_unbind_handle+0x1a: xorl %eax,%eax
ddi_dma_unbind_handle+0x1c: call *0xe8(%rsi)
ddi_dma_unbind_handle+0x22: leave
ddi_dma_unbind_handle+0x23: ret
反彙編的結果有時會比較難看懂，好在OpenSolaris已經開放源代碼了，我們可以對照代碼：
ddi_dma_unbind_handle(ddi_dma_handle_t h)
{
ddi_dma_impl_t *hp = (ddi_dma_impl_t *)h;
dev_info_t *hdip, *dip;
int (*funcp)(dev_info_t *, dev_info_t *, ddi_dma_handle_t);
dip = hp->dmai_rdip;
hdip = (dev_info_t *)DEVI(dip)->devi_bus_dma_unbindhdl;
funcp = DEVI(dip)->devi_bus_dma_unbindfunc;
return ((*funcp)(hdip, dip, h));
}
不難看出，ddi_dma_unbind_handle+0xf指令正是以下這行，訪問dmai_rdip成員的語句：
dip = hp->dmai_rdip;
可以用mdb驗證一下：
offsetof (ddi_dma_impl_t, dmai_rdip) = 0x20
ddi_dma_unbind_handle+0xf對應的指令是：
ddi_dma_unbind_handle+0xf: movq 0x20(%rdx),%rsi
%rdx寄存器的值可以從以下命令得到：
%rax = 0x0000000000000000 %r9 = 0xfffffffec02023c8
%rbx = 0x0000000000000018 %r10 = 0x0000000000002000
%rcx = 0x0000000000000009 %r11 = 0x0000000000000001
%rdx = 0x0000000000000066 %r12 = 0xfffffffec1dc8fb0
%rsi = 0x0000000000000009 %r13 = 0x0000000000000018
%rdi = 0x0000000000000066 %r14 = 0xfffffffec1dc9298
%r8 = 0x0000000000000180 %r15 = 0xfffffffec1dc9288
%rip = 0xfffffffffba189ff ddi_dma_unbind_handle+0xf
%rbp = 0xffffff0003cb9100
%rsp = 0xffffff0003cb90f0
%rflags = 0x00010286
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
status=<of,df,IF,tf,SF,zf,af,PF,cf>
%cs = 0x0030 %ds = 0x004b %es = 0x004b
%trapno = 0xe %fs = 0x0000 %gs = 0x01c3
%err = 0x0
所以ddi_dma_unbind_handle+0xf指令實際上是去訪問0x20(%rdx)對應的地址而發生的bad trap, 即addr=88:
mdb: failed to read data from target: no mapping for address
0x86:
再看一下ddi_dma_unbind_handle(9F)裏的說明，這個函數幾乎是所有的使用dma的驅動都需要用到的：
NAME
ddi_dma_unbind_handle - unbinds the address in a DMA handle
SYNOPSIS
#include <sys/ddi.h>
#include <sys/sunddi.h>
int ddi_dma_unbind_handle(ddi_dma_handle_t handle);
PARAMETERS
handle The DMA handle previously allocated by a call to
ddi_dma_alloc_handle(9F).
可見，在bcme驅動調用ddi_dma_unbind_handle時，傳遞的handle可能已經被釋放，或者是一個非法的地址，可惜我沒有 bcme驅動的源代碼，不然也許可以進一步定位錯誤，因爲雖然mdb沒有自動找到bcme函數的參數，但是因爲我們有bcme的棧指針，或許可以從棧中找到已經被保存的函數參數，當然，這要對AMD64的ABI比較熟悉：
0xffffff0003cb90f0:
0xffffff0003cb90f0: 0xfffffffff7fe9d38
0xffffff0003cb90f8: 0x66
0xffffff0003cb9100: 0xffffff0003cb91a0
0xffffff0003cb9108: bcme_tx_sctgth+0x305
0xffffff0003cb9110: 0xfffffffee22bf300
0xffffff0003cb9118: 0x522
0xffffff0003cb9120: 0xfffffffec1dab000
0xffffff0003cb9128: 0xfffffffec1dc8fb0
0xffffff0003cb9130: 0
0xffffff0003cb9138: QQ_PushTail+0x57
0xffffff0003cb9140: 0xfffffffec1db39e0
0xffffff0003cb9148: 0x48a22ddc
0xffffff0003cb9150: 0x28
0xffffff0003cb9158: 0xbaddcafe00000000
0xffffff0003cb9160: 0xffffff0003cb91a0
0xffffff0003cb9168: 0x522f7fe488d
0xffffff0003cb9170: 0xfffffffee22c8880
0xffffff0003cb9178: 0xfffffffee22b6ddc
0xffffff0003cb9180: 0xfffffffec1db3d68
0xffffff0003cb9188: 0x28
0xffffff0003cb9190: 0xfffffffec1dab000
0xffffff0003cb9198: 0x3c
0xffffff0003cb91a0: 0xffffff0003cb91f0
0xffffff0003cb91a8: UM_SendPacketIntel+0x56
0xffffff0003cb91b0: 0xfffffffec1dab000
0xffffff0003cb91b8: 0xfffffffee22bf300
0xffffff0003cb91c0: 0
0xffffff0003cb91c8: 0x3c
0xffffff0003cb91d0: 0x522
0xffffff0003cb91d8: 0x3c
0xffffff0003cb91e0: 0x522
0xffffff0003cb91e8: 0xfffffffec1dab040
0xffffff0003cb91f0: 0xffffff0003cb9230
0xffffff0003cb91f8: UM_SendMBLKPacket+0xf2
0xffffff0003cb9200: 0xfffffffec1db3f30
0xffffff0003cb9208: 0xfffffffec1dab000
0xffffff0003cb9210: 0xfffffffee22bf300
0xffffff0003cb9218: 0xfffffffee22bf300
0xffffff0003cb9220: 0xfffffffec1db39f0
0xffffff0003cb9228: 0xfffffffee3be9600
0xffffff0003cb9230: 0xffffff0003cb9280
0xffffff0003cb9238: UM_SendPacketsMP+0x91
0xffffff0003cb9240: 0xfffffffec1954638
0xffffff0003cb9248: 0xfffffffee22bf300
0xffffff0003cb9250: 0xfffffffec1dab000
0xffffff0003cb9258: 0xfffffffec1db3f20
0xffffff0003cb9260: 0xfffffffee22bf300
即使沒有源代碼，我們也知道，這是bcme驅動的一個bug，我會設法聯繫broadcom公司的人報告一個bug，並且我可以提供crash dump文件供他們分析和解決這個問題。