Is there a patch for v4l2/mt9p031 kernel panic

[patsandt]

4.1.18 kernel, iMX6, custom board based on sabre-lite. I'm testing repeated image captures using gstreamer. Usually the code runs to completion without problem but occasionally (once every several hundred captures), I see a kernal panic from which the code never recovers:

[ 2201.806881] ------------[ cut here ]------------
[ 2201.811594] WARNING: CPU: 0 PID: 15311 at /home/pat/PepProjection/openembedded/build/tmp-glibc/work-shared/p2420-prodpcb1/kernel-source/drivers/media/i2c/mt9p031.c:1002 mt9p031_set_power+0x12c/0x17c [mt9p031]()
[ 2201.830329] Modules linked in: wl18xx wlcore imx_ipu_scaler imx_ipuv3_csi imx_ipu mt9p031 wlcore_sdio aptina_pll spidev coda videobuf2_vmalloc v4l2_mem2mem phytec_mediabus imx_media ipv6
[ 2201.847256] CPU: 0 PID: 15311 Comm: gst-launch-1.0 Not tainted 4.1.18-i.MX6-PD15.3.1 #1
[ 2201.855264] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 2201.861795] Backtrace:
[ 2201.864283] [<80013fbc>] (dump_backtrace) from [<800141d8>] (show_stack+0x18/0x1c)
[ 2201.871856]  r6:60000013 r5:00000000 r4:80b250f8 r3:00000000
[ 2201.877597] [<800141c0>] (show_stack) from [<807aa500>] (dump_stack+0xb4/0xe8)
[ 2201.884830] [<807aa44c>] (dump_stack) from [<8002dcc4>] (warn_slowpath_common+0x80/0xbc)
[ 2201.892922]  r10:00000008 r9:ebf9ccb8 r8:7f0c1c40 r7:000003ea r6:7f0c1464 r5:00000009
[ 2201.900832]  r4:00000000 r3:00000000
[ 2201.904445] [<8002dc44>] (warn_slowpath_common) from [<8002dda4>] (warn_slowpath_null+0x24/0x2c)
[ 2201.913232]  r8:eb50cac8 r7:ed7f9410 r6:eda04640 r5:ed7f9518 r4:00000000
[ 2201.920023] [<8002dd80>] (warn_slowpath_null) from [<7f0c1464>] (mt9p031_set_power+0x12c/0x17c [mt9p031])
[ 2201.929602] [<7f0c1338>] (mt9p031_set_power [mt9p031]) from [<7f0c14c8>] (mt9p031_close+0x14/0x18 [mt9p031])
[ 2201.939431]  r8:eb50cac8 r7:ed554410 r6:eda04640 r5:ed7f9410 r4:ebceb900 r3:7f0c14b4
[ 2201.947272] [<7f0c14b4>] (mt9p031_close [mt9p031]) from [<8054c144>] (subdev_close+0x40/0x8c)
[ 2201.955818] [<8054c104>] (subdev_close) from [<8053d8a0>] (v4l2_release+0x40/0x80)
[ 2201.963390]  r6:ebf9ccb8 r5:ebcfcc00 r4:eda04640 r3:8054c104
[ 2201.969126] [<8053d860>] (v4l2_release) from [<80104a18>] (__fput+0x90/0x1e8)
[ 2201.976264]  r5:00000000 r4:eda04640
[ 2201.979878] [<80104988>] (__fput) from [<80104bd0>] (____fput+0x10/0x14)
[ 2201.986582]  r10:00000000 r9:ebecc000 r8:00000000 r7:e9fc8a00 r6:00000000 r5:80b7bbf0
[ 2201.994491]  r4:e9fc8de0
[ 2201.997050] [<80104bc0>] (____fput) from [<80049c04>] (task_work_run+0xbc/0xf0)
[ 2202.004372] [<80049b48>] (task_work_run) from [<80013998>] (do_work_pending+0x90/0xb8)
[ 2202.012292]  r8:80010784 r7:80010784 r6:ebecdfb0 r5:ebecc000 r4:00000000 r3:eda04640
[ 2202.020122] [<80013908>] (do_work_pending) from [<80010604>] (work_pending+0xc/0x20)
[ 2202.027867]  r7:00000006 r6:016a20d0 r5:016a20d0 r4:016a20d4
[ 2202.033764] ---[ end trace 1dd9ab222c9b6c40 ]---

I found this (BCM2835-V4L2: Return buffers to videobuf2 on shutdown · raspberrypi/linux@f1e870c · GitHub ), which might be related. I'd be willing to test a related fix if someone can point me to the correct file and buffers.

[patsandt]

More info: I found this in v4l2_driver.c. That "sleep (1)" seems bad.

int v4l2_free_bufs(struct v4l2_driver *drv)
{
    unsigned int i;

    if (!drv->n_bufs)
        return 0;

    /* Requests the driver to free all buffers */
    drv->reqbuf.count  = 0;
    drv->reqbuf.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    drv->reqbuf.memory = V4L2_MEMORY_MMAP;

    /* stop capture */
    if (xioctl(drv->fd,VIDIOC_STREAMOFF,&drv->reqbuf.type)<0)
        return errno;

    sleep (1);    // FIXME: Should check if all buffers are stopped

/* V4L2 API says REQBUFS with count=0 should be used to release buffer.
   However, video-buf.c doesn't implement it.
 */
#if 0
    if (xioctl(drv->fd,VIDIOC_REQBUFS,&drv->reqbuf)<0) {
        perror("reqbufs while freeing buffers");
        return errno;
    }
#endif

[gusarambula]

Hello Pat Sandt,

As of today, there is no support for kernel 4.1.18 on the BSPs for NXP boards. I’m not sure if Boundary Devices, manufacturers of the Sabre-Lite, might have support for this kernel, perhaps you can also ask this question on their forums.

The fix you pointed out may be the culprit but there is no patch available for the i.MX BSP so you would need to implement it.

Please let us know of your findings and perhaps another Community user has some information on this.

Regards,

[patsandt]

I'm using a Phytec module and they are using 4.1.18. However, I've been testing a fix and I'm working on a patch right now. Initial testing suggests that adding a call to v4l2_free_bufs to mt9p031_close might help. (I've run 2000 tests without a failure. I'm just building the patch now. Further testing once the patch is in the build.)

[patsandt · Accepted solution]

Answer: Adding a call to v4l2_free_bufs to mt9p031_close (in mt9p031.c) has apparently gotten rid of the kernel panics.

[gusarambula]

Thank you for posting your findings! I'm sure it will help other community users.

Regards,

[patsandt]

I hope so. I found the problem because I'm inclined to stress test. Each

loop of my test captures images from two mt9p031 cameras using a gst-launch

script. Although I still see script hangs, I can time them out, kill the

scripts, and retry. That kind of fault-tolerant approach was NOT working

for the kernel panics.

On Thu, Aug 17, 2017 at 2:40 PM, gusarambula <admin@community.nxp.com>