Hi all,
We have DM365-based custom hardware (the design is based on the evaluation module). We plan to make use of the capabilities of the SoC to develop several different products.
We are using DVSDK 4_00_00_44 (as distributed, no components have been upgraded).
The current task is to create an application that can simultaneously accept two streams of MPEG4-encoded video, decode both and send the resultant video frames to a companion system for subsequent processing. I am using the "mpeg4dec_hdvicp" codec.
At present, input data is being read (by both decoders) from a (local) file and both outputs are shipped to the companion system using the "g_ether" driver (essentially, it simulates TCP/IP/Ethernet over USB).
For our implementation, I started with the DMAI demo video decoder application (video_decode_io2) and modified it so that all processing is moved to a thread that I can instantiate as many times as required. I did take care to ensure that CERuntime_init() and Dmai_init() are called only once (in the main thread before the video processing threads are started). All other functionality (I/O, codec engine creation, buffer allocation/management, codec processing, etc.) is completely encapsulated by the video processing thread.
When run single-threaded, things work fine. The problems begin when I add a second thread. It appears as if both threads function normally for a while and then one of them gets stuck waiting for codec processing to complete (i.e., the call to Vdec2_process() in one thread does not return). At that point the entire application is (obviously) deadlocked.
Although I understand that it is not necessary, I added a mutex to ensure that calls to Vdec2_process() can only be made by one thread at a time. Predictably, this did not have any effect. The application still deadlocks.
The attached file "test.log" contains the output of the application run with CE_DEBUG=3. I note that it contains no errors.
I have tried debugging the application. I ran the application until it deadlocked and then halted it. Here is its state at that moment:
(gdb) info threads
Id Target Id Frame
3 Thread 0x412ff490 (LWP 1411) 0x4003480c in __lll_lock_wait () from /lib/libpthread.so.0
2 Thread 0x40aff490 (LWP 1410) 0x40275aec in ioctl () from /lib/libc.so.6
* 1 Thread 0x4001f040 (LWP 1407) 0x4002cbbc in pthread_join () from /lib/libpthread.so.0
(gdb) t 3
[Switching to thread 3 (Thread 0x412ff490 (LWP 1411))]
#0 0x4003480c in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0 0x4003480c in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x4002dc20 in pthread_mutex_lock () from /lib/libpthread.so.0
#2 0x0000c1f8 in appMain (arg=0xbec34b00) at appMain.c:728
#3 0x4002c5f4 in start_thread () from /lib/libpthread.so.0
#4 0x4027d368 in clone () from /lib/libc.so.6
#5 0x4027d368 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) t 2
[Switching to thread 2 (Thread 0x40aff490 (LWP 1410))]
#0 0x40275aec in ioctl () from /lib/libc.so.6
(gdb) bt
#0 0x40275aec in ioctl () from /lib/libc.so.6
#1 0x0007328c in VICP_wait ()
#2 0x000717e8 in HDVICPSYNC_wait ()
#3 0x0002e5c4 in MPEG4VDEC_TI_Decode ()
#4 0x00013980 in VIDDEC2_process ()
#5 0x00011ccc in Vdec2_process (hVd=0xff540, hInBuf=0x10acb8, hDstBuf=0x1057e8) at ce/Vdec2.c:170
#6 0x0000c224 in appMain (arg=0xbec34a48) at appMain.c:734
#7 0x4002c5f4 in start_thread () from /lib/libpthread.so.0
#8 0x4027d368 in clone () from /lib/libc.so.6
#9 0x4027d368 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Thread 1 is the main thread, waiting for the others to exit. Thread 3 is being held by (my) mutex, waiting to call Vdec2_process(). Thread 2 appears to be the one that has deadlocked, waiting for the decoder to finish processing.
I should also point out that this deadlock is not fatal for the system. If I kill off the application, all memory allocated via CMEM is freed (very nice) and I can re-run the application immediately.
I do have CCS4 and an XDS100 available. If it would be of any help, I can use it to examine the hardware once the deadlock occurs.
I do not know if improper configuration of the DM365 via its various internal registers could be the cause of this problem. Although our code is based on the DVSDK, I did have to modify U-Boot to reconfigure some I/Os so that our board would boot properly. I haven't changed the contents of any registers except those associated with I/O use (including remapping some I/O from being connected to internal DM365 peripherals to being used as straight digital I/O).
Any help with this problem would be most appreciated.
Sincerely yours,
Ray Allen
