<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 12:06 PM, "“tiejun.chen”" <span dir="ltr"><<a href="mailto:tiejun.chen@windriver.com" target="_blank">tiejun.chen@windriver.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 01/21/2014 02:04 PM, Arun Chandran wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Mon, Jan 20, 2014 at 1:55 PM, "�tiejun.chen�"<br>
<<a href="mailto:tiejun.chen@windriver.com" target="_blank">tiejun.chen@windriver.com</a>><u></u>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 01/17/2014 03:52 PM, Arun Chandran wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
I am testing kgdb on freescale p2020 target.<br>
<br>
In target<br>
------------<br>
<br>
1)<br>
root@freescale-p2020ds:~# uname -a<br>
Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST 2014<br>
ppc GNU/Linux<br>
<br>
2)<br>
root@freescale-p2020ds:~# cat /proc/cpuinfo<br>
processor       : 0<br>
cpu             : e500v2<br>
clock           : 999.990008MHz<br>
revision        : 4.0 (pvr 8021 1040)<br>
bogomips        : 124.99<br>
<br>
processor       : 1<br>
cpu             : e500v2<br>
clock           : 999.990008MHz<br>
revision        : 4.0 (pvr 8021 1040)<br>
bogomips        : 124.99<br>
<br>
total bogomips  : 249.99<br>
timebase        : 62499376<br>
platform        : P2020 DS<br>
model           : fsl,P2020DS<br>
Memory          : 768 MB<br>
<br>
3)<br>
freescale-p2020ds:~# echo "ttyS1,115200" ><br>
/sys/module/kgdboc/parameters/<u></u>kgdoc<br>
<br>
4) I set up host (settings given below); Then I send   "SysRq : DEBUG"<br>
<br>
In host<br>
----------<br>
(gdb) target remote /dev/ttyS0<br>
Remote debugging using /dev/ttyS0<br>
kgdb_breakpoint () at kernel/debug/debug_core.c:1013<br>
1013 arch_kgdb_breakpoint();<br>
(gdb) b sys_sync<br>
Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.<br>
(gdb) c<br>
Continuing.<br>
<br>
I am able to take control in host; after that I am setting breakpoint at<br>
"sys_sync"<br>
<br>
In target<br>
------------<br>
root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
do<br>
sync<br>
done<br>
<br>
</blockquote>
<br>
In host<br>
----------<br>
Breakpoint 1, sys_sync () at fs/sync.c:103<br>
103 {<br>
(gdb) c<br>
Continuing.<br>
<br>
Breakpoint is hit only one time instead of 9 times; after that target<br>
hangs.<br>
<br>
</blockquote>
<br>
I recommend you try upstream to take a further look at this, instead of<br>
that Freescale distribution. As I recall currently KGDB works well in 85xx<br>
case in ML.<br>
</blockquote>
<br>
<br>
Many thanks for your suggestion.<br>
<br>
I tested the same thing on linux-3.12.y (<br>
<a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs%2Ftags%2Fv3.12.8&h=linux-3.12.y" target="_blank">https://git.kernel.org/cgit/<u></u>linux/kernel/git/stable/linux-<u></u>stable.git/log/?id=refs%<u></u>2Ftags%2Fv3.12.8&h=linux-3.12.<u></u>y</a><br>

).<br>
<br>
</blockquote>
<br></div></div>
Please go powerpc tree,<br>
<br>
git clone git://<a href="http://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git" target="_blank">git.kernel.org/pub/scm/<u></u>linux/kernel/git/benh/powerpc.<u></u>git</a><br>
<br>
git checkout next<div class="im"><br></div></blockquote><div><br></div><div>Yes It works fine on that tree.. Seems my problem is solved by commit</div><div><a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/kernel/kgdb.c?id=8258e268c15a29c09d7c88d91a948bdf729433d8">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/kernel/kgdb.c?id=8258e268c15a29c09d7c88d91a948bdf729433d8</a><br>
</div><div><br></div><div>Thank you for the help.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
root@p2020ds:~# uname -a<br>
Linux freescale-p2020ds 3.12.8 #136 SMP Tue Jan 21 11:14:13 IST 2014 ppc<br>
GNU/Linux<br>
<br>
<br>
The breakpoint I placed at "sys_sync" is hit only once. After that my gdb<br>
command "continue" does not make further<br>
hits. And the target is hung. It is not even responding to my further<br>
sending of "SysRq : DEBUG"<br>
<br>
I have attached my .config<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Then i tried to send "SysRq : DEBUG" in target kernel panics.<br>
<br>
I have pasted the panic below.<br>
<br>
##############################<u></u>###########<br>
SysRq : DEBUG<br>
Kernel panic - not syncing: Recursive entry to debugger<br>
<br>
</blockquote>
<br>
The kernel already trap into kgdb_handle_exception() with the debug<br>
exception while triggering that break point, but again you trigger another<br>
debug exception by SysRq. Actually KGDB can't handle such this recursive<br>
behavior, so KGDB always call kgdb_reenter_check() to prevent this scenario<br>
with this call trace.<br>
<br>
<br>
</blockquote>
I am doing it because the target is hung after the initial breakpoint is<br>
hit.<br>
</blockquote>
<br></div>
This is just what I mean. Although looks your kernel is hung, actually your kernel is already in kgdb exception handler previously. So after you send break by SysRq to debug, its not allowed by current kgdb scheme as I said. The following call trace also show this path explicitly.<span class=""><font color="#888888"><br>

<br>
Tiejun</font></span><div class=""><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
static int kgdb_reenter_check(struct kgdb_state *ks)<br>
{<br>
         unsigned long addr;<br>
<br>
         if (atomic_read(&kgdb_active) != raw_smp_processor_id())<br>
                 return 0;<br>
         ...<br>
<br>
         if (exception_level > 1) {<br>
                 dump_stack();<br>
                 panic("Recursive entry to debugger");<br>
         }<br>
<br>
<br>
Tiejun<br>
<br>
  CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Call Trace:<br>
[effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)<br>
[effe5d50] [c0588878] panic+0xe4/0x224<br>
[effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/<u></u>0x1f8<br>
[effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/<u></u>0x80<br>
[effe5e00] [c057e7e0] program_check_exception+0x10c/<u></u>0x264<br>
[effe5e10] [c000f660] ret_from_except_full+0x0/0x4c<br>
--- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8<br>
      LR = __handle_sysrq+0x154/0x1cc<br>
[effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)<br>
[effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218<br>
[effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174<br>
[effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8<br>
[effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/<u></u>0x2a8<br>
[effe5fc0] [c00b5720] handle_irq_event+0x44/0x74<br>
[effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c<br>
[effe5ff0] [c000d58c] call_handle_irq+0x18/0x28<br>
[c4f91b10] [c0004f60] do_IRQ+0x150/0x224<br>
[c4f91b40] [c000f6ac] ret_from_except+0x0/0x18<br>
--- Exception: 501 at rpcauth_lookup_credcache+<u></u>0x138/0x2a4<br>
      LR = rpcauth_lookup_credcache+0xb8/<u></u>0x2a4<br>
[c4f91c00] [24002424] 0x24002424 (unreliable)<br>
[c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac<br>
[c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/<u></u>0x124<br>
[c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330<br>
[c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4<br>
[c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8<br>
[c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c<br>
[c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/<u></u>0x168<br>
[c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/<u></u>0x194<br>
[c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8<br>
[c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824<br>
[c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/<u></u>0x8c<br>
[c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c<br>
[c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4<br>
[c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44<br>
[c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c<br>
--- Exception: c01 at 0xff08a98<br>
      LR = 0xfed53e8<br>
CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6<br>
Call Trace:<br>
[effe5bb0] [c0008060] show_stack+0x4c/0x168 (unreliable)<br>
[effe5bf0] [c00b2cac] kgdb_handle_exception+0x1c4/<u></u>0x1f8<br>
[effe5c40] [c0010038] kgdb_handle_breakpoint+0x4c/<u></u>0x80<br>
[effe5c50] [c057e7e0] program_check_exception+0x10c/<u></u>0x264<br>
[effe5c60] [c000f660] ret_from_except_full+0x0/0x4c<br>
--- Exception: 700 at kgdb_panic_event+0x1c/0x3c<br>
      LR = notifier_call_chain+0x60/0xb0<br>
[effe5d20] [00000000]    (nil) (unreliable)<br>
[effe5d40] [c05819dc] __atomic_notifier_call_chain+<u></u>0x14/0x24<br>
[effe5d50] [c05888a8] panic+0x114/0x224<br>
[effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/<u></u>0x1f8<br>
[effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/<u></u>0x80<br>
[effe5e00] [c057e7e0] program_check_exception+0x10c/<u></u>0x264<br>
[effe5e10] [c000f660] ret_from_except_full+0x0/0x4c<br>
--- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8<br>
      LR = __handle_sysrq+0x154/0x1cc<br>
[effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)<br>
[effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218<br>
[effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174<br>
[effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8<br>
[effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/<u></u>0x2a8<br>
[effe5fc0] [c00b5720] handle_irq_event+0x44/0x74<br>
[effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c<br>
[effe5ff0] [c000d58c] call_handle_irq+0x18/0x28<br>
[c4f91b10] [c0004f60] do_IRQ+0x150/0x224<br>
[c4f91b40] [c000f6ac] ret_from_except+0x0/0x18<br>
--- Exception: 501 at rpcauth_lookup_credcache+<u></u>0x138/0x2a4<br>
      LR = rpcauth_lookup_credcache+0xb8/<u></u>0x2a4<br>
[c4f91c00] [24002424] 0x24002424 (unreliable)<br>
[c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac<br>
[c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/<u></u>0x124<br>
[c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330<br>
[c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4<br>
[c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8<br>
[c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c<br>
[c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/<u></u>0x168<br>
[c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/<u></u>0x194<br>
[c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8<br>
[c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824<br>
[c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/<u></u>0x8c<br>
[c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c<br>
[c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4<br>
[c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44<br>
[c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c<br>
--- Exception: c01 at 0xff08a98<br>
      LR = 0xfed53e8<br>
<br>
<br>
##############################<u></u>##########################<br>
<br>
Could you please share your thoughts on this issue?<br>
<br>
I have also attached my kernel .config.<br>
<br>
Regards,<br>
Arun C<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Linuxppc-dev mailing list<br>
<a href="mailto:Linuxppc-dev@lists.ozlabs.org" target="_blank">Linuxppc-dev@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_blank">https://lists.ozlabs.org/<u></u>listinfo/linuxppc-dev</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>