Nvarguscamerasrc dmabuf_fd -1 mapped entry NOT found

Hi folks, I am trying to use nvarguscamerasrc and move off of nvv4l2camerasrc. I am pretty sure the camera is compatible but I run into an error.

This is the pipeline: gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1536, format=(string)NV12, framerate=(fraction)30/1' ! filesink location=argust.mp4 -e

This is the error

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 1920 x 1536 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;

GST_ARGUS: Running with following settings:
   Camera index = 0 
   Camera mode  = 0 
   Output Stream W = 1920 H = 1536 
   seconds to Run    = 0 
   Frame Rate = 29.999999 
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadExecute:694 NvBufSurfaceFromFd Failed.
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadFunction:247 (propagating)
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: INVALID_SETTINGS
Additional debug info:
Argus Error Status
EOS on shutdown enabled -- waiting for EOS after Error
Waiting for EOS...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Interrupt while waiting for EOS - stopping pipeline...
Execution ended after 0:00:34.284225531
Setting pipeline to NULL ...
GST_ARGUS: Cleaning up
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 137)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 91)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 137)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 91)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 137)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 91)
Freeing pipeline ...
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 137)
(Argus) Error Timeout:  (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 91)
(Argus) Error InvalidState: Argus client is exiting with 4 outstanding client threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 366)

Also after I run it for the first time I think that it still holds onto the camera which makes the following error for every subsequent time I run the above pipeline:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:762 Failed to create CaptureSession
Got EOS from element "pipeline0".
Execution ended after 0:00:00.001238145
Setting pipeline to NULL ...
Freeing pipeline ...

Package: nvidia-jetpack
Version: 5.1-b147
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 5.1-b147), nvidia-jetpack-dev (= 5.1-b147)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_5.1-b147_arm64.deb

On the Orin nx.

I am new to developing on Jetson so if you have advice on how to do things like modifying the device tree or where flags should be added, that would be much appreciated.

Thanks and let me know if there any other specs needed to properly help debug this issue. @ShaneCCC

The subsequent error you are seeing is due to Argus getting into a bad state. You can reset the Argus daemon with the following command (requires sudo privileges):

systemctl restart nvargus-daemon

As for the dmabuf_fd -1 error, that is likely happening due to some error in the Sensor → CSI → VI pipeline. There are a few questions that need to be answered before we can debug further:

  • Which camera are you using?
  • Are you using a custom baseboard?
  • Have you made device tree modifications?
  • Are you using JetPack or a Yocto based distro (answer seems to be JetPack but it is worth confirming)
  • Does the pipeline work with nvv4l2camerasrc?
  • What output results from v4l2-ctl --device /dev/video0 --stream-mmap?
  • What output results from media-ctl -p?

Here are some resources you may find helpful for understanding Camera Development for Jetson as well:

If you have made device tree changes, then that is most likely where the issue is. It is a pain to debug but I would say to focus on your camera’s pipeline.

Thank you for your reply! systemctl restart did the trick for the subsequent errors.

The dma buffer error is still there though.

Also this pipeline works: gst-launch-1.0 nvv4l2camerasrc ! nvvidconv ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1536, format=(string)NV12, framerate=(fraction)30/1' ! filesink location=argust.mp4 -e

As far as the camera is concerned I am using leopard camera that I have been assured supports Argus.

We are using JetPack.

nothing gets output from 4l2-ctl --device /dev/video0

this is the output of media-ctl -p

Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		<- "isx031 0-001a":0 [ENABLED]
	pad1: Source
		-> "vi-output, isx031 0-001a":0 [ENABLED]

- entity 4: 13e40000.host1x:nvcsi@15a00000- (2 pads, 0 link)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
	pad0: Sink
	pad1: Source

- entity 7: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev2
	pad0: Sink
		<- "isx031 0-001c":0 [ENABLED]
	pad1: Source
		-> "vi-output, isx031 0-001c":0 [ENABLED]

- entity 10: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev3
	pad0: Sink
		<- "isx031 0-001d":0 [ENABLED]
	pad1: Source
		-> "vi-output, isx031 0-001d":0 [ENABLED]

- entity 13: isx031 0-001a (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev4
	pad0: Source
		[fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 15: vi-output, isx031 0-001a (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video0
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

- entity 33: isx031 0-001c (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev5
	pad0: Source
		[fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 35: vi-output, isx031 0-001c (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

- entity 45: isx031 0-001d (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev6
	pad0: Source
		[fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 47: vi-output, isx031 0-001d (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video2
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

Thanks again for helping @pwolfe1 !

My bad, the command should actually be v4l2-ctl --device /dev/video0 --stream-mmap (just updated my post)

If nvv4l2camerasrc works, to me that says your driver is fine. I am honestly less familiar with debugging Argus specifically than Linux cameras in general but you do see any error output in dmesg or journalctl -u nvargus-daemon that corresponds to the failed attempts to access the camera timestamp-wise?

No worries, the output is:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<^C

Hmm, I don’t remember if these logs correspond to a previous run, but it is likely

-- Logs begin at Thu 2022-09-08 02:58:15 PDT, end at Fri 2023-03-10 12:07:08 PST. --
Mar 10 11:19:52 x1-fs systemd[1]: Started Argus daemon.
Mar 10 11:46:54 x1-fs systemd[1]: Stopping Argus daemon...
Mar 10 11:46:54 x1-fs nvargus-daemon[1182]: === NVIDIA Libargus Camera Service (0.98.3)=== Listenin>
Mar 10 11:46:54 x1-fs systemd[1]: nvargus-daemon.service: Succeeded.
Mar 10 11:46:54 x1-fs systemd[1]: Stopped Argus daemon.
Mar 10 11:46:54 x1-fs systemd[1]: Started Argus daemon.
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: === NVIDIA Libargus Camera Service (0.98.3)=== Listenin>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: OFParserListModules: module list: /proc/device-tree/teg>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: OFParserListModules: module list: /proc/device-tree/teg>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: OFParserListModules: module list: /proc/device-tree/teg>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclHwGetModuleList: No module data found
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclHwGetModuleList: No module data found
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclHwGetModuleList: No module data found
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclHwGetModuleList: No module data found
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: OFParserGetVirtualDevice: NVIDIA Camera virtual enumera>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: ---- imager: No override file found. ----
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: ---- imager: No override file found. ----
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: (NvCamV4l2) Error ModuleNotPresent: V4L2Device not avai>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: (NvCamV4l2) Error ModuleNotPresent:  (propagating from >
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: (NvOdmDevice) Error ModuleNotPresent:  (propagating fro>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclDriverInitializeData: Unable to initialize driver >
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclInitializeDrivers: error: Failed to init camera su>
Mar 10 11:47:07 x1-fs nvargus-daemon[4154]: NvPclStartPlatformDrivers: Failed to start module drive>

I cannot recreate these logs when I do gst launch again though

Sorry for the delay. We are using a custom board but the jetson boards don’t have any modifications. The driver does apparently patch the kernel with a dtb file. Do you think I should look into that file to find the error?

camera - isx031 by leopard

If you are able to get good-looking video from nvv4l2camerasrc I feel like your driver is probably fine. I think we need to hear from an NVIDIA person or someone else with deeper Argus knowledge.

Just wondering, why are you trying to move from the V4L2 element to Argus? From my understanding nvv4l2camerasrc is more stable / production ready than Argus but I may have misunderstood.

It is my understanding that Argus is much better for CSI enabled cameras because it can use the ISP connection as well. I don’t have a detailed explanation but I have heard from people more qualified than me that it is better. Also I think that leopard are changing the device tree as well in some patch files they have for us. Hopefully someone from Nvidia or Leopard can help here.

1 Like

Hi @_saarth ,
If I’m not mistaken, that sensor uses serdes, right? We encountered a similar problem and the fix was to change the serdes clk on the driver level, and depending on the data rate enable skew calibration. You can check more over here.

Regards,
Andres
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

2 Likes

Thanks for your tip Andres. I will look into it. As far as the data rate, are you referring to the bit rate of the feed?

The data rate is defined by the deserializer, for example this TI one.
The data rate is controled with the registers and in this case, is this section:
image
So it depends on the deserializer that you are using and how you set those data rates, if controllable.

1 Like

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