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.