dmai bug? Can't reopen capture device..

Which DVSDK are you using?  I'm only aware of DMAI 1.10 being part of DVSDK 1.40, which supports DM6467.  You may want to upgrade to a newer version of DMAI.

hi David,

       I'm using dvsdk_1_30_01_41. I tried dmai 1.16, the bug is still exist.

       Thanks a lot!

David Meixner said:

Which DVSDK are you using?  I'm only aware of DMAI 1.10 being part of DVSDK 1.40, which supports DM6467.  You may want to upgrade to a newer version of DMAI.

Hi David,

      I have just tested lsp-200,  dvsdk_2_00_00_22,  dmai_1_20_00_06. And the bug is till exist. Below is the log message:

root@davinci:/home# DMAI_DEBUG=2 ./video_loopback_copy_dm6446.x470MVxx
@0x00060196:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Dmai log level set to '2'. Note that calling CERuntime_init after this point may cause unexpected change to DMAI tracing behavior.
@0x00065a65:[T:0x4001ed40] ti.sdo.dmai - [Capture] Checking video standard
@0x0006bceb:[T:0x4001ed40] ti.sdo.dmai - [Capture] Capture input set to COMPOSITE
@0x0006bdc6:[T:0x4001ed40] ti.sdo.dmai - [Capture] Video input connected size 720x576 pitch 1440
@0x0006bf0f:[T:0x4001ed40] ti.sdo.dmai - [BufTab] Allocating BufTab for 3 buffers
@0x0006c0f9:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x402f2000 (physical 0x80800000)
@0x00070ac1:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 0 mapped to 0x402f2000 has physical address 0x80800000
@0x00070c58:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x403ca000 (physical 0x87300000)
@0x00075604:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 1 mapped to 0x403ca000 has physical address 0x87300000
@0x00075785:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x404a2000 (physical 0x80a00000)
@0x0007a123:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 2 mapped to 0x404a2000 has physical address 0x80a00000
@0x0007ee06:[T:0x4001ed40] ti.sdo.dmai - [Display] Video output set to size 720x576 pitch 1440
@0x0007ef61:[T:0x4001ed40] ti.sdo.dmai - [BufTab] Allocating BufTab for 3 buffers
@0x0007f19c:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x4057a000 (physical 0x80c00000)
@0x00083b12:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 0 mapped to 0x4057a000 has physical address 0x80c00000
@0x00083dc2:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x40976000 (physical 0x86000000)
@0x00088780:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 1 mapped to 0x40976000 has physical address 0x86000000
@0x000889da:[T:0x4001ed40] ti.sdo.dmai - [Buffer] Set user pointer 0x40d72000 (physical 0x86400000)
@0x0008d43e:[T:0x4001ed40] ti.sdo.dmai - [Dmai] Driver buffer 2 mapped to 0x40d72000 has physical address 0x86400000

change once!
@0x0055e2c6:[T:0x4001ed40] ti.sdo.dmai - [Capture] Checking video standard
@0x00564535:[T:0x4001ed40] ti.sdo.dmai - [Capture] Capture input set to COMPOSITE
@0x00564614:[T:0x4001ed40] ti.sdo.dmai - [Capture] Video input connected size 720x576 pitch 1440
@0x00564857:[T:0x4001ed40] ti.sdo.dmai - [Dmai] VIDIOC_REQBUFS failed (Device or resource busy)
@0x005648ea:[T:0x4001ed40] ti.sdo.dmai - [Capture] Failed to allocate capture driver buffers on /dev/video0
video_loopback_copy_dm6446.x470MVxx: linux/Capture.c:650: Capture_get: Assertion `hCapture' failed.
Aborted

Please kindly test this. Thanks.

Wei Jiang

I've got the same problem with GA release dvsdk2.0.00.22.  The key problem is if Capture_delete is called then Capture_create will fail.

Anybody solved this problem? It puzzled me very long time[:(]

Thanks

kickgame said:

I've got the same problem with GA release dvsdk2.0.00.22.  The key problem is if Capture_delete is called then Capture_create will fail.

The problem has been reported, I am trying to get a status on where we are on this issue.

Update: It appears this issue has been fixed already; you will need to upgrade to DMAI trunk or at minimum update cleanup function in capture.c

Dear Juan,

     Thanks a lot for your reply.

      I changed the cleanup function and the bug still alive.  can you tell me where is the newest dmai? I tested the gforge-svn dmai and it's the same problem. link here:

              https://gforge.ti.com/gf/project/dmai/

      Would you kindly test this and show me your development environment? I have tested lsp120, lsp130, lsp200 and dvsdk1.30, dvsdk2.00 and dmai1.60, dmai2.00, dmai2,10 and the dmai-svn. All of them have this problem.

     I wonder whether I made some mistake in my operation?

     Thanks  again.

       Wei Jiang

Anybody solved this problem?

Anybody solved this problem? [:@]

Thanks!

I have the same problem but display device, I'm using DM6446-EVM, and I'm using dvsdk_2_00_00_22.

I've modified display.c of decode demo as below:

    /* Create the display device instance */
    dAttrs.numBufs = NUM_DISPLAY_BUFS;
    dAttrs.videoStd = envp->videoStd;
    dAttrs.videoOutput = envp->displayOutput;
    hDisplay = Display_create(NULL, &dAttrs);
    deleteRet = Display_delete(hDisplay);
    printf("loop 1, deleteRet %d\n", deleteRet);
    sleep(3);
    hDisplay = Display_create(NULL, &dAttrs);
    deleteRet = Display_delete(hDisplay);
    printf("loop 2, deleteRet %d\n", deleteRet);
    sleep(3);
    hDisplay = Display_create(NULL, &dAttrs);
    deleteRet = Display_delete(hDisplay);
    printf("loop 3, deleteRet %d\n", deleteRet);
    sleep(3);
    hDisplay = Display_create(NULL, &dAttrs);

The second Display_create will fail with:

root@192.168.0.47:/opt/dvsdk/dm6446# DMAI_DEBUG=2 ./decode -v q13.m2v
Decode demo started.
@0x00023863:[T:0x4001f960] ti.sdo.dmai - [Dmai] Dmai log level set to '2'. Note that calling CERuntime_init after this point may cause unexpected change to DMAI tracing behavior.
@0x000bef8f:[T:0x4001f960] ti.sdo.dmai - [BufTab] Allocating BufTab for 1 buffers
@0x000bf192:[T:0x4001f960] ti.sdo.dmai - [Buffer] Set user pointer 0x42449000 (physical 0x80800000)
@0x000bf6ed:[T:0x4001f960] ti.sdo.dmai - [Display] Display buffer 0 mapped to 0x42449000 has physical address 0x40025000
@0x000c7bc4:[T:0x42c75490] ti.sdo.dmai - [Display] Video output set to size 720x480 pitch 1440
@0x000c7d16:[T:0x42c75490] ti.sdo.dmai - [BufTab] Allocating BufTab for 3 buffers
@0x000c7f82:[T:0x42c75490] ti.sdo.dmai - [Buffer] Set user pointer 0x42c76000 (physical 0x86000000)
@0x000cbd93:[T:0x42c75490] ti.sdo.dmai - [Dmai] Driver buffer 0 mapped to 0x42c76000 has physical address 0x86000000
@0x000cc012:[T:0x42c75490] ti.sdo.dmai - [Buffer] Set user pointer 0x43072000 (physical 0x86400000)
@0x000cfe62:[T:0x42c75490] ti.sdo.dmai - [Dmai] Driver buffer 1 mapped to 0x43072000 has physical address 0x86400000
@0x000d00ed:[T:0x42c75490] ti.sdo.dmai - [Buffer] Set user pointer 0x4346e000 (physical 0x86800000)
@0x000d3f1d:[T:0x42c75490] ti.sdo.dmai - [Dmai] Driver buffer 2 mapped to 0x4346e000 has physical address 0x86800000
loop 1, deleteRet 0
@0x000d9769:[T:0x44069490] ti.sdo.dmai - [Vdec2] Video decoder instance created
@0x000d99bc:[T:0x44069490] ti.sdo.dmai - [Vdec2] Made XDM_SETPARAMS control call
@0x000d9ba1:[T:0x44069490] ti.sdo.dmai - [Vdec2] Made XDM_GETBUFINFO control call
@0x000d9c5c:[T:0x44069490] ti.sdo.dmai - [BufTab] Allocating BufTab for 5 buffers
@0x000d9dd5:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 829440 at 0x4406a000 (0x87c42000 phys)
@0x000d9f9b:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 829440 at 0x4414b000 (0x87b61000 phys)
@0x000da132:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 829440 at 0x4422c000 (0x87a80000 phys)
@0x000da2c0:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 829440 at 0x4430d000 (0x8799f000 phys)
@0x000da48f:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 829440 at 0x443ee000 (0x878be000 phys)
@0x000da590:[T:0x44069490] ti.sdo.dmai - [Loader] Creating Loader for q13.m2v with buffer size 1658880, window size 829440, alignment -1
@0x000dabe0:[T:0x44069490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 1658880 at 0x444cf000 (0x87d23000 phys)
DavinciDisplay DavinciDisplay.1: not IO user
@0x003b1be3:[T:0x42c75490] ti.sdo.dmai - [Display] Video output set to size 720x480 pitch 1440
@0x003b2ef7:[T:0x42c75490] ti.sdo.dmai - [Dmai] VIDIOC_REQBUFS failed (Device or resource busy)
@0x003b2fa7:[T:0x42c75490] ti.sdo.dmai - [Display] Failed to allocate display driver buffers on /dev/video2

What's the difference between the first create and the second one?? Why fail??

Hi Juan,

    Thanks for your replay. I've just registered an account in that system, but not get the confirm email yet.

    For my problem, it's not related to the link you give. I've done some test on my problem, the problem is

During calling Display_create -> Display_v4l2_create, the /dev/video2 device will be opened and referenced by the following function:

1. hDisplay->fd = open(attrs->displayDevice, O_RDWR, 0);

2. _Dmai_v4l2DriverAlloc -> mmap (numBufs times)

During calling Display_delete -> Display_v4l2_delete -> cleanup, the following functions is supposed to decrease the reference, but not the truth:

1.   if (close(hDisplay->fd) == -1) {             (This do decrease the reference by one)

2.  munmap(Buffer_getUserPtr(hDispBuf),   (This doesn't)

And finally the reference doesn't reduce to 0, and the release function davinci_release in davinci_display.c is not called, then a second Display_create

will fail in davinci_doioctl of cmd VIDIOC_REQBUFS because davinci_release was not called, and the resource of first open is not released.

Any comment? Thanks.

Thanks,

Colin Zuo

Hi colin,

       So am I. Except mine is video0.

      For your problem, maybe you can try framebuffer not v4l2-display.

Wei Jiang

Hi Juan, Colin,

          Maybe it's the same bug here:

          https://gforge.ti.com/gf/project/dmai/tracker/action=TrackerItemEdit&tracker_item_id=981/?action=TrackerItemEdit&tracker_item_id=471

        I tried the patch but it seems unavaliable.

Wei Jiang

Hi WeiJiang,

  Yes, it's that bug, it seems not fixed in dvsdk_2_00_00_22.

  The mmap was called with bufDesc->v4l2buf.length of size 4177920, while the munmap was called with

Buffer_getSize(hDispBuf) (actually fmt.fmt.pix.sizeimage) of size 691200.

  So the file reference was not decreased, and the release function not get called.

   I'm not sure whether dmai needs to be changed or the linux kernel driver. Need study further.

Thanks,

Colin

Hi WeiJiang,

    That patch works fine in my case. Thanks.

Thanks,

Colin

Hi Juan,

     It indeed resolved my problem, too.

     bug fixed here:

            https://gforge.ti.com/gf/project/dmai/scmsvn/?action=ScmCommitDetail&scm_commit_id=1069

     Thanks for your help.

Juan Gonzales said:

Not sure if this post is related to the same bug you are seeing http://e2e.ti.com/forums/p/12573/48972.aspx#48972.

Either way, you should follow the recommendations and submit bug via https://gforge.ti.com/gf/project/dmai/tracker/?action=TrackerItemEdit&tracker_item_id=981.  I believe you can also track bugs there.

 

that is great news!  I am glad it helped solve the issues you two were seeing as well.

I'm using an OMAP 3530 Mistral EVM with DVSDK 3_00_02_44 (GA)

I'm seeing the same error when working with Display_create and Display_delete calls from DMAI.

I call Display_create, followed by Display_delete, followed by Display_create. This call to Display_create fails with a DMAI error message saying it "cannot open /dev/video2." It looks like the Display_delete is not freeing up the display driver instance as it should.

I checked the code in Display_v4l2.c, and for the Display_delete call (cleanup) I see:

"munmap(Buffer_getUserPtr(hDispBuf), Buffer_getSize(hDispBuf)"

whereas during creation the call to mmap (in _VideoBuf.c) is:

mmap(NULL, bufDesc->v4l2buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, bufDesc->v4l2buf.m.offset) + topOffset;

Thanks!

I do not think the patch provided in gforge repository solved the problem.  As Gurnani pointed out, the root cause is the mmap/munmap mismatch.  I add a line in _VideoBuf.c and it seems to fix this issue with my DVSDK 2.0 setup:

@@ -317,6 +317,8 @@ Int _Dmai_v4l2DriverAlloc(Int fd, Int numBufs, enum v4l2_buf_type type,
         Buffer_setUseMask(hBuf, gfxAttrs.bAttrs.useMask);
         Buffer_setUserPtr(hBuf, virtPtr);
 
+    Buffer_setSize(hBuf, bufDesc->v4l2buf.length);
+
         /* Initialize buffer to black */
         _Dmai_blackFill(hBuf);