Argus sample oneShot fails with option '-d 1' although /dev/video1 works perfectly with v4l2 (jetpack-4.3)

Hello,

I have compiled successfully the oneshot example, called argus_oneshot, and I can run it successfully without option, thus using my first sensor. I have a second identical sensor on the same board, that works perfectly with v4l2, but running argus_oneshot with option ‘-d 1’ fails with the message

Failed to get IFrame interface

, while the kernel has issued a

fence timeout on [ffffffc1e6809c00] after 1500ms

message. Should argus_oneshot work with the second sensor or is that an expected behaviour ?

Thereafter, trying to use sensor 0 does not work anymore, until I reboot my board.

My two identical sensors are connected using 4 mipi lanes each, on csi 1 and csi 2.

Both of them are working by v4l2-ctl?

Yes :

nvidia@cam5-0000:~ v4l2-ctl -d 0 --stream-mmap=3 --stream-count=256 --set-fmt-video=width=2464,height=2056,pixelformat=BG12 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 36.00 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.82 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.76 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.75 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.72 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.71 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.71 fps <<<<< nvidia@cam5-0000:~ v4l2-ctl -d 1 --stream-mmap=3 --stream-count=256 --set-fmt-video=width=2464,height=2056,pixelformat=BG12
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 36.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.82 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.76 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.75 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.72 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.71 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35.71 fps
<<<<<
nvidia@cam5-0000:~$

nvcamerasrc also works with both sensors; see attached log.
nvcamerasrc.log (4.8 KB)

How about others sample APP?

I am on a custom board, using ssh. I have no display. Which samples are expected to work ?

I have also tested yuvJpeg (argus_yuv_jpeg). It works with the default option or ‘-d 0’. Like oneShot, it also fails with ‘-d 1’, and afterwards ‘-d 0’ does not work anymore.

How about the gst-launch-1.0?

export DISPLAY=:0
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12' ! nvvidconv ! fpsdisplaysink video-sink=fakesink --verbose
gst-launch-1.0 nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12' ! nvvidconv ! fpsdisplaysink video-sink=fakesink --verbose

That works with sensor-id=0, but fails with sensor-id=1.
It blocks after

CONSUMER: Producer has connected; continuing.

and the serial console shows

[ 166.806202] host1x 13e10000.host1x: CaptureSchedule: syncpoint id 19 (15600000.isp_nvargus-daemon_4) stuck waiting 753, timeout=-1
[ 170.902255] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 35 (15700000.vi_2) clientid 1486, HW thresh 12, done 13
[ 170.913697] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 34 (15700000.vi_1) clientid 1486, HW thresh 14, done 15
[ 170.924851] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 33 (15700000.vi_0) clientid 1486, HW thresh 1, done 1
[ 170.939220] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 15 (15600000.isp_nvargus-daemon_0) clientid 1477, HW thresh 735, done 737
[ 170.951792] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 16 (15600000.isp_nvargus-daemon_1) clientid 1477, HW thresh 735, done 736
[ 170.964386] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 17 (15600000.isp_nvargus-daemon_2) clientid 1477, HW thresh 735, done 736
[ 170.976970] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 18 (15600000.isp_nvargus-daemon_3) clientid 1477, HW thresh 5157, done 5158
[ 170.989772] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 31 (15600000.isp_nvargus-daemon_5) clientid 1477, HW thresh 32, done 33
[ 171.002371] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 19 (15600000.isp_nvargus-daemon_4) clientid 1477, HW thresh 750, done 750
[ 181.142371] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 35 (15700000.vi_2) clientid 1486, HW thresh 14, done 15
[ 181.153955] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 34 (15700000.vi_1) clientid 1486, HW thresh 16, done 17
[ 181.165175] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 33 (15700000.vi_0) clientid 1486, HW thresh 3, done 3
[ 181.178239] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 15 (15600000.isp_nvargus-daemon_0) clientid 1477, HW thresh 739, done 741
[ 181.191022] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 16 (15600000.isp_nvargus-daemon_1) clientid 1477, HW thresh 737, done 738
[ 181.203813] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 17 (15600000.isp_nvargus-daemon_2) clientid 1477, HW thresh 737, done 738
[ 181.216464] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 18 (15600000.isp_nvargus-daemon_3) clientid 1477, HW thresh 5159, done 5160
[ 181.229284] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 31 (15600000.isp_nvargus-daemon_5) clientid 1477, HW thresh 34, done 35
[ 181.241991] host1x 13e10000.host1x: cdma_handle_timeout: timeout: 19 (15600000.isp_nvargus-daemon_4) clientid 1477, HW thresh 766, done 766

Enable the log and enable run the sensor-id=1

https://elinux.org/Jetson_TX2_Camera_BringUp#Steps_to_enable_more_debug_messages

Sorry for the noise, ShaneCCC,

it works now; I had added printk’s to tegra_ivc_vi_notify_get_capture_status to ascertain that that function was used also when acquiring with argus (after I had already checked that it is used with v4l2). Those two added printk’s were enough to trigger a timeout for sensor 1, although they are innocuous for sensor 0. I didn’t check further. I only notice that without the printk’s, sensor 1 works again. I just must add that I managed to get UTC timestamps so the printk(ts) takes a little bit more time than with uptime timestamps.

static int tegra_ivc_vi_notify_get_capture_status(struct device *dev,
unsigned ch,
u64 index,
struct vi_capture_status *status)
{
struct tegra_ivc_channel *chan = to_tegra_ivc_channel(dev);
struct tegra_ivc_vi_notify *ivn = tegra_ivc_channel_get_drvdata(chan);
struct vi_capture_status __iomem *status_mem =
&ivn->status_mem[ch * ivn->status_entries];
int err = 0;

printk(“tivngcs(%u,%llu)\n”, ch, index);
if (ivn->status_entries != 0) {
index &= ivn->status_entries - 1;
memcpy_fromio(status, &status_mem[index], sizeof(*status));

            if (ivn->adjust_ts_counter % ADJUST_TS_FREQUENCY == 0)
                    ivn->ts_adjustment = get_ts_adjustment(ivn->ts_res_ns);

            if (status->sof_ts != 0) {
                    s64 ts = (s64)status->sof_ts;
                    ts += ivn->ts_adjustment;
                    status->sof_ts = (u64)ts;

printk("-> %llu\n", (u64)ts);
}

            if (status->eof_ts != 0) {
                    s64 ts = (s64)status->eof_ts;
                    ts += ivn->ts_adjustment;
                    status->eof_ts = (u64)ts;
            }

            ivn->adjust_ts_counter++;
    } else {
            err = -ENOTSUPP;
    }
    return err;

}

I don’t have idea for it now. Could you check if add some delay help on it?