i.MX Processors中的主题 Re: i.MX 8M Mini DRM crash

i.MX 8M Mini DRM crash

philippe_schenk — Thu, 22 Sep 2022 10:13:02 GMT

Hello,

I was trying out the DSI to HDMI bridge on the i.MX 8M Mini EVK. I was plugging in and out two monitors when DRM suddenly crashed. I wanted to report this in the hope you can fix this in an upcoming release.

[ 100.445376] [CRTC:33:crtc-0] vblank wait timed out [ 100.450240] WARNING: CPU: 2 PID: 32 at drivers/gpu/drm/drm_atomic_helper.c:1514 drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 100.462255] Modules linked in: overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes imx8m_ddrc crct10dif_ce snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_micfil governor_userspace snd_soc_imx_spdif gpio_ir_recv rc_core imx_bus snd_soc_imx_card fuse [ 100.493347] CPU: 2 PID: 32 Comm: kworker/2:1 Not tainted 5.15.32-lts-next+gfa6c3168595c #1 [ 100.501615] Hardware name: FSL i.MX8MM EVK board (DT) [ 100.506669] Workqueue: events adv7511_hpd_work [ 100.511123] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 100.518088] pc : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 100.524619] lr : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 100.531154] sp : ffff80000a04ba00 [ 100.534469] x29: ffff80000a04ba00 x28: 0000000000000e21 x27: 0000000000000000 [ 100.541613] x26: 0000000000000001 x25: 0000000000000038 x24: ffff0000056e1800 [ 100.548758] x23: 0000000000000001 x22: 0000000000000000 x21: ffff000008e9af80 [ 100.555899] x20: ffff0000048c1088 x19: 0000000000000000 x18: ffffffffffffffff [ 100.563043] x17: 000000040044ffff x16: 00400032b5503510 x15: ffff80008a04b717 [ 100.570188] x14: 0000000000000000 x13: ffff800009c21f40 x12: 000000000000057f [ 100.577332] x11: 00000000000001d5 x10: ffff800009c21f40 x9 : ffff800009c21f40 [ 100.584478] x8 : 00000000ffffefff x7 : ffff800009c79f40 x6 : ffff800009c79f40 [ 100.591622] x5 : 0000000000000000 x4 : ffff000055b969d0 x3 : ffff000055b99950 [ 100.598768] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000041da940 [ 100.605914] Call trace: [ 100.608361] drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 100.614549] drm_atomic_helper_wait_for_vblanks+0x1c/0x30 [ 100.619953] lcdif_drm_atomic_commit_tail+0x58/0x80 [ 100.624837] commit_tail+0xa4/0x184 [ 100.628330] drm_atomic_helper_commit+0x160/0x370 [ 100.633041] drm_atomic_commit+0x50/0x60 [ 100.636970] drm_client_modeset_commit_atomic+0x1c8/0x260 [ 100.642375] drm_client_modeset_commit_locked+0x60/0x19c [ 100.647689] drm_client_modeset_commit+0x34/0x60 [ 100.652312] drm_fb_helper_set_par+0xcc/0x124 [ 100.656671] drm_fb_helper_hotplug_event.part.0+0xb0/0xe0 [ 100.662076] drm_fbdev_client_hotplug+0x180/0x230 [ 100.666786] drm_client_dev_hotplug+0x88/0xe0 [ 100.671149] drm_kms_helper_hotplug_event+0x38/0x50 [ 100.676036] adv7511_hpd_work+0x94/0x184 [ 100.679962] process_one_work+0x1d0/0x354 [ 100.683980] worker_thread+0x13c/0x470 [ 100.687731] kthread+0x154/0x160 [ 100.690965] ret_from_fork+0x10/0x20 [ 100.694545] ---[ end trace 74c1803f4c5a8138 ]--- [ 120.548728] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [ 120.554956] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:33:crtc-0] commit wait timed out [ 130.788742] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [ 130.794970] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:35:HDMI-A-1] commit wait timed out

Best Regards,
Philippe

Re: i.MX 8M Mini DRM crash

AldoG — Wed, 28 Sep 2022 23:54:52 GMT

Hello,

I do not know which Linux version are you running but we already have a workaround for this scenario, please refer to the following commit:

https://source.codeaurora.org/external/imx/linux-imx/commit/?h=lf-5.15.y&id=97b4737f3370e683f585ca6533b01358c21430db

Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

philippe_schenk — Thu, 29 Sep 2022 08:50:03 GMT

Thanks for your reply. The patch you linked is already in the kernel we are using. We are specifically using `Linux 5.15.32_2.0.0`

Re: i.MX 8M Mini DRM crash

AldoG — Thu, 06 Oct 2022 00:25:20 GMT

Hello,

Thank you for confirmation, we have a more recent Linux version but I do not see anything different at source code I will discuss this internally.

Thank you for your report,
Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

philippe_schenk — Mon, 10 Oct 2022 07:35:33 GMT

Thank you for taking this up!

I'm looking forward to the outcome.

Best Regards,
Philippe

Re: i.MX 8M Mini DRM crash

AldoG — Fri, 14 Oct 2022 20:58:14 GMT

Hi,

I have tried on my side multiple times to replicate the crash but I couldn’t, I'm using the following setup:

i.MX8MMini LPDDR4 (CPU2) EVK.
MIPI-DSI to HDMI bridge
HDMI Bi-Direction Switch
2 different HDMI Monitors
Linux version 5.15.32

I have used the switch to keep changing between the 2 HDMI monitors but no crash seen on DRM.
Next, I tried only using one or the other by plugging in and out HDMI, but same result no crash seen on DRM.

Could you share detailed steps to replicate?
Also, how easy is to reproduce this?
Does it happen randomly?

Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

philippe_schenk — Mon, 17 Oct 2022 15:26:17 GMT

Hi Aldo,

Thank you very much for answering and trying to reproduce the issue. I also tried again and compiled a detailed step-by-step guide how to reproduce this issue. I am aware that this seems a very "niche" bug however it indicates that DRM handles EDID wrongly - hence it probably only occurs when using different resolution monitors.

# Boot NXP i.MX Release Distro 5.15-kirkstone # On i.MX8M Mini EVK # With attached DSI-to-HDMI adapter # In U-Boot setenv fdtfile imx8mm-evk.dtb saveenv boot # In Linux systemctl stop weston ## Plug in first monitor ## Then force the default-mode of the monitor modetest -s 35:#0 ## Press <enter> to terminate modetest ## Plug in second monitor ## - I cannot reproduce it with two Full-HD monitors ## - I use a 1280x1024 and 1920x1080 monitor

Best Regards,
Philippe

Re: i.MX 8M Mini DRM crash

AldoG — Tue, 01 Nov 2022 23:47:30 GMT

Hi,

I'm still working with internal team regarding this issue, team is testing with different resolutions, but would it be possible to test with lower resolution (720p) on your side?

Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

philippe_schenk — Wed, 02 Nov 2022 12:00:03 GMT

Hi Aldo,

Thanks for coming back to me. If you still couldn't reproduce on your side I suggest we don't waste our times on this issue. It is not that important after all and very specific use-case that is not often used most probably.

Thanks and Best Regards,
Philippe

Re: i.MX 8M Mini DRM crash

AldoG — Thu, 03 Nov 2022 00:07:20 GMT

Hello,

Thank you for your consideration, I'll continue investigating the issue with low priority and let you know of the results here later.

Thank you for your report,
Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

stefan_eichenberger — Mon, 28 Nov 2022 13:43:40 GMT

Hi,

I think I found another way to reproduce this issue. I do the following steps:

Boot with 1920x1080 display connected
Disconnect 1920x1080 display
Wait 10s (because of polling mode)
Connect 1280x720 display
reboot

Then this message appears:

[ 53.647167] ------------[ cut here ]------------ [ 53.651901] [CRTC:33:crtc-0] vblank wait timed out [ 53.656829] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1524 drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 53.668974] Modules linked in: rfcomm algif_hash algif_skcipher af_alg fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc mcp251xfd crypto_engine rng_core authenc libdes can_dev crct10dif_ce mwifiex_sdio mwifiex imx8m_ddrc btmrvl_sdio btmrvl sec_mipi_dsim_imx bluetooth sec_dsim governor_userspace imx_be [ 53.709642] CPU: 0 PID: 1 Comm: systemd Tainted: G O 5.15.77-6.1.0-devel+git.8053ffcbece2 #1 [ 53.719555] Hardware name: Toradex Verdin iMX8M Mini WB on Verdin Development Board (DT) [ 53.727786] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 53.734871] pc : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 53.741518] lr : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 53.748162] sp : ffff800009c4b930 [ 53.751535] x29: ffff800009c4b930 x28: 00000000000006f6 x27: 0000000000000000 [ 53.758803] x26: 0000000000000001 x25: 0000000000000038 x24: ffff00000117e800 [ 53.766071] x23: 0000000000000001 x22: 0000000000000000 x21: ffff00000c1f5280 [ 53.773336] x20: ffff000000480088 x19: 0000000000000000 x18: ffffffffffffffff [ 53.780604] x17: 000000040044ffff x16: 0000000000000001 x15: ffff800089c4b647 [ 53.787871] x14: 0000000000000000 x13: ffff800009a12500 x12: 0000000000000528 [ 53.795137] x11: 00000000000001b8 x10: ffff800009a12500 x9 : ffff800009a12500 [ 53.802403] x8 : 00000000ffffefff x7 : ffff800009a6a500 x6 : ffff800009a6a500 [ 53.809670] x5 : 0000000000000000 x4 : ffff00003fd809d0 x3 : ffff00003fd83990 [ 53.816937] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000000a8000 [ 53.824203] Call trace: [ 53.826694] drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 53.832986] drm_atomic_helper_wait_for_vblanks+0x18/0x30 [ 53.838482] lcdif_drm_atomic_commit_tail+0x54/0x70 [ 53.843454] commit_tail+0xa0/0x180 [ 53.847008] drm_atomic_helper_commit+0x160/0x370 [ 53.851798] drm_atomic_commit+0x4c/0x60 [ 53.855795] drm_client_modeset_commit_atomic+0x1c8/0x260 [ 53.861291] drm_client_modeset_commit_locked+0x5c/0x1a0 [ 53.866698] drm_client_modeset_commit+0x30/0x60 [ 53.871399] drm_fb_helper_set_par+0xc8/0x120 [ 53.875835] drm_fb_helper_hotplug_event.part.0+0xb0/0xe0 [ 53.881333] drm_fbdev_client_restore+0x98/0xd0 [ 53.888947] drm_client_dev_restore+0x84/0xdc [ 53.896367] drm_lastclose+0x6c/0x7c [ 53.902874] drm_release+0xfc/0x114 [ 53.909153] __fput+0x70/0x240 [ 53.914857] ____fput+0x10/0x20 [ 53.920502] task_work_run+0x80/0x180 [ 53.926544] do_notify_resume+0x200/0x12ec [ 53.932898] el0_svc+0x6c/0x80 [ 53.938089] el0t_64_sync_handler+0xa4/0x130 [ 53.944425] el0t_64_sync+0x1a0/0x1a4 [ 53.950067] ---[ end trace 5ea06ebb2e853670 ]---

It is not exactly the same but it is also related to drm_fb_helper_hotplug_event.part. I think it is because the drm drivers are unloaded/not fully working anymore when fbdev wants to process the hotplug event.

Re: i.MX 8M Mini DRM crash

AldoG — Tue, 06 Dec 2022 20:45:06 GMT

Hello,

Thank you for sharing more details, I have forwarded to internal team so they can continue investigating this issue.

Best regards,
Aldo.

Re: i.MX 8M Mini DRM crash

AldoG — Fri, 20 Jan 2023 22:57:33 GMT

Hi @philippe_schenk,

We are still looking into this, could you share the details of the monitor/display that you're using for myour test, like brand and model?

Thank you,
Best regards,
Aldo.