162.065032] tegra-vi4 15700000.vihttp://15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 162.071598] tegra-vi4 15700000.vihttp://15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
Hi anupam.kumar,
Please help to provide more details of this issue, such as camera info, reproduce steps, JetPack version…etc.
i am using SDK 32.4.3 on Tx2 EVK,it is compiled image from these sdk and i am using ov2735 sensor with Tx2 EVK,my probe got success and after that i am trying to take raw image from sensor.
in tx2 EVK ov5693 is inbuild so i have replaced these with ov2735 using same csi line,i2c bus and mclk0.
command running:
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=500 -d /dev/video0 --stream-to=ov2735.raw
error getting:
[ 64.443650] ov2735 2-003c: camera_common_mclk_enable:calledream-to=ov2735.raw
[ 64.449288] ov2735 2-003c: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[ 64.457183] ov2735 2-003c: camera_common_mclk_enable:function exit
[ 64.463459] ov2735 2-003c: ov2735_power_on: power on
[ 64.472596] ov2735 2-003c: ov2735_power_on: power on exit
[ 64.487396] ov2735 2-003c: ov2735_set_mode: called with set mode value 0
162.065032] tegra-vi4 15700000.vihttp://15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 162.071598] tegra-vi4 15700000.vihttp://15700000.vi: tegra_channel_error_recovery: attempting to reset the
This error i am getting,when i trace this with kernel debug i found below message
root@linux:/home/ubuntu# cat /sys/kernel/debug/tracing/trace
tracer: nop
entries-in-buffer/entries-written: 27/27 #P:4
_-----=> irqs-off
/ _----=> need-resched
| / _—=> hardirq/softirq
|| / _–=> preempt-depth
||| / delay
TASK-PID CPU# |||| TIMESTAMP FUNCTION
| | | |||| | |
kworker/4:0-36 [004] .... 103.117994: rtos_queue_peek_from_isr_failed: tstamp:3500119660 queue:0x0b4b4500
kworker/4:0-36 [004] .... 103.285929: rtos_queue_peek_from_isr_failed: tstamp:3505119652 queue:0x0b4b4500
kworker/4:0-36 [004] .... 103.457884: rtos_queue_peek_from_isr_failed: tstamp:3510119646 queue:0x0b4b4500
kworker/4:0-36 [004] .... 103.625840: rtos_queue_peek_from_isr_failed: tstamp:3515119640 queue:0x0b4b4500
kworker/4:0-36 [004] .... 103.737795: rtos_queue_peek_from_isr_failed: tstamp:3520119634 queue:0x0b4b4500
kworker/4:0-36 [004] .... 103.905766: rtos_queue_peek_from_isr_failed: tstamp:3525119626 queue:0x0b4b4500
kworker/4:0-36 [004] .... 104.073730: rtos_queue_peek_from_isr_failed: tstamp:3530119618 queue:0x0b4b4500
kworker/4:0-36 [004] .... 104.241665: rtos_queue_peek_from_isr_failed: tstamp:3535119611 queue:0x0b4b4500
kworker/4:0-36 [004] .... 104.409617: rtos_queue_peek_from_isr_failed: tstamp:3540119606 queue:0x0b4b4500
kworker/4:0-36 [004] .... 104.577562: rtos_queue_peek_from_isr_failed: tstamp:3545119599 queue:0x0b4b4500
kworker/4:0-36 [004] .... 104.745568: rtos_queue_peek_from_isr_failed: tstamp:3550119593 queue:0x0b4b4500
kworker/4:1-811 [004] .... 104.857484: rtos_queue_peek_from_isr_failed: tstamp:3555119585 queue:0x0b4b4500
can you please help on this.
The trace log tells NVCSI/VI didn’t receive any data from the MIPI bus.
You may need to probe the MIPI signal to make sure the sensor output is as spec.