• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Crash on DSPLink when closing an algorithm

ddompe
Intellectual 750 points

Hi,

I have a problem that I have been tracing down for long time regarding infrequent crashes in dsplink when closing an algorithm. I'm running dvsdk 4.01.00.09 on OMAP3 board, and using a h264 decoder from gstreamer.

The error happens when I'm cleaning up the algorithm from the gstreamer plugin (I have verified that the plugin is closing the algorithm when no other thread is calling something like the process() function of the algorithm):

Unable to handle kernel paging request at virtual address 8737e584
pgd = cc628000
[8737e584] *pgd=00000000
Internal error: Oops: 805 [#1]
last sysfs file: /sys/devices/virtual/ti/lpm0/dev
Modules linked in: lpm_omap3530 sdmak dsplinkk cmemk
CPU: 0    Not tainted  (2.6.34-ridgerun #4)
PC is at LIST_GetHead+0x40/0x50 [dsplinkk]
LR is at LDRV_MSGQ_get+0x44/0xc4 [dsplinkk]
pc : [<bf017bc0>]    lr : [<bf011ea0>]    psr: 80000013
sp : cc433e98  ip : 22222222  fp : 431f87dc
r10: ffffffff  r9 : cc432000  r8 : bf0229b0
r7 : d353c000  r6 : cc433efc  r5 : 00008000  r4 : 00000000
r3 : 8737e580  r2 : 00008000  r1 : cc433efc  r0 : d353f000
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8c628019  DAC: 00000015
Process queue0:src (pid: 4994, stack limit = 0xcc4322f0)
Stack: (0xcc433e98 to 0xcc434000)
3e80:                                                       c018e03a 431f87f4
3ea0: c018e03a 431f87f4 431f87f4 cc432000 4108d5a4 bf01ec7c c04d36d8 0000ee6b
3ec0: 000111f8 00000000 0000ee6b 00000000 cc433f04 c004c770 002625a0 00000000
3ee0: 00000000 00008000 00000000 00010001 ffffffff 00000000 00008000 d2f04880
3f00: cc433f2c cff06ac0 431f87f4 c018e03a cff06ac0 c00ba5fc 0000000d cff06ac0
3f20: 0000000d c00bacfc cc433f5c cc558630 c04d36d8 00060db9 00000000 57302d83
3f40: cc558630 c04d36d8 cc558630 c04d36d8 c002f004 c004e418 cc558630 c04d36a8
3f60: cc433f7c c004e52c 0000000d 431f87f4 c018e03a cff06ac0 c002f004 cc432000
3f80: 4108d5a4 c00bad74 0000000d 00000001 431f87f4 4108c240 ffffffff 431f888c
3fa0: 00000036 c002ee80 4108c240 ffffffff 0000000d c018e03a 431f87f4 0000000d
3fc0: 4108c240 ffffffff 431f888c 00000036 00010001 00002858 4108d5a4 431f87dc
3fe0: 4108ea98 431f86c8 4104c558 40541aec 80000010 0000000d 030cccb9 09e008f3
[<bf017bc0>] (LIST_GetHead+0x40/0x50 [dsplinkk]) from [<bf011ea0>] (LDRV_MSGQ_get+0x44/0xc4 [dsplinkk])
[<bf011ea0>] (LDRV_MSGQ_get+0x44/0xc4 [dsplinkk]) from [<bf01ec7c>] (DRV_Ioctl+0x1cc/0x7c0 [dsplinkk])
[<bf01ec7c>] (DRV_Ioctl+0x1cc/0x7c0 [dsplinkk]) from [<c00ba5fc>] (vfs_ioctl+0x60/0x70)
[<c00ba5fc>] (vfs_ioctl+0x60/0x70) from [<c00bacfc>] (do_vfs_ioctl+0x518/0x55c)
[<c00bacfc>] (do_vfs_ioctl+0x518/0x55c) from [<c00bad74>] (sys_ioctl+0x34/0x54)
[<c00bad74>] (sys_ioctl+0x34/0x54) from [<c002ee80>] (ret_fast_syscall+0x0/0x30)
Code: 13a02902 15803000 15913000 15933000 (15830004)
---[ end trace e70acf2f5d7d425b ]---
I trace down the issue to seems related to the function LIST_GetHead being call in a list that doesn't longer exists. I have tried to add some debug on the MSGQ functions but the debug just makes the bug to disappear. 
Any expert on DSPLink that may hint on the reason for this behavior? We have wrote and endurance test by constantly running and stopping the algorithm and this error happens 1 out of 2000 times in average (however with debug enabled it obviously may take around 20000 times to happen).

								


				
				

				
			

		

			
						
									
                			    			                        
						
						
			
			
						
			                        
			
			
				
			  
			

			     
			

		


				    			

						
















	

	

					
    
	
    





		
	
  • 
		
    
			 


	
		
	
	









    
	
    
		
    
							
					
    
		
    
			
													0
							
			
				
									
							
						
				
			
			
			
					
    
	
    
	                                    
                      
    
                        
                          TI__Genius
                        12025 points
                      
    
                          
                   		
		
    
					
    ddompe,
    

    The call to LDRV_MSGQ_get() seen in the stack traceback would indicate a thread is calling MSGQ_get(). So, maybe there is a timing issue where one thread is finalizing DSPLink while another thread is waiting for a message. When finalizing DSPLink, there can not be any other thread making any DSPLink API calls because all the resources will be released. It might be a bug in the GStreamer plugin. Try contacting the DVSDK team about this.
    

    ~ Ramsey
    
			
    

		
		
		
		
	
    
	
    
		
    
			
		
    
	
    

	            
                 	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
			
		
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    •