Potential crash of mx6s_csi_driver ?

[khang_letruong]

Hi there,

During my porting of a custom camera on iMX8M Mini board, I ran into following crash while testing with v4l2-compliance :

[ 1890.179782] unknown pixelformat:'    '
[ 1890.183592] Unable to handle kernel NULL pointer dereference at virtual address 00000024
[ 1890.191717] Mem abort info:
[ 1890.194514]   Exception class = DABT (current EL), IL = 32 bits
[ 1890.200489]   SET = 0, FnV = 0
[ 1890.203639]   EA = 0, S1PTW = 0
[ 1890.206782] Data abort info:
[ 1890.209695]   ISV = 0, ISS = 0x00000006
[ 1890.213562]   CM = 0, WnR = 0
[ 1890.216554] user pgtable: 4k pages, 48-bit VAs, pgd = ffff8000777bf000
[ 1890.223108] [0000000000000024] *pgd=00000000b3ee5003, *pud=00000000b3e10003, *pmd=0000000000000000
[ 1890.232102] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 1890.237675] Modules linked in: 8021q garp stp mrp cdc_ether usbnet r8152 crc32_ce crct10dif_ce qca9377(O) galcore(O)
[ 1890.248217] CPU: 2 PID: 4117 Comm: v4l2-compliance Tainted: G           O    4.14.98-DEBUG_dnl_ecam_integration+g1cef60b #1
[ 1890.259344] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1890.264394] task: ffff800077cf0000 task.stack: ffff00001a328000
[ 1890.283512] PC is at mx6s_vidioc_enum_framesizes+0x90/0x160
[ 1890.289083] LR is at mx6s_vidioc_enum_framesizes+0x90/0x160
[ 1890.294652] pc : [<ffff0000089e9360>] lr : [<ffff0000089e9360>] pstate: 40000145
[ 1890.302048] sp : ffff00001a32bb90
[ 1890.302050] x29: ffff00001a32bb90 x28: ffff800077754000
[ 1890.310676] x27: 0000000000000000 x26: ffff800076e1e800
[ 1890.315988] x25: 0000000000000001 x24: ffff800076e1f040
[ 1890.321299] x23: 000000000000004a x22: ffff800076e1e018
[ 1890.326610] x21: ffff00000928fe98 x20: ffff000008f7c058
[ 1890.331922] x19: ffff00001a32bd30 x18: 0000000000000010
[ 1890.337233] x17: 0000ffff91c24910 x16: ffff00000822a240
[ 1890.342545] x15: ffffffffffffffff x14: ffff000089744547
[ 1890.347856] x13: ffff000009744555 x12: ffff000009598df8
[ 1890.353167] x11: ffff00000862e478 x10: ffff00001a32b860
[ 1890.358478] x9 : 0000000000000006 x8 : 3a74616d726f666c
[ 1890.363789] x7 : 65786970206e776f x6 : 0000000000000522
[ 1890.369101] x5 : 0000000000000000 x4 : 0000000000000000
[ 1890.374412] x3 : 0000000000000000 x2 : ffff80007df90ef0
[ 1890.379724] x1 : ffff800077cf0000 x0 : 0000000000000000
[ 1890.385037] Process v4l2-compliance (pid: 4117, stack limit = 0xffff00001a328000)
[ 1890.392517] Call trace:
[ 1890.394965] Exception stack(0xffff00001a32ba50 to 0xffff00001a32bb90)
[ 1890.401404] ba40:                                   0000000000000000 ffff800077cf0000
[ 1890.409232] ba60: ffff80007df90ef0 0000000000000000 0000000000000000 0000000000000000
[ 1890.417060] ba80: 0000000000000522 65786970206e776f 3a74616d726f666c 0000000000000006
[ 1890.424889] baa0: ffff00001a32b860 ffff00000862e478 ffff000009598df8 ffff000009744555
[ 1890.432716] bac0: ffff000089744547 ffffffffffffffff ffff00000822a240 0000ffff91c24910
[ 1890.440544] bae0: 0000000000000010 ffff00001a32bd30 ffff000008f7c058 ffff00000928fe98
[ 1890.448371] bb00: ffff800076e1e018 000000000000004a ffff800076e1f040 0000000000000001
[ 1890.456198] bb20: ffff800076e1e800 0000000000000000 ffff800077754000 ffff00001a32bb90
[ 1890.464026] bb40: ffff0000089e9360 ffff00001a32bb90 ffff0000089e9360 0000000040000145
[ 1890.471853] bb60: ffff00000928fe98 ffff800076e1e018 0000ffffffffffff ffff800076e1f040
[ 1890.479680] bb80: ffff00001a32bb90 ffff0000089e9360
[ 1890.484565] [<ffff0000089e9360>] mx6s_vidioc_enum_framesizes+0x90/0x160
[ 1890.491181] [<ffff0000089b174c>] __video_do_ioctl+0x204/0x2f8
[ 1890.496925] [<ffff0000089b126c>] video_usercopy+0x1ec/0x4a8
[ 1890.502495] [<ffff0000089b153c>] video_ioctl2+0x14/0x20
[ 1890.507721] [<ffff0000089ad63c>] v4l2_ioctl+0x7c/0x198
[ 1890.512858] [<ffff000008229a0c>] do_vfs_ioctl+0xa4/0x8d8
[ 1890.518168] [<ffff00000822a2bc>] SyS_ioctl+0x7c/0x98
[ 1890.523130] Exception stack(0xffff00001a32bec0 to 0xffff00001a32c000)
[ 1890.529569] bec0: 0000000000000003 00000000c02c564a 0000fffff3fb9100 0000000000000001
[ 1890.537396] bee0: 0000fffff3fb9060 00000000ffffffff 00000000340733c0 0000000000000001
[ 1890.545223] bf00: 000000000000001d 0000ffff91ed1060 0000000000000000 0000000000000000
[ 1890.553050] bf20: 0000000000000001 000000000000270f 0000000000000002 0000000000000000
[ 1890.560878] bf40: 00000000004530c0 0000ffff91c24910 0000ffff91caca70 000000000000000d
[ 1890.568705] bf60: 0000000000000000 0000fffff3fb9c10 0000fffff3fb98e0 0000000000000000
[ 1890.576532] bf80: 0000000000431b78 000000000043b470 00000000c02c564a 0000000000000000
[ 1890.584360] bfa0: 0000fffff3fb9fe8 0000fffff3fb9020 0000000000407f34 0000fffff3fb9020
[ 1890.592187] bfc0: 0000ffff91c2491c 0000000040000000 0000000000000003 000000000000001d
[ 1890.600014] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1890.607843] [<ffff000008083b18>] __sys_trace_return+0x0/0x4
[ 1890.613415] Code: f94002c1 97f3ac6b b9400660 97ffff5f (b9402404)
[ 1890.619507] ---[ end trace e5d7955dfc481c2f ]---

Checking in the source code , I find that following function may return NULL :

struct mx6s_fmt *format_by_fourcc(int fourcc)
{
        int i;

        for (i = 0; i < NUM_FORMATS; i++) {
                if (formats[i].pixelformat == fourcc)
                        return formats + i;
        }

        pr_err("unknown pixelformat:'%4.4s'\n", (char *)&fourcc);
        return NULL;
}

However, there is no check of the return value in the following calling functions :

static int mx6s_vidioc_enum_framesizes(struct file *file, void *priv,
                                         struct v4l2_frmsizeenum *fsize)
{

       ...

        struct mx6s_fmt *fmt;

       ...

        fmt = format_by_fourcc(fsize->pixel_format);
        if (fmt->pixelformat != fsize->pixel_format)
                return -EINVAL;

       ...

}

and

static int mx6s_vidioc_enum_frameintervals(struct file *file, void *priv,
                struct v4l2_frmivalenum *interval)
{

       ...

        struct mx6s_fmt *fmt;

       ...

        fmt = format_by_fourcc(interval->pixel_format);
        if (fmt->pixelformat != interval->pixel_format)
                return -EINVAL;

       ...

}

I'm using fsl-image-validation-imx with rel_imx_4.14.98_2.0.0_ga.

By prudence, I'd like to know if it's a potential bug or format_by_fourcc() function will never return NULL according to its input ?

Best regards,

Khang

[bbilas]

Hello everyone,
I've encountered the same issue but using imx6ul platform. I've checked the connections using oscilloscope and everything looks good, DRAM is also checked using ddr stress test tool. I'm using the latest (I guess) rel_imx_5.4.24_2.1.0 linux release.

Best

Bartek

[igorpadykov]

Hi Khang

log "Unable to handle kernel NULL pointer" may point to memory

errors so one can run ddr test https://community.nxp.com/docs/DOC-340179 

and rebuild image using documentation included in ddr test package.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------