AnsweredAssumed Answered

Is there a patch for v4l2/mt9p031 kernel panic

Question asked by Pat Sandt on Aug 15, 2017
Latest reply on Aug 17, 2017 by Pat Sandt

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.

Outcomes