PowerPC, P2020RDB, application debug when the application is in tight loop, Sysrq

Scott Wood scottwood at freescale.com
Thu May 2 05:54:17 EST 2013


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


More information about the Linuxppc-dev mailing list