Vi-output 100% CPU loading

We use the xavier module to connect 4 cameras.
With JetPack 4.6.1 , Use v4l2-ctl to capture the image, it stucks after a while with error log "tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 512 "or “tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072”
Top tools show the vi-ouput use system resource 100%
Here is the trace log:
vi-output_100%.log (59.0 MB)

This issue can be reproduced in JetPack 5.1.

It’s VI’s bug, When there is an error code, it will enter an abnormal state and the spin lock will not be released.

Hi zheng,
Thank you for your reply!
I set the capture_state = CAPTURE_ERROR and reset the capture channel in this case, but it not work sometimes.
Is there any solutions?

Need to modify the code in the VI part of the kernel. I think this is a bug in nvidia, but they haven’t fixed it.

hello liucz19,

it’s capture erroneous to report discarding frame for dropping capture buffer.
may I know what’s the camera module you’re using, is it only failure by multi-cam use-case?

Hi Jerry,
The camera module use GMSL serializer max96705 and deserializer max96712.
It’s also failure by single-cam use-case.

hello liucz19,

is it actually output frames to CSI channel?
since it’s a SerDes chip, which usually has capability to enable test-pattern. could you please have a try to enable it for issue narrow down, thanks

Hi Jerry,
Yes, it outputs frames to CSI channel. Enable test-pattern, this issue did not reproduce.
The log shows" err_data 131072 (2000h) and 512 (200h) " when the mipi signal is bad, then vi-output thread goes to unnomal state.
I think it needs to reset vi channel and nvcsi stream when it happens.

hello liucz19,

am I understand correctly there’s MIPI signaling intermittent of your real use-case?

please see-also Topic 243051.
there’s known issue of nvarguscamera doesn’t recover from single NVCSI failure.
it turns out an issue of Argus error handling regression.
we’ve arrange resources for investigation, you should also expect this error handling mechanism won’t be fix soon.

Hi Jerry,
Yes, the mipi signal is unstable.
This issue is very critical for our project. We need to get this resolved asap.

hello liucz19,

as I mentioned. this error handling mechanism won’t be fix soon.

here’s pre-built update to include Argus stability fixes. please refer to Topic 243051, comment #36.
you may based-on JetPack-5.1.1/l4t-r35.3.1 to update the binaries for verification.

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