<div dir="ltr"><div><div><div>Hi Scott,<br><br></div>           Thanks for the information. "sysrq_enable_flag" is custom code introduced as part of  'y' hack implementation. I will check with the latest kernels to make use of "sysrq"  feature.<br>
<br></div>Regrads,<br></div>Sai<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 2, 2013 at 1:24 AM, Scott Wood <span dir="ltr"><<a href="mailto:scottwood@freescale.com" target="_blank">scottwood@freescale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/17/2013 12:04:10 AM, saikrishna gajula wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
HI All,<br>
<br>
             I am new to this group. I am working on Freescale P2020<br>
platform running linux 2.6.21.   I am looking for debug mechanism/utility,<br>
when a multi threaded application running on linux , appears to be hung (<br>
running in a tight loop,deadlock)  while not able to access the board<br>
through serial/SSH/Telnet.<br>
<br>
   I was looking at Magic sysrq option in linux to generate the stack,<br>
register dump when the application is hung. I am able to dump the call<br>
trace in normal working conditions. But i can't use  echo  t ><br>
/proc/sysrq-trigger and debug when the application hung.<br>
<br>
 I am using below piece of code(drivers/serial/8250.c) on P2020RDB to debug<br>
the application where in , in hung situation, when i press 'y'  followed by<br>
't'  on serial console it should go to sysrq handler, and dump the call<br>
trace, but it is not happening.(simply board hung)<br>
<br>
{<br>
           if(sysrq_enable_flag)<br>
                  handle_sysrq(ch, up->port.info->tty);<br>
<br>
        sysrq_enable_flag = 0;<br>
<br>
        if(ch == 'y')<br>
            sysrq_enable_flag = 1;<br>
}<br>
<br>
It would be helpful if you provide any hint on the issue, or any other way<br>
to debug the application in hang situations.<br>
</blockquote>
<br></div>
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'.<br>

<br>
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).<br>

<br>
In any case, upgrade to a newer kernel -- maybe you're hitting a bug that has been fixed since then.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Scott<br>
</font></span></blockquote></div><br></div></div>