From: "Ing. Josua Mayer" <josua.mayer@jm0.eu>
To: matrandg@cisco.com, mchehab@kernel.org
Cc: linux-media@vger.kernel.org
Subject: [BUG] tc358743: division by zero
Date: Wed, 9 Jun 2021 17:07:22 +0200 [thread overview]
Message-ID: <427466e4-1b6f-f7c3-3d5e-89c7a7f2ec79@jm0.eu> (raw)
Dear Maintainers,
During my attempts at capturing HDMI via the csi-2 port on i.MX6
HummingBoard, I triggered a division by zero in
tc358743_num_csi_lanes_needed!
I am running Debian testing, with linux 5.10.40 - built from debian
sources with the tc358743 driver enabled:
Linux sr-imx6 5.10.0-7-armmp #1 SMP Debian 5.10.40-2 (2021-05-29) armv7l
GNU/Linux
The crash is triggered from userspace as I execute:
media-ctl -l "'tc358743 0-000f':0->'imx6-mipi-csi2':0[1]"
media-ctl -l "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
media-ctl -l "'ipu1_csi0_mux':2->'ipu1_csi0':0[1]"
media-ctl -l "'ipu1_csi0':2->'ipu1_csi0 capture':0[1]"
v4l2-ctl -d /dev/v4l-subdev7 --set-edid=file=tc358743-edid.hex && sleep 1
v4l2-ctl -d /dev/v4l-subdev7 --set-dv-bt-timings query && sleep 1
[ 60.985439] Division by zero in kernel.
[ 60.989333] CPU: 1 PID: 395 Comm: v4l2-ctl Tainted: G WC E
5.10.0-7-armmp #1 Debian 5.10.40-2
[ 60.998904] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 61.005438] Backtrace:
[ 61.007911] [<c0cf1fe8>] (dump_backtrace) from [<c0cf2394>]
(show_stack+0x20/0x24)
[ 61.015489] r7:00000018 r6:600b0013 r5:00000000 r4:c14cdc90
[ 61.021162] [<c0cf2374>] (show_stack) from [<c0cf74c4>]
(dump_stack+0xc8/0xdc)
[ 61.028394] [<c0cf73fc>] (dump_stack) from [<c0cf216c>]
(__div0+0x24/0x28)
[ 61.035276] r7:00000018 r6:034bc000 r5:c1f67890 r4:4f1a0000
[ 61.040951] [<c0cf2148>] (__div0) from [<c07b1254>] (Ldiv0+0x8/0x10)
[ 61.047336] [<bf412000>] (tc358743_num_csi_lanes_needed [tc358743])
from [<bf412a44>] (tc358743_set_csi+0x1c/0x3f0 [tc358743])
[ 61.058734] r9:00000000 r8:c2b8b400 r7:c1f67a59 r6:bf419380
r5:c1f679e8 r4:c1f67890
[ 61.066495] [<bf412a28>] (tc358743_set_csi [tc358743]) from
[<bf413f64>] (tc358743_s_dv_timings+0x104/0x1a8 [tc358743])
[ 61.077283] r7:c1f67a59 r6:bf419380 r5:c1f679e8 r4:c1f67890
[ 61.082961] [<bf413e60>] (tc358743_s_dv_timings [tc358743]) from
[<c0a79fd4>] (subdev_do_ioctl+0x430/0xd0c)
[ 61.092708] r7:c1f67890 r6:c2ea0780 r5:c2d91c00 r4:c0845657
[ 61.098376] [<c0a79ba4>] (subdev_do_ioctl) from [<c0a7a934>]
(subdev_do_ioctl_lock+0x84/0xb4)
[ 61.106909] r10:c2d91c00 r9:bea08dec r8:c0845657 r7:00000000
r6:c2d91c00 r5:c2ea0780
[ 61.114741] r4:c2e35000
[ 61.117294] [<c0a7a8b0>] (subdev_do_ioctl_lock) from [<c0a6c4b4>]
(video_usercopy+0x190/0x674)
[ 61.125913] r9:bea08dec r8:c2d91c00 r7:bea08dec r6:c0845657
r5:00000000 r4:c0845657
[ 61.133668] [<c0a6c324>] (video_usercopy) from [<c0a79254>]
(subdev_ioctl+0x20/0x24)
[ 61.141419] r10:c30372a8 r9:00000003 r8:c2ea0780 r7:bea08dec
r6:c2ea0780 r5:00000000
[ 61.149251] r4:c0a79234
[ 61.151797] [<c0a79234>] (subdev_ioctl) from [<c0a64920>]
(v4l2_ioctl+0x4c/0x60)
[ 61.159207] [<c0a648d4>] (v4l2_ioctl) from [<c05a90ac>]
(sys_ioctl+0x130/0xa74)
[ 61.166520] r5:00000000 r4:c0845657
[ 61.170107] [<c05a8f7c>] (sys_ioctl) from [<c03000c0>]
(ret_fast_syscall+0x0/0x54)
[ 61.177681] Exception stack(0xc48adfa8 to 0xc48adff0)
[ 61.182742] dfa0: 005023a4 004dad3c 00000003
c0845657 bea08dec 00000000
[ 61.190927] dfc0: 005023a4 004dad3c 00000003 00000036 0050c808
bea09494 bea08fa0 00000000
[ 61.199109] dfe0: 00500df8 bea08d2c 004a635d b6cde418
[ 61.204169] r10:00000036 r9:c48ac000 r8:c03002c4 r7:00000036
r6:00000003 r5:004dad3c
[ 61.212000] r4:005023a4
I am attaching the device-tree changes as a file for reference. Any
ideas what is happening here?
I can see 2 divisions:
1. pdata->refclk_hz / pdata->pll_prd
2. DIV_ROUND_UP(bps, bps_pr_lane)
1. should never be 0, since it is initialized during probe and then
never changed
2. see how the divisor can be 0
pdata->refclk_hz / pdata->pll_prd is the inversion of how pll_prd is
calculated, and should equal to 6MHz from probe.
pll_fbd is also set in probe: pll_fbd = bps_pr_lane / refclk_hz * pll_prd
As I have specified a link-frequency of 594MHz, that produces:
bps_pr_lane = 2 * 594MHz
pll_fbd = 2 * 594MHz / 27MHz * (27MHz / 6MHz) = 2 * 594MHz / 6MHz = 198
Apparently from initialization, the division by zero can not occur :(
(unless I made a mistake here).
Thank you for reading this far!
Yours sincerely
Josua Mayer
next reply other threads:[~2021-06-09 15:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 15:07 Ing. Josua Mayer [this message]
2021-06-09 15:08 ` [BUG] tc358743: division by zero Ing. Josua Mayer
2021-06-09 17:08 ` Ing. Josua Mayer
2021-06-09 17:27 ` Dave Stevenson
2021-06-21 14:58 ` Ing. Josua Mayer
2021-06-22 20:33 ` [PATCH] media: tc358743: fix missing return of error code in tc358743_probe_of Josua Mayer
2021-06-23 10:05 ` Dave Stevenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=427466e4-1b6f-f7c3-3d5e-89c7a7f2ec79@jm0.eu \
--to=josua.mayer@jm0.eu \
--cc=linux-media@vger.kernel.org \
--cc=matrandg@cisco.com \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.