On 04/17/2013 12:04:10 AM, saikrishna gajula wrote:
HI All,
I am new to this group. I am working on Freescale P2020
platform running linux 2.6.21. I am looking for debug
mechanism/utility,
when a multi threaded application running on linux , appears to be
hung (
running in a tight loop,deadlock) while not able to access the board
through serial/SSH/Telnet.
I was looking at Magic sysrq option in linux to generate the stack,
register dump when the application is hung. I am able to dump the call
trace in normal working conditions. But i can't use echo t >
/proc/sysrq-trigger and debug when the application hung.
I am using below piece of code(drivers/serial/8250.c) on P2020RDB to
debug
the application where in , in hung situation, when i press 'y'
followed by
't' on serial console it should go to sysrq handler, and dump the
call
trace, but it is not happening.(simply board hung)
{
if(sysrq_enable_flag)
handle_sysrq(ch, up->port.info->tty);
sysrq_enable_flag = 0;
if(ch == 'y')
sysrq_enable_flag = 1;
}
It would be helpful if you provide any hint on the issue, or any
other way
to debug the application in hang situations.
There's an erratum regarding breaks in Freescale's serial port
implementation that has been worked around in more recent kernels.
2.6.21 is six years old. If you update to a kernel that has the
workaround, or backport the workaround yourself to your old kernel, you
should be able to use a break instead of hacking in a check for 'y'.
Other than that, either the kernel is hung too badly to respond to
serial input at all (in which case use JTAG to debug) or there's
something wrong with your 'y' hack (sysrq_enable_flag doesn't even
appear in current kernels so I can't see if this is the case without
digging through old code).
In any case, upgrade to a newer kernel -- maybe you're hitting a bug
that has been fixed since then.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev