hi Laurent and all who it may concern,
Ever since I switches to using imx7-media-csi on imx8mq I have seen a
bug that hangs /freezes the system so that I can't really save a trace
or get logs for it. It happens not every time when starting streaming,
but sometimes - when starting to stream frames.
It kind of looks like a lock not released or something similar, but
some race condition might happen since it's happening every 2 to 10
times.
For me, when it fails, it fails the first time when starting to stream
after rebooting. If it succeeds that first time, it continues to
succeed, until I reboot.
The last logs I can see currently in the failing case are
[ 37.811693] videobuf2_common: [cap-00000000e2303470]
__setup_offsets: buffer 0, plane 0 offset 0x00000000
[ 37.824161] videobuf2_common: [cap-00000000e2303470]
__setup_offsets: buffer 1, plane 0 offset 0x003d0000
[ 37.836844] videobuf2_common: [cap-00000000e2303470]
__setup_offsets: buffer 2, plane 0 offset 0x007a0000
[ 37.849406] videobuf2_common: [cap-00000000e2303470]
__setup_offsets: buffer 3, plane 0 offset 0x00b70000
[ 37.860091] videobuf2_common: [cap-00000000e2303470]
__vb2_queue_alloc: allocated 4 buffers, 1 plane(s) each
[ 37.870770] videobuf2_common: [cap-00000000e2303470] vb2_mmap:
buffer 0, plane 0 successfully mapped
[ 37.880155] videobuf2_common: [cap-00000000e2303470] vb2_mmap:
buffer 1, plane 0 successfully mapped
[ 37.889532] videobuf2_common: [cap-00000000e2303470] vb2_mmap:
buffer 2, plane 0 successfully mapped
[ 37.898880] videobuf2_common: [cap-00000000e2303470] vb2_mmap:
buffer 3, plane 0 successfully mapped
[ 37.908127] videobuf2_common: [cap-00000000e2303470] vb2_core_qbuf:
qbuf of buffer 0 succeeded
[ 37.916949] videobuf2_common: [cap-00000000e2303470] vb2_core_qbuf:
qbuf of buffer 1 succeeded
[ 37.925659] videobuf2_common: [cap-00000000e2303470] vb2_core_qbuf:
qbuf of buffer 2 succeeded
[ 37.934395] videobuf2_common: [cap-00000000e2303470] vb2_core_qbuf:
qbuf of buffer 3 succeeded
[ 38.077613] videobuf2_common: [cap-00000000e2303470]
vb2_core_streamon: successful
[ 38.085523] videobuf2_common: [cap-00000000e2303470]
__vb2_wait_for_done_vb: will sleep waiting for buffers
but sometimes I see it hang a few lines later:
[ 60.996573] videobuf2_common: [cap-00000000eb3bac3a]
__vb2_wait_for_done_vb: will sleep waiting for b
uffers
[ 61.048564] imx7_csi_vb2_buf_done: start
[ 61.052514] videobuf2_common: vb2_buffer_done: start
[ 61.057478] videobuf2_common: [cap-00000000eb3bac3a]
vb2_buffer_done: done processing on buffer 0, st
ate: done
[ 61.067479] videobuf2_common: [cap-00000000eb3bac3a]
__vb2_buf_mem_finish: call_memop(0, finish)
[ 61.076268] videobuf2_common: vb2_buffer_done: waking up done_wq
the vb2 logs with advanced debugging preceding these, are identical in
the success and failing case.
With the exact same sensor driver but the nxp CSI driver
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/mxc/capture/mx6s_capture.c?h=imx_5.4.0_8dxlphantom_er
is never happened (and the mipi driver is most likely not the issue
since it's controller config that should be exactly the same as well).
In the success case then imx7_csi_vb2_buf_done() gets called then.
I'm quite confident now that it's a bug in imx7-media-csi since it uses
the buffers.
So what's happening? I really don't yet know. Any idea?
thank you,
martin
and the success case continues like so (with some more debug prints
that in mainline):
[ 26.493415] videobuf2_common: [cap-00000000500f079b]
__vb2_wait_for_done_vb: will sleep waiting for b
uffers
[ 26.531273] imx7_csi_vb2_buf_done: start
[ 26.535238] videobuf2_common: [cap-00000000500f079b]
vb2_buffer_done: done processing on buffer 0, st
ate: done
[ 26.545261] videobuf2_common: vb2_buffer_done: waking up done_wq
[ 26.551284] imx_media_capture_device_next_buf: start
[ 26.551294] videobuf2_common: [cap-00000000500f079b]
__vb2_wait_for_done_vb: loop done
[ 26.556259] imx_media_capture_device_next_buf: ok
[ 26.563269] imx7_csi_vb2_buf_done: start
and so on
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hello Martin,
Am Freitag, dem 12.11.2021 um 12:23 +0100 schrieb Martin Kepplinger:
hi Laurent and all who it may concern,
Ever since I switches to using imx7-media-csi on imx8mq I have seen a
bug that hangs /freezes the system so that I can't really save a trace
or get logs for it. It happens not every time when starting streaming,
but sometimes - when starting to stream frames.
It kind of looks like a lock not released or something similar, but
some race condition might happen since it's happening every 2 to 10
times.
For me, when it fails, it fails the first time when starting to stream
after rebooting. If it succeeds that first time, it continues to
succeed, until I reboot.
When I read your description I was immediately reminded to this post on
NXP forums [1].
I do not know if this is what is happening to you, but it sounds
somewhat similar. There is also an errata in post [2] describing some
backgrounds. Later posts also describe that apparently only CSI port 1
is affected, but CSI port 2 is not.
Do you have the possibility to test CSI port 2?
Best regards,
Alexander
[1] https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1218063
[2] https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1216509/highlight/true#M167970
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Am 12. November 2021 13:40:43 MEZ schrieb Alexander Stein [off-list ref]:
Hello Martin,
Am Freitag, dem 12.11.2021 um 12:23 +0100 schrieb Martin Kepplinger:
quoted
hi Laurent and all who it may concern,
Ever since I switches to using imx7-media-csi on imx8mq I have seen a
bug that hangs /freezes the system so that I can't really save a trace
or get logs for it. It happens not every time when starting streaming,
but sometimes - when starting to stream frames.
It kind of looks like a lock not released or something similar, but
some race condition might happen since it's happening every 2 to 10
times.
For me, when it fails, it fails the first time when starting to stream
after rebooting. If it succeeds that first time, it continues to
succeed, until I reboot.
When I read your description I was immediately reminded to this post on
NXP forums [1].
I do not know if this is what is happening to you, but it sounds
somewhat similar. There is also an errata in post [2] describing some
backgrounds. Later posts also describe that apparently only CSI port 1
is affected, but CSI port 2 is not.
Do you have the possibility to test CSI port 2?
yes but I can only say that csi port 2 behaves better while I have seen a lockup there too. That too matches your links' issue description. I dont have logs from port 2 yet.
Thanks a lot, there's at least something new to test I think. Let's see whether a kernel thread would work instead of an m4 program.
But why haven't I ever seen the problem on the mx6s_capture nxp driver? That doesn't fit the picture yet for me.
Best regards,
Alexander
[1] https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1218063
[2] https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1216509/highlight/true#M167970
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Am Freitag, dem 12.11.2021 um 15:49 +0100 schrieb Martin Kepplinger:
Am 12. November 2021 13:40:43 MEZ schrieb Alexander Stein
[off-list ref]:
quoted
Hello Martin,
Am Freitag, dem 12.11.2021 um 12:23 +0100 schrieb Martin
Kepplinger:
quoted
hi Laurent and all who it may concern,
Ever since I switches to using imx7-media-csi on imx8mq I have
seen a
bug that hangs /freezes the system so that I can't really save a
trace
or get logs for it. It happens not every time when starting
streaming,
but sometimes - when starting to stream frames.
It kind of looks like a lock not released or something similar,
but
some race condition might happen since it's happening every 2 to
10
times.
For me, when it fails, it fails the first time when starting to
stream
after rebooting. If it succeeds that first time, it continues to
succeed, until I reboot.
When I read your description I was immediately reminded to this
post on
NXP forums [1].
I do not know if this is what is happening to you, but it sounds
somewhat similar. There is also an errata in post [2] describing
some
backgrounds. Later posts also describe that apparently only CSI
port 1
is affected, but CSI port 2 is not.
Do you have the possibility to test CSI port 2?
yes but I can only say that csi port 2 behaves better while I have
seen a lockup there too. That too matches your links' issue
description. I dont have logs from port 2 yet.
Thanks a lot, there's at least something new to test I think. Let's
see whether a kernel thread would work instead of an m4 program.
But why haven't I ever seen the problem on the mx6s_capture nxp
driver? That doesn't fit the picture yet for me.
quoted
Best regards,
Alexander
[1]
https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1218063
[2]
https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1216509/highlight/true#M167970
this seems to be fixed by
https://lore.kernel.org/linux-media/20211117092710.3084034-1-martin.kepplinger@puri.sm/T/#t
the issue described in the nxp forums should be taken care of by the
underrun (or called "discard" in the nxp driver) buffer in the driver.
thank you!
martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel