關(guān)于kdb重入， Debugger re-entered的問題

cuic139

最近kdb經(jīng)常出現(xiàn)重入然后卡死的情況，信息如下：

kdb: Debugger re-entered on cpu 1, new reason = 1
Not executing a kdb command
No longjmp available for recovery
Cannot recover, allowing event to proceed

其實就是在kdb（）函數(shù)里面又panic了，結(jié)果在debugger情況下又再次debugger了，

請教這種情況下該如何處理呢，正常情況下是會出現(xiàn)kdb重入的，不過幾率非常小，可是在我這里比如在sys_mkdir函數(shù)下了一個斷點，

然后執(zhí)行mkdir命令會進入斷點，然后go出來就會出現(xiàn)上面的信息，這樣就不正常了，有什么辦法解決呢？

cuic139

莫有人回答嗎？個人感覺在有一個cpu進入kdb后，會調(diào)用smp_kdb_stop給其他cpu發(fā)核間中斷ipi通知其他cpu，阻止出現(xiàn)重入情況，不知為何還會這樣，按理說kdb肯定考慮了smp的情況呀

linuxfellow

我自己也試了一下kdb,發(fā)現(xiàn)很不好用，尤其是多線程pthread處理得很不好，沒有再用。

cuic139

回復(fù) 3# linuxfellow 你用的是什么版本的內(nèi)核，我用的是2.6.39，sgi上只有一個給3.0的patch。。。湊合patch上了結(jié)果在多核環(huán)境下一進入斷點或者是單步執(zhí)行就會出現(xiàn)重入reenter的情況，分析了好幾天源碼，覺得是在kdb的處理函數(shù)里，斷點和單步的情況下沒有進給其他cpu發(fā)送ipi中斷的處理流程，但是代碼里寫的好像就是不該進入。。。也不知道問誰，CU的大神們，求救

1.         if (smp_processor_id() == lkdb_initial_cpu &&
   
2.           !KDB_STATE(DOING_SS) &&
   
3.           !KDB_STATE(RECURSE)) {
   
4.                 /*
   
5.                  * (Re)install the global breakpoints and cleanup the cached
   
6.                  * symbol table.  This is only done once from the initial
   
7.                  * processor on go.
   
8.                  */
   
9.                 KDB_DEBUG_STATE("kdb 12", reason);
   
10.                 if (!kdb_quiet(reason) || smp_processor_id() == 0) {
    
11.                         lkdb_bp_install_global(regs);
    
12.                         lkdbnearsym_cleanup();
    
13.                         ldebug_kusage();
    
14.                 }
    
15.                 if (!KDB_STATE(GO1)) {
    
16.                         /*
    
17.                          * Release all other cpus which will see KDB_STATE(LEAVING) is set.
    
18.                          */
    
19.                         int i;
    
20.                         for (i = 0; i < NR_CPUS; ++i) {
    
21.                                 if (KDB_STATE_CPU(KDB, i))
    
22.                                         KDB_STATE_SET_CPU(LEAVING, i);
    
23.                                 KDB_STATE_CLEAR_CPU(WAIT_IPI, i);
    
24.                                 KDB_STATE_CLEAR_CPU(HOLD_CPU, i);
    
25.                         }
    
26.                         /* Wait until all the other processors leave kdb */
    
27.                         while (kdb_previous_event() != 1)
    
28.                                 ;
    
29.                         if (!kdb_quiet(reason))
    
30.                                 notify_die(DIE_KDEBUG_LEAVE, "KDEBUG LEAVE", regs, error, 0, 0);
    
31.                         lkdb_initial_cpu = -1;        /* release kdb control */
    
32.                         KDB_DEBUG_STATE("kdb 13", reason);
    
33.                 }
    
34.         }

復(fù)制代碼

cuic139

和smp多核似乎也沒關(guān)系，單cpu的情況下如果斷點進入也會出現(xiàn)相同的cpu重入的情況，把debug信息截圖傳上來了，是在正常的kdb函數(shù)結(jié)束之后，又有一個do_debug函數(shù)調(diào)了kdb函數(shù)，就是截圖里面取反色的那塊地方，還是沒搞懂

cuic139

太坑爹了。。。sgi出的這個3.0的patch估計有問題，以前的patch打上去就能用了。。。單步、斷點、smp什么的也都沒問題

linuxfellow

cuic139 發(fā)表于 2012-02-08 11:51
太坑爹了。。。sgi出的這個3.0的patch估計有問題，以前的patch打上去就能用了。。。單步、斷點、smp什么的也 ...

我沒有象你這樣執(zhí)著地試kgb. 小試一下就放棄了。選擇了高低兩套：
高端用Lauterbach的PowerTrace 7660
低端直接用Gnu GDB
Lauterbach的debugger用得很好
Gnu GDB始終沒解決pthread跟蹤問題，還得花點時間； 畢竟免費，用起來也方便；一直想花時間，解決多線程debugger問題，只是頭緒太多,不曾得閑。

最近公司嫌Lauterbach太貴，開始考慮mentor graphics的debugger

cuic139

回復(fù) 7# linuxfellow kdb調(diào)好了。。。是寄存器的問題 Lauterbach的PowerTrace 7660這款我看了一下，這個東西可以調(diào)內(nèi)核嗎？尤其是對于沒有圖形界面的操作系統(tǒng)，mentor graphics的那個應(yīng)該也是調(diào)試嵌入式應(yīng)用程序的吧，我這苦于要調(diào)試內(nèi)核，kgdb需要雙機而且還要加調(diào)試信息重新編譯，只能用kdb，好在調(diào)好了，這個應(yīng)該是sgi和linux內(nèi)核的兼容性不太好，有兩個寄存器的值取錯了。。。唉，浪費了一禮拜的時間。。。


   

linuxfellow

cuic139 發(fā)表于 2012-02-09 17:13
回復(fù) 7# linuxfellow kdb調(diào)好了。。。是寄存器的問題 Lauterbach的PowerTrace 7660這款我看了一下，這 ...

我主要是作嵌入式，所看的debugger都是嵌入式開發(fā)。Lauterbach讓整個processor單步運行，它會讓所有進程都單步運行。
你用過GDB調(diào)試pthread嗎， 我自己GDB多線程調(diào)試一直不順利。還有你用kdb試試多線程debug一下，看能否在不同thread之間正常轉(zhuǎn)換？ 當(dāng)時我就是因為這個原因放棄的