General error queue is out of sync with frame queue;csi5_stream_close: csi_port=3;corr_err: discarding frame 0, flags: 0, err_data 131072


Thanks to this community, I successed to enable our customized sensor.
However, I have an issue during streaming.

Some cameras stturted and dmesg shows this error after running for a while
NVIDIA Jetson AGX Orion
OS:Linux5.10 Jetpack5.10
log.txt (9.4 KB)

Under the same sensor serdes configuration, the Xavier chip platform is normal and the Orion platform is not normal

Check the pix_clk_hz configure for below know problem.
Also try to boost the clocks if output large resolution.

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:

Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)

We reserve 12 senors (11 are actually connected), one of which is a 9296 deserializer connected to 2 sensors, all sensors can be started during the start-up phase, and some sensors have no video after running for a period of time
Each sensor uses 2lane, set mipi date rate = 1.2G, pix_clk_hz = 1.2G*2(lane)/16(bits per pixel)=150000000, is there any problem with the dts setting

The pix_clk_hz looks fine.
Try boost the clocks to check if still have problem get the trace log to get more information.

The problem exists after booting the clock. The trace log file is as follows.all sensors can be started during the start-up phase, and some sensors have no video after running for a period of time
log.txt (9.4 KB)

Did you try 15fps or less?

The camera defaults to 22 frames, the application layer only uses 10 frames, still having problems. Reducing the sensor drive output to less than 15 frames as well?

Please modify below timeout value in vi5_fops.c to try.


Reference to below document for kernel driver.

#define CAPTURE_TIMEOUT_MS 2500, the problem remains,The problem is that the frame is lowered first until the video is broken,How to deal with the drop frame problem?

Did you boost the clocks to try?

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

The following attempts were made:

  1. Reduce the frame rate
  2. #define CAPTURE_TIMEOUT_MS 5000
  3. Boost the clocks
  4. adjust pix_clk_hz
    None of the above is invalid

Could it be that EOF Missing is causing this problem? How to solve the problem of eof missing?

How about increase the timeout to infinite?

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.

Is this still an issue to support? Any result can be shared? Thanks