libv4l2: error setting pixformat: Device or resource busy

Hi,

I try to restart a few pipelines (6) after stopping “recording”. Prior to stop encoding I set the pipeline to GST_STATE_PAUSED and then GST_STATE_NONE and finally unreffing the pipeline. BTW, I tried some delays between the above mentioned state changes (no sufficient results).
When I restart the pipelines (regenrate the whole pipelines and then set them to GST_STATE_PLATIN) some of the pipeline start while other claim that the a device is busy “libv4l2: error setting pixformat: Device or resource busy”.

I have attached a log where 6 channels are encoding and then manually stopped, followed by another attempt to run where only one channel (2) starts and the others clame to be busy.

All pipelines are running from within the same process.

Please advise.

device busy.txt (611 KB)

Hi,
If you run r28.2.1, please check https://elinux.org/Jetson_TX2/28.2.1_patches

DaneLLL, hi,

how should *.so files be installed? I have overwritten previous files and recompiled the kernel image, is it correct?

DaneLLL, hi,

how should *.so files be installed? I have overwritten previous files and recompiled the kernel image, is it correct?
I think that got all updated but I am getting now the following error during piepline running:

[  163.988588] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  164.005267] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  164.015262] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_INTR_STATUS 0x00000044
[  164.023339] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_ERR_INTR_STATUS 0x00000044
[  164.038602] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  164.049538] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x00000004
[  164.058087] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x00000004
[  164.066392] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_INTR_STATUS 0x00000044
[  164.074406] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_ERR_INTR_STATUS 0x00000044
[  164.088564] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  164.099477] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_INTR_STATUS 0x00000044
[  164.107697] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_ERR_INTR_STATUS 0x00000044
[  164.188662] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  164.201567] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x00000004
[  164.209529] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x00000004
[  164.217797] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_INTR_STATUS 0x00000044
[  164.225820] nvcsi 150c0000.nvcsi: csi4_cil_check_status (2) CIL_ERR_INTR_STATUS 0x00000044
[  164.238607] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel

I have also attached the suspicious files: csi4_fops.c and vi4_fops.c.

Please advise.

vi4_fops.c (29.9 KB)
csi4_fops.c (18.5 KB)

Hi,
You may try to apply below prebuilt lib only.
https://devtalk.nvidia.com/default/topic/1043548/jetson-tx1/-mmapi-please-merge-two-libtegrav4l2-so-that-modify-different-issues/post/5294104/#5294104
It is a known issue on r28.2.1 and your issue looks similar to it.

DaneLLL, hi,

and this goes to my first question: how should *.so files be installed? I have overwritten previous files and recompiled the kernel image, is it correct?

Hi,
Please replace the one in /usr/lib/aarch64-linux-gnu/tegra. It is not required to rebuild kernel.

Hi,
I’ve copied the libtegrav4l2.so to /usr/lib/aarch64-linux-gnu/tegra, restarted the machine and got the same results, the device or resource are busy.

Please advise.

Hi,
Please try to run one encoding thread in one process. Multiple encoding threads in one process may not work properly. We are evaluating to support this usecase in future r32 releases.

DaneLLL,

I am very sorry to hear it. Our project is based on it. We decided to go with the TX2i like to years ago…
What are you saying that we need to replace the whole architecture?

Please advise.

Hi,
Please share a patch on 01_video_encode or either sample so that we can reproduce the failure. All reference samples are single encoding thread and need modification to run multiple threads.

DaneLLL,hi,
It is possible that I was not clear. I produce six independent GStreamer pipelines which are provided video from v4l2src element. All pipelines are running in the same application. When I shut down the pipeline the v4l2src elements are still occupied although I have set the pipeline to GST_STATE_NONE and then unreffed. When I start again the “busy” note is displayed randomly among the pieplines.
So, I do not understand the reference to 01_video_encode.
Please elaborate.

Hi,
01_video_encode is a tegra_multimedia_api sample.

For using gstreamer, some plugins are from 3rdparty. Do you observe the issue in running ‘v4l2src ! fakesink’? Or it is triggered by adding encoder to run ‘v4l2src ! nvvidconv ! omxh264enc ! fakesink’?

DaneLLL, hi,

The first option does not fail, while the second option fails.

Hi,
It looks same as 1056389 reported on r32. We will try to reproduce it on r28.

Since we have well verified single encoding thread in each process, it would be great if you can switch to this case.

Hi,
We try to run this sample for 1+ hour but don’t hit any error.

Please check if you can share a patch on it to make it close to your case and we can reproduce the issue.
There are only one USB3 port on developer kit so it may hit bandwidth limitation in launching 6 v4l2 sources(USB cameras). If it can be reproduced with videotestsrc, please use videotestsrc.