Hang in NvOsThreadJoin when calling VIDIOC_STREAMOFF on Jetson (libtegrav4l2)

Robotics & Edge Computing Jetson Systems Jetson Xavier NX
1

Hardware/Software Environment:

  • Device: Jetson Xavier NX
  • JetPack Version: 5.1.2 (L4T 35.3.1)
  • Kernel: 5.10.120-tegra
  • Camera: [e.g., IMX219, AR0234, or USB cam model]

Issue Description:
Our application hangs indefinitely when calling v4l2_ioctl(fd, VIDIOC_STREAMOFF, &buf_type) for V4L2 capture streams. Stack traces consistently show blocking in NvOsThreadJoin within libtegrav4l2.so, indicating the driver’s internal capture thread fails to terminate.

Key Observations:

Blocking Callstack (from GDB):

#0 __pthread_clockjoin_ex (threadid=281470383349520, thread_return=0x0, clockid=0, abstime=, block=) at pthread_join_common.c:145
#1 0x0000ffff39fe24d8 in NvOsThreadJoin () at /usr/lib/aarch64-linux-gnu/tegra/libnvos.so
#2 0x0000ffff1c9ce454 in () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#3 0x0000ffff1c9cf290 in () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#4 0x0000ffff1c9cbb60 in TegraV4L2_Ioctl () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#5 0x0000ffff1ca2e050 in plugin_ioctl () at /usr/lib/aarch64-linux-gnu/libv4l/plugins/nv/libv4l2_nvvideocodec.so
#6 0x0000ffff40022390 in v4l2_ioctl () at /lib/aarch64-linux-gnu/libv4l2.so.0
#7 0x0000ffff9c39d6bc in NvV4l2ElementPlane::setStreamStatus(bool) (this=0xffff880e0fe8, status=false) at NvV4l2ElementPlane.cpp:570
#8 0x0000ffff9c39c9c4 in NvV4l2ElementPlane::deinitPlane() (this=0xffff880e0fe8) at NvV4l2ElementPlane.cpp:461
#9 0x0000ffff9c3adb80 in NvV4l2Element::~NvV4l2Element() (this=0xffff880e0dd0, __in_chrg=) at NvV4l2Element.cpp:90
#10 0x0000ffff9c369594 in NvVideoDecoder::~NvVideoDecoder() (this=0xffff880e0dd0, __in_chrg=) at NvVideoDecoder.cpp:85
#11 0x0000ffff9c3695b4 in NvVideoDecoder::~NvVideoDecoder() (this=0xffff880e0dd0, __in_chrg=) at NvVideoDecoder.cpp:87

3

hello oob400,

please see-also Topic 258971 to apply multi-cam race condition fixes.

4

Thanks for the reply, but we use the SDK Manager to burn the firmware. We don’t know where the source file capture-ivc.c is located, nor how to compile it and update the kernel image.

5

hello oob400,

please visit L4T page, such as NVIDIA Jetson Linux 35.3.1 to download [Driver Package (BSP) Sources] package.
you may refer to developer guide, Building the Kernel for reference.

6

Thanks, we will try it.

7

hello JerryChang,

we have upgrade the L4T to 35.6.2, but it has new issue, here is the callstack

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffff1f7564f8 in ?? () from /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
[Current thread is 1 (Thread 0xfffec1653f10 (LWP 55157))]
(gdb) bt
#0 0x0000ffff1f7564f8 in () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#1 0x0000ffff1f759bd0 in () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#2 0x0000ffff1f74cb78 in TegraV4L2_Ioctl () at /usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so
#3 0x0000ffff1f7b00a8 in plugin_ioctl () at /usr/lib/aarch64-linux-gnu/libv4l/plugins/nv/libv4l2_nvvideocodec.so
#4 0x0000ffff3e34f390 in v4l2_ioctl () at /lib/aarch64-linux-gnu/libv4l2.so.0
#5 0x0000ffff7538c540 in NvV4l2ElementPlane::qBuffer(v4l2_buffer&, NvBuffer*) (this=0xffff5c8067c8, v4l2_buf=…, shared_buffer=0x0) at NvV4l2ElementPlane.cpp:262
#6 0x0000ffff7535555c in nv_put_frame_block(nv_context_t*, char*, int) (ctx=0xffff5c806350, nalu_parse_buffer=0xffff5d3f93a0 “”, size=2580) at nvidia_codec.cpp:587
#7 0x0000ffff75355b34 in nv_put_frame_loop_fcn(void*) (arg=0xffff5c806350) at nvidia_codec.cpp:757
#8 0x0000ffffb10c3624 in start_thread (arg=0xffff75355a58 <nv_put_frame_loop_fcn(void*)>) at pthread_create.c:477
#9 0x0000ffffb101a62c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
(gdb) f 5
#5 0x0000ffff7538c540 in NvV4l2ElementPlane::qBuffer (this=0xffff5c8067c8, v4l2_buf=…, shared_buffer=0x0) at NvV4l2ElementPlane.cpp:262
262 NvV4l2ElementPlane.cpp: No such file or directory.
(gdb) p this
$1 = (NvV4l2ElementPlane * const) 0xffff5c8067c8
(gdb) p *this
$2 = {plane_lock = {__data = {__lock = 1, __count = 0, __owner = 55157, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = “\001\000\000\000\000\000\000\000u\327\000\000\001”, ‘\000’ <repeats 34 times>, __align = 1}, plane_cond = {__data = {{__wseq = 0, __wseq32 = {
__low = 0, __high = 0}}, {__g1_start = 0, __g1_start32 = {__low = 0, __high = 0}}, __g_refs = {0, 0}, __g_size = {0, 0}, __g1_orig_size = 0, __wrefs = 0,
__g_signals = {0, 0}}, __size = ‘\000’ <repeats 47 times>, __align = 0}, fd = @0xffff5c8069f0, plane_name = 0xffff753a5fb8 “Output Plane”,
buf_type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, blocking = true, num_buffers = 2, buffers = 0xffff5d2db2b0, n_planes = 1 ‘\001’, planefmts = {{width = 0,
height = 0, bytesperpixel = 0, stride = 0, sizeimage = 4000000}, {width = 0, height = 0, bytesperpixel = 0, stride = 0, sizeimage = 0}, {width = 0,
height = 0, bytesperpixel = 0, stride = 0, sizeimage = 0}}, memory_type = V4L2_MEMORY_MMAP, num_queued_buffers = 0, total_queued_buffers = 0,
total_dequeued_buffers = 0, streamon = true, dqthread_running = false, stop_dqthread = false, dq_thread = 0, callback = 0x0, dqThread_data = 0x0,
v4l2elem_profiler = @0xffff5c8066d8, is_in_error = 0, comp_name = 0xffff753a2450 “dec0”}
(gdb)

8

hello oob400,

may I know your steps for moving forward to 35.6.2.
for instance, did you refer to developer guide, Updating Jetson Linux with Image-Based Over-the-Air Update?

10

We just upgrade the L4T to 35.6.2 with the deb files, which like
nvidia-l4t-tools_35.6.2-20250515185434_arm64.deb
nvidia-l4t-init_35.6.2-20250515185434_arm64.deb
nvidia-l4t-kernel_5.10.216-tegra-35.6.2-20250515185434_arm64.deb
nvidia-l4t-core_35.6.2-20250515185434_arm64.deb
nvidia-l4t-cuda_35.6.2-20250515185434_arm64.deb
nvidia-l4t-multimedia-utils_35.6.2-20250515185434_arm64.deb
nvidia-l4t-nvsci_35.6.2-20250515185434_arm64.deb
nvidia-l4t-multimedia_35.6.2-20250515185434_arm64.deb

11

When we upgrade to 35.6.2, the HDMI can’t display anything.

Which shows in the serial port

[ 6.974829] tegra_cec 3960000.tegra_cec: Can’t find physical address.
[ 6.975002] tegra_cec 3960000.tegra_cec: tegra_cec_init Done.
[ 7.174852] tegradc 15200000.display: hdmi: edid read failed
[ 7.175086] tegradc 15200000.display: hdmi: using fallback edid
��pll_d2 has no dyn ramp
��[ 7.175243] tegradc 15200000.display: blank - powerdown
[ 7.187030] tegradc 15200000.display: unblank
[ 7.242771] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 7.242776] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 7.294779] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 7.294787] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 7.346769] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 7.346776] tegradc 15200000.display: timeout waiting for postcomp init state to promote
[ 7.394646] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[ 7.398769] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 7.398775] tegradc 15200000.display: timeout waiting for win assignments to promote
[ 7.398780] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
[ 7.398807] tegradc 15200000.display: update windows ret = -14
[ 7.398811] tegradc 15200000.display: sync windows ret = -14
[ 7.401529] extcon-disp-state external-connection:disp-state: cable 53 state 1
[ 7.407053] Extcon HDMI: HPD enabled
[ 7.407060] tegradc 15200000.display: hdmi: plugged
[ 7.431785] Rootfs mounted over PARTUUID=23d886e2-00d4-4ca8-9aeb-857eed95fb21
[ 7.464484] Switching from initrd to actual rootfs
[ 7.603013] systemd[1]: System time before build time, advancing clock.
[ 7.636720] tegradc 15200000.display: hdmi: tegra_edid_read_block(0) returned err -121
[ 7.639561] tegradc 15200000.display: hdmi_recheck_edid: read_edid_into_buffer() returned -121
[ 7.641938] tegradc 15200000.display: hdmi: unable to read EDID

12

hello oob400,

were you using Xavier NX DevKit?
is this display monitor compatible issue? please test with another display monitor as well.

13

Yes, some display monitor shows well.

But if we use 35.4.1, all the display monitor shows well.

But it’s not the main question.

The main question is why Our application hangs indefinitely when calling v4l2_ioctl.

We changed the application logic，it seems can work well.

14

hello oob400,

is it single camera or multiple camera use-case?
please refer to developer guide, Approaches for Validating and Testing the V4L2 Driver to test with your sensor driver directly.