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.

Kernel gets stuck when saving output of encoder to usb mass storage device

Hello,

I am having a problem where the kernel/system stops responding (with out any crash reports, just stops/gets stuck) after around 30 - 90 minutes when
I try to save the encoded output to a usb mass storage device:

scenario description:

0. using DM365EVM rev E.
1. installed last sdk (4_01_00_09)
2. run the setup.sh to create a: filesystem, kernel image nfs, tftp etc.
3. build the dvsdk_demos, and run make_install to put demos in the nfs file system
4. system boots with uboot env that was supplied by the setup.sh also using the default kernel image and fileysystem.
5. insert a disk-on-key: Fat32 formated mass storage device to USB-J1 of the EVM.
6. the usb stick gets mounted and enumerated ok by the system and i can access it, the stick is mounted at /media/sda1
7. start to encode a D1 PAL signal using the dvsdk demo encode with the following command:  "./encode -v /media/sda1/Test.264 -y 2"
8. the demo starts to run and a preview is displayed.
9. after around 1 hour the video stops streaming, the serial command line stops responding as if the kernel is dead.
10. no responce from the system.

If this test is reapeted when the saved target is to an SDCARD like this: "./encode -v /media/mmcblk0p1/Test.264 -y 2" then there is no problem and the kernel continues to run.
If this test is reapeted when the saved target is to an NFS folder then there is no problem and the kernel continues to run.

could there be some kind of problem when encoding to save the output to a usb mass storage device ?
Is there fix for this problem ?

Thank you
Amir


  • Amir,

    Can you please enable the debug messages and provide the log. Use "echo D3 >/proc/driver/musb_hdrc" to enable debug level to level-3. This will slow down the write speed due to logs. Additionally you can also repeat the test in PIO mode (non-DMA) to check if this is DMA issue. 

    REgards,
    Ajay