Dual ZED X on ZED Box Duo: repeatable Argus AlreadyAllocated and InvalidState despite two working streams (SDK 5.4.1, driver 1.4.3)

Software ROS2
1

Hello Stereolabs team,

we are testing two ZED X cameras connected to one ZED Box Duo. Both cameras
can be opened and streamed at the same time, but nvargus-daemon emits
repeatable resource and state errors during every dual-camera startup.

The sender is a native application, not a Docker container. A single process
owns two sl::Camera instances. It opens the cameras sequentially with
setFromGMSLPort(), waits two seconds between opens, verifies the expected
serial number after each open, and enables both H.265 encoders only after both
cameras have opened successfully.

There is no camera hotplug and neither nvargus-daemon nor zed_x_daemon is
restarted while a camera session is open. Both cameras are connected before
boot. The sender and receiver processes stop cleanly after each test.

Sender environment

  • Stereolabs ZED Box Duo, Jetson Orin NX 16 GB
  • JetPack 6.2.1
  • L4T 36.4.4
  • Kernel 5.15.148-tegra
  • ZED SDK 5.4.1
  • stereolabs-zedbox-duo
    1.4.3-LI-MAX96712-ZEDBOX-L4T36.4.0
  • Two ZED X cameras, firmware 2001, on GMSL ports 0 and 1
  • HD1200 at 30 FPS, H.265, 12.5 Mbit/s per camera
  • DEPTH_MODE::NONE on the sender

The system was upgraded from ZED SDK 5.2.3 and ZED Box Duo driver 1.4.1 to
SDK 5.4.1 and driver 1.4.3. The upgrade removed the previous
Failed to connect to zed_x_daemon warning from the single-process test, but
the Argus messages below remain.

Receiver and functional result

The two network streams are received by a Jetson AGX Orin running ZED SDK
5.4.1 and two ROS 2 wrapper instances. Both A/B runs passed all ten checked
data paths for the two cameras: RGB, registered depth, reduced point cloud,
health, and heartbeat. Point clouds remained close to the configured 5 Hz
target. Both sender streams and both receivers shut down with exit code 0.

Reproduction

  1. Boot the ZED Box with both cameras already connected.
  2. Confirm that both cameras are AVAILABLE and that zed_x_daemon is active.
  3. Start the single-process sender with open order cam0-first.
  4. Open port 0, wait two seconds, open port 1, verify both serial numbers, and
    then enable both streams.
  5. Start both network receivers and verify the ten ROS 2 data paths.
  6. Stop sender and receivers cleanly.
  7. Repeat with open order cam1-first.
  8. Inspect the isolated nvargus-daemon journal windows.

Results

Run Open order All 10 receiver paths Point cloud cam0/cam1 AlreadyAllocated NvCameraUtils InvalidState Wrong frequency range ModuleNotPresent Failed to connect to zed_x_daemon
A cam0-first passed 5.09 / 5.19 Hz 12 8 531 60 0
B cam1-first passed 5.74 / 5.00 Hz 12 4 357 30 0

Run A contains one additional ZED_Explorer provider cycle immediately before
the sender starts. It accounts for 30 of the 60 ModuleNotPresent messages.
The Wrong frequency range rate is approximately 5.5 messages/s in run A and
5.3 messages/s in run B, so the difference in raw totals is caused mainly by
the different run durations.

Representative messages are:

(Argus) Error AlreadyAllocated: Device 0 (of 1) is in use
(NvCameraUtils) Error InvalidState: Mutex not initialized
(NvCameraUtils) Error InvalidState: Mutex has not been initialized
(NvCamV4l2) Error ModuleNotPresent: V4L2Device not available
SCF: Error BadParameter: Sensor could not be opened.
Wrong frequency range!

We found the existing community statement that Wrong frequency range! can
be ignored if the cameras work normally. We therefore do not treat that
warning alone as proof of a failed stream. Our main concern is the repeatable
AlreadyAllocated and uninitialized-mutex InvalidState combination during a
clean two-camera open on the already recommended SDK 5.4.1 / driver 1.4.3
stack.

Questions

  1. Is using two sl::Camera instances in one native process supported for two
    ZED X cameras on this ZED Box Duo stack?
  2. Are AlreadyAllocated and the uninitialized-mutex NvCameraUtils InvalidState messages expected internal enumeration/probing messages, or
    do they indicate a driver or Argus defect?
  3. Can this state affect long-term stability, frame timing, hardware sync, or
    later camera recovery even though both short streams remain functional?
  4. Are the ModuleNotPresent and BadParameter messages expected probes for
    unused device-tree modules on this carrier configuration?
  5. Is there a recommended open order, minimum delay, sync configuration, or
    newer compatible driver for JetPack 6.2.1 / L4T 36.4.4?
  6. Which messages may safely be excluded from a production health gate, and
    which ones should still be treated as a camera-stack fault?

I have attached sanitized A/B sender logs, isolated nvargus-daemon logs, a
test report with exact counts, and a fresh ZED_Diagnostic_Results.json.

Related discussions already checked:

Thank you for checking whether these messages are benign for this exact stack
or whether an additional driver fix or configuration change is required.

2

Hi @payk
Welcome to the StereoLabs community.

Thank you for a genuinely well built report; the A/B structure, the isolated nvargus-daemon windows, and the per message counts make this much faster to analyze than the usual log dump.

One general remark first, because it frames most of the individual answers. Every message in your list is emitted by the NVIDIA Argus stack (nvargus-daemon, NvCameraUtils, NvCamV4l2, SCF), not by the ZED SDK and not by the ZED X Driver. Argus prints a large part of its enumeration and probing activity at “Error” severity even when the operation that follows completes correctly, so severity in the journal is not a reliable fault indicator. Your own numbers support the benign interpretation: 12 AlreadyAllocated in both runs, identical and independent of open order and of run duration, and ModuleNotPresent in exact multiples of 30 per provider cycle. Those are fixed size probe loops, not a race and not a leak.

  1. Is using two sl::Camera instances in one native process supported for two ZED X cameras on this ZED Box Duo stack?

Yes, fully supported, and it is the configuration we recommend on a single Jetson for two ZED X cameras. The two requirements are that each sl::Camera object is grabbed from its own thread, and that the open() calls are serialized rather than concurrent; you are already doing both. Reference: Hardware Recommendations for GMSL2 cameras.

  1. Are AlreadyAllocated and the uninitialized-mutex NvCameraUtils InvalidState messages expected internal enumeration/probing messages, or do they indicate a driver or Argus defect?

They are expected probing and teardown messages, not a defect. AlreadyAllocated: Device 0 (of 1) is in use is printed when an Argus client queries a sensor device that is already owned by a live capture session, which is unavoidable when the SDK enumerates devices while the first camera is already streaming; the uninitialized mutex InvalidState lines come from the destruction of those short lived probing contexts, where the mutex was never created because the probe did not reach that stage.

  1. Can this state affect long-term stability, frame timing, hardware sync, or later camera recovery even though both short streams remain functional?

No. These messages are confined to the enumeration and open window and do not recur once both sessions are streaming, so nothing accumulates with uptime. Frame synchronization between the two ports is done by the hardware trigger generated on the carrier board, completely independent of Argus client side device arbitration, so it is not affected either; see Frame synchronization.

  1. Are the ModuleNotPresent and BadParameter messages expected probes for unused device-tree modules on this carrier configuration?

Yes. The device tree shipped with the driver package declares all the ports supported by the MAX96712 deserializer, so Argus probes the nodes of the ports with no camera attached; V4L2Device not available and SCF: Error BadParameter: Sensor could not be opened. are the expected outcome of those probes. Your count of 30 per provider cycle, invariant with respect to open order, is exactly the signature of that fixed probe over the unpopulated nodes.

  1. Is there a recommended open order, minimum delay, sync configuration, or newer compatible driver for JetPack 6.2.1 / L4T 36.4.4?

There is no recommended open order; the ports are symmetric, and your A/B result confirms it. Once open() has returned SUCCESS the device is fully acquired, so no additional delay is formally required; your two seconds are conservative and can be reduced if boot to stream time matters, keeping the calls strictly sequential. The 1.4.3-LI-MAX96712-ZEDBOX-L4T36.4.0 package is the correct one for the JetPack 6.2.x line, and I recommend checking the ZED X Driver download page from time to time, since new versions are published there.

  1. Which messages may safely be excluded from a production health gate, and which ones should still be treated as a camera-stack fault?

I would exclude from the gate: Wrong frequency range!, ModuleNotPresent: V4L2Device not available, SCF: Error BadParameter: Sensor could not be opened., and AlreadyAllocated plus NvCameraUtils InvalidState when they fall inside the open window. I would treat as a fault: those same messages appearing after both cameras are streaming, Argus Error FileOperationFailed, any camera reboot notification, Failed to connect to zed_x_daemon, and any grab() return different from ERROR_CODE::SUCCESS. My suggestion, though, is not to build the gate on the journal at all, but on the SDK side signals, which are the actual contract: the grab() return code, image timestamp continuity, and the Health Status module, which is designed exactly for this kind of production monitoring.

So, to summarize: on SDK 5.4.1 with driver 1.4.3 what you observe is normal Argus verbosity for a dual camera open, and the fact that both runs passed all ten data paths with clean exit codes is the meaningful result. If at some point the pattern changes, in particular counts growing with runtime or any of those messages appearing during streaming rather than at open, please post the new nvargus-daemon window and we will look into it, because that would be a different signature from the one described here.