drmModeFreeResources() does not return on 35.1

After upgrading to L4T 35.1, drmModeFreeResources() supplied by libdrm_nvdc.so does not return anymore, causing the respective thread within our application to freeze.

A simple code snippet to reproduce this behaviour:

#include <stdio.h>
#include <xf86drm.h>
#include <xf86drmMode.h>

int main(void)
{
        int fd = drmOpen("drm-nvdc", NULL);

        printf("fd: %i\n", fd);

        drmModeResPtr res = drmModeGetResources(fd);

        printf("res: 0x%lx\n", (long)res);
        printf("fbs: 0x%lx\n", (long)res->fbs);
        printf("crtcs: 0x%lx\n", (long)res->crtcs);
        printf("connectors: 0x%lx\n", (long)res->connectors);
        printf("encoders: 0x%lx\n", (long)res->encoders);

        /* Does not return :( */
        drmModeFreeResources(res);
}

Compiled with clang -I/usr/include/libdrm -ldrm main.c

If you run the executable it will hang after the last printf()

lldb yields:

$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (aarch64).
(lldb) run
Process 1528 launched: 'a.out' (aarch64)
fd: 4
res: 0xaaaaaaabd320
fbs: 0x0
crtcs: 0xaaaaaaabd380
connectors: 0xaaaaaaabd3a0
encoders: 0xaaaaaaabd3c0
Process 1528 stopped
* thread #1, name = 'a.out', stop reason = signal SIGSTOP
    frame #0: 0x0000fffff7ddf268 libpthread.so.0`__lll_lock_wait(futex=0x0000fffff7fc7420, private=0) at lowlevellock.c:52:7
(lldb) thread list
Process 1528 stopped
* thread #1: tid = 1528, 0x0000fffff7ddf268 libpthread.so.0`__lll_lock_wait(futex=0x0000fffff7fc7420, private=0) at lowlevellock.c:52:7, name = 'a.out', stop reason = signal SIGSTOP
  thread #2: tid = 1556, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_vbl'
  thread #3: tid = 1557, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_pflip'
  thread #4: tid = 1558, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_vbl'
  thread #5: tid = 1559, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_pflip'
  thread #6: tid = 1560, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_vbl'
  thread #7: tid = 1561, 0x0000fffff7ddb414 libpthread.so.0`__pthread_cond_wait at futex-internal.h:186:13, name = 'drm_pflip'
(lldb) bt
* thread #1, name = 'a.out', stop reason = signal SIGSTOP
  * frame #0: 0x0000fffff7ddf268 libpthread.so.0`__lll_lock_wait(futex=0x0000fffff7fc7420, private=0) at lowlevellock.c:52:7
    frame #1: 0x0000fffff7dd6d20 libpthread.so.0`__GI___pthread_mutex_lock(mutex=0x0000fffff7fc7420) at pthread_mutex_lock.c:80:7
    frame #2: 0x0000fffff7fa25a0 libdrm.so.2`drmFree + 32
    frame #3: 0x0000fffff7bae6dc libdrm.so.2.4.0`drmModeFreeResources + 28
    frame #4: 0x0000fffff7fa0c58 libdrm.so.2`drmModeFreeResources + 40
    frame #5: 0x0000aaaaaaaa0958 a.out`main + 164
    frame #6: 0x0000fffff7e3de18 libc.so.6`__libc_start_main(main=(a.out`main), argc=1, argv=0x0000fffffffff4c8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=<unavailable>) at libc-start.c:308:16
    frame #7: 0x0000aaaaaaaa07d4 a.out`_start + 52

The Mesa version of drmModeFreeResources() in xf86drmMode.c looks quite trivial with no obvious point where this could hang. I was not able to find the source for the nvidia version, i.e. libdrm_nvdc.so.

Following questions:

  • Just to make sure, is the source of libdrm_nvdc.so available somewhere?
  • What is the purpose of the drm_vbl and drm_pflip threads?
  • What must be changed to avoid the freeze?

Hi,

No, the source is not public. The threads are for fetching one frame from queue and render out.

For demonstrating DRM, we have a jetson_multiemdia_api sample in

/usr/src/jetson_multimedia_api/samples/08_video_dec_drm/

And NvDrmRenderer class is in

/usr/src/jetson_multimedia_api/samples/common/classes/NvDrmRenderer.cpp

Please refer to the sample. Furthermore, nvdrmvideosink plugin in gstreamer is open source and you may also take a look.

Hi, thank you for your response!

I just ran the 08_video_dec_drm sample with --disable-video and could observe a very similar behaviour. The application freezes in the constructor of the NvDrmRenderer class, precisely the drmGetVersion() call never returns.

lldb yields:

(lldb) thread backtrace
* thread #1, name = 'OutputPlane', stop reason = signal SIGSTOP
  * frame #0: 0x0000ffffb869e268 libpthread.so.0`__lll_lock_wait(futex=0x0000ffffb6cb6420, private=0) at lowlevellock.c:52:7
    frame #1: 0x0000ffffb8695d20 libpthread.so.0`__GI___pthread_mutex_lock(mutex=0x0000ffffb6cb6420) at pthread_mutex_lock.c:80:7
    frame #2: 0x0000ffffb6c8bbe0 libdrm.so.2`drmMalloc + 32
    frame #3: 0x0000ffffb2c85de8 libdrm.so.2.4.0`drmGetVersion + 24
    frame #4: 0x0000ffffb6c91a60 libdrm.so.2`___lldb_unnamed_symbol219$$libdrm.so.2 + 120
    frame #5: 0x0000ffffb6c92364 libdrm.so.2`drmGetVersion + 52
    frame #6: 0x0000aaaac1f8e340 video_dec_drm`NvDrmRenderer::NvDrmRenderer(char const*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, drm_tegra_hdr_metadata_smpte_2086, bool) + 796
    frame #7: 0x0000aaaac1f91e24 video_dec_drm`NvDrmRenderer::createDrmRenderer(char const*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, drm_tegra_hdr_metadata_smpte_2086, bool) + 200
    frame #8: 0x0000aaaac1f890b0 video_dec_drm`drm_rendering(context_t&, int, char**, int) + 528
    frame #9: 0x0000aaaac1f89cc0 video_dec_drm`main + 52
    frame #10: 0x0000ffffb6930e18 libc.so.6`__libc_start_main(main=(video_dec_drm`main), argc=4, argv=0x0000fffff2b894f8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=<unavailable>) at libc-start.c:308:16
    frame #11: 0x0000aaaac1f85e64 video_dec_drm`_start + 52

Hi,
Please disable Ubuntu desktop before running the sample. Here is the document for reference:
Jetson Linux API Reference: 08_video_dec_drm (Direct Rendering Manager) | NVIDIA Docs

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.