hi all,
let’s enable tegrastats to monitor the utility reports to gather more details.
hi,
Below are the errors and tegrastats informantion, it doesn’t seem like it’s a temperature issue：
hello alexigu01x,
it seems all CPU resources has fully occupied.
may I know what’s the real use-case you’re worked with, and, how many camera streams you’ve enabled?
furthermore, according to Supported Modes and Power Efficiency, may I know which power-mode you’re using?
We only used dual imx283 to have 2 camera streams(one sensor to one stream) and then got the error. (We use it to recognize codes on objects in real time and read them.）
And the power-mode is:
hello alexigu01x,
thanks for sharing.
let’s narrow down this failure, please give it a try for launching camera stream only.
for example,
please enable terminal to launch camera for testing, this is sample pipeline to disable preview and shows frame-rate only.
$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v
hello alexigu01x,
please try have these two camera streaming running to verify the stream stability.
did you have display monitor connected? it may due to you’re not having HDMI or DP connected to report such error.
FYI, the goal of nvphsd is to adjust power/performance of the CPU Cores, to meet the right balance based on the hints obtained from system during run time. for camera, it is based on fps.
you may ignore those nvphs errors at the moment as they’re not effect camera use-case.
or… please try adding display_state_fmt=/dev/null to workaround this error report.
hello alexigu01x,
please test again by updating pre-built binary, (libnvfusacap.so and libnvargus.so) with the attachment,
for instance, Topic277276_Jan08.zip (507.2 KB)
I changed the two files but after reboot, the stream couldn’t run. And when I changed back to the previous file, it could run.
hello alexigu01x,
let me double confirm, you’re based-on l4t-r35.4.1 to replace those two binaries, right?
please also share your steps for reference, thanks
hello alexigu01x,
it’s my mistake, it’s an incorrect build dependency for libnvfusacap.so.
I’ve rebuild and repack binary files, please try again with this attachment, Topic277276_Jan09.zip (507.2 KB)
After the update, I got the same error from the two streams：
Here are the logs:
daemon.txt (12.8 KB)
dmesg_logs.txt (82.0 KB)
hello alexigu01x,
kernel has reported… Tachometer Overflow is detected, but this may not harmful as system still alive.
it looks like race condition, or, sensor stream stability with nvarguscamerasrc.
could you please further narrow down by running with v4l2 standard IOCTL.
for example,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap
I’ll also arrange resources to check whether we’re able to repo this locally.
hello alexigu01x,
it’s reporting discarding frame messages, which meant it’s VI to drop the capture buffers due to errors.
please dump the sensor support formats, you should specify the same settings to the v4l pipeline.
$ v4l2-ctl -d /dev/video0 --list-formats-ext
Hi,
I changed the pixelformat to RG12 but all the width/height could only reach 19.98fps(e.g. the 3872*2174 supposed to have 60 fps but still 19.98 fps)
While my sensor supposed to support both RG10 and RG12 but when I used RG10, there was no outputs and had errors(I tried all the fps):
hello alexigu01x,
it’s likely driver side choosing 1st sensor mode (5496x3694@20-fps) for streaming.
to avoid this, you may add an optional Device Properties, use_sensor_mode_id to the device tree.
after that, you’ll able to enable mode selection, i.e. --set-ctrl sensor_mode=<N>
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=RG10 --set-ctrl bypass_mode=0 --set-ctrl sensor_mode=4 --stream-mmap --stream-count=100
FYI,
we’ve also test dual cam long-run streaming, it’s based-on Xavier NX / dual IMX219.
it’s confirmed we could have dual camera streaming for 12+ hours without issues. (tested via libargus)
please verify your sensor stream with v4l2 standard IOCTL.
it might be an issue of sensor driver if you still reproduce stability issue.