关于kdb重入， Debugger re-entered的问题

cuic139

最近kdb经常出现重入然后卡死的情况，信息如下：

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（）函数里面又panic了，结果在debugger情况下又再次debugger了，

请教这种情况下该如何处理呢，正常情况下是会出现kdb重入的，不过几率非常小，可是在我这里比如在sys_mkdir函数下了一个断点，

然后执行mkdir命令会进入断点，然后go出来就会出现上面的信息，这样就不正常了，有什么办法解决呢？

cuic139

莫有人回答吗？个人感觉在有一个cpu进入kdb后，会调用smp_kdb_stop给其他cpu发核间中断ipi通知其他cpu，阻止出现重入情况，不知为何还会这样，按理说kdb肯定考虑了smp的情况呀

linuxfellow

我自己也试了一下kdb,发现很不好用，尤其是多线程pthread处理得很不好，没有再用。

cuic139

回复 3# linuxfellow 你用的是什么版本的内核，我用的是2.6.39，sgi上只有一个给3.0的patch。。。凑合patch上了结果在多核环境下一进入断点或者是单步执行就会出现重入reenter的情况，分析了好几天源码，觉得是在kdb的处理函数里，断点和单步的情况下没有进给其他cpu发送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.         }

复制代码

cuic139

和smp多核似乎也没关系，单cpu的情况下如果断点进入也会出现相同的cpu重入的情况，把debug信息截图传上来了，是在正常的kdb函数结束之后，又有一个do_debug函数调了kdb函数，就是截图里面取反色的那块地方，还是没搞懂

cuic139

太坑爹了。。。sgi出的这个3.0的patch估计有问题，以前的patch打上去就能用了。。。单步、断点、smp什么的也都没问题

linuxfellow

cuic139 发表于 2012-02-08 11:51
太坑爹了。。。sgi出的这个3.0的patch估计有问题，以前的patch打上去就能用了。。。单步、断点、smp什么的也 ...

我没有象你这样执著地试kgb. 小试一下就放弃了。选择了高低两套：
高端用Lauterbach的PowerTrace 7660
低端直接用Gnu GDB
Lauterbach的debugger用得很好
Gnu GDB始终没解决pthread跟踪问题，还得花点时间； 毕竟免费，用起来也方便；一直想花时间，解决多线程debugger问题，只是头绪太多,不曾得闲。

最近公司嫌Lauterbach太贵，开始考虑mentor graphics的debugger

cuic139

回复 7# linuxfellow kdb调好了。。。是寄存器的问题 Lauterbach的PowerTrace 7660这款我看了一下，这个东西可以调内核吗？尤其是对于没有图形界面的操作系统，mentor graphics的那个应该也是调试嵌入式应用程序的吧，我这苦于要调试内核，kgdb需要双机而且还要加调试信息重新编译，只能用kdb，好在调好了，这个应该是sgi和linux内核的兼容性不太好，有两个寄存器的值取错了。。。唉，浪费了一礼拜的时间。。。


   

linuxfellow

cuic139 发表于 2012-02-09 17:13
回复 7# linuxfellow kdb调好了。。。是寄存器的问题 Lauterbach的PowerTrace 7660这款我看了一下，这 ...

我主要是作嵌入式，所看的debugger都是嵌入式开发。Lauterbach让整个processor单步运行，它会让所有进程都单步运行。
你用过GDB调试pthread吗， 我自己GDB多线程调试一直不顺利。还有你用kdb试试多线程debug一下，看能否在不同thread之间正常转换？ 当时我就是因为这个原因放弃的