kukui kodama (lenovo 10e) crtc crashes

[rakslice]

With the kukui 230917-01 image on kodama (lenovo 10e) I get a lot of spontaneous exits from Xorg with one of these in the dmesg; is this some known issue?

 2283.192940] ------------[ cut here ]------------
[ 2283.192962] mediatek-drm mediatek-drm.1.auto: vblank wait timed out on crtc 0
[ 2283.193002] WARNING: CPU: 4 PID: 4607 at drivers/gpu/drm/drm_vblank.c:1269 drm_wait_one_vblank+0x1e4/0x204
[ 2283.193030] Modules linked in: rfcomm hidp qrtr bnep binfmt_misc mtk_vcodec_dec v4l2_vp9 mtk_vcodec_enc v4l2_h264 mtk_vcodec_common mtk_jpeg mtk_vpu hid_multitouch ath10k_sdio videobuf2_dma_contig ath10k_core v4l2_mem2mem videobuf2_memops ath cros_ec_sensors videobuf2_v4l2 hci_uart videobuf2_common mac80211 btqca cros_ec_sensors_core btbcm videodev libarc4 industrialio_triggered_buffer coresight_cpu_debug coresight sbs_battery mc kfifo_buf cros_usbpd_charger cfg80211 cros_ec_chardev cros_usbpd_logger i2c_hid_of bluetooth i2c_hid ecdh_generic cros_ec_typec ecc typec at24 rfkill mtk_scp mtk_rpmsg mtk_scp_ipi mt8183_mt6358_ts3a227_max98357 mt6577_auxadc snd_soc_ts3a227e snd_soc_mt6358 rtc_mt6397 mtk_wdt snd_soc_mt8183_afe snd_soc_mtk_common snd_soc_bt_sco snd_soc_max98357a coreboot_table fuse ip_tables x_tables ipv6
[ 2283.193236] CPU: 4 PID: 4607 Comm: Xorg Tainted: G        W          6.1.51-stb-mt8+ #1
[ 2283.193248] Hardware name: MediaTek kodama sku288 board (DT)
[ 2283.193255] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2283.193265] pc : drm_wait_one_vblank+0x1e4/0x204
[ 2283.193277] lr : drm_wait_one_vblank+0x1e4/0x204
[ 2283.193288] sp : ffff80000a7838f0
[ 2283.193293] x29: ffff80000a7838f0 x28: ffff80000a783d48 x27: ffff0db103bd9000
[ 2283.193309] x26: ffffd93f92fdac18 x25: ffffd93f93306898 x24: ffff0db103bdb880
[ 2283.193323] x23: ffff0db103bdb888 x22: 0000000000003dc3 x21: 0000000000000000
[ 2283.193336] x20: 0000000000000000 x19: ffff0db103bd8800 x18: 0000000000000006
[ 2283.193349] x17: 2063747263206e6f x16: 2074756f2064656d x15: 6974207469617720
[ 2283.193362] x14: 6b6e616c6276203a x13: ffffd93f937753b8 x12: 0000000000000c24
[ 2283.193375] x11: 000000000000040c x10: ffffd93f937cd3b8 x9 : ffffd93f937753b8
[ 2283.193389] x8 : 00000000ffffefff x7 : ffffd93f937cd3b8 x6 : 80000000fffff000
[ 2283.193402] x5 : ffff0db13f755a08 x4 : 0000000000000000 x3 : 0000000000000027
[ 2283.193414] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0db101e69d80
[ 2283.193428] Call trace:
[ 2283.193433]  drm_wait_one_vblank+0x1e4/0x204
[ 2283.193445]  drm_crtc_wait_one_vblank+0x1c/0x2c
[ 2283.193455]  mtk_drm_crtc_atomic_disable+0xc4/0x3a0
[ 2283.193469]  disable_outputs+0x220/0x340
[ 2283.193481]  drm_atomic_helper_commit_tail_rpm+0x24/0xa0
[ 2283.193494]  commit_tail+0xa4/0x190
[ 2283.193506]  drm_atomic_helper_commit+0x164/0x180
[ 2283.193513]  drm_atomic_commit+0xa8/0xe0
[ 2283.193524]  drm_atomic_connector_commit_dpms+0xe0/0x110
[ 2283.193532]  drm_mode_obj_set_property_ioctl+0x1b8/0x410
[ 2283.193542]  drm_connector_property_set_ioctl+0x40/0x70
[ 2283.193550]  drm_ioctl_kernel+0xc8/0x174
[ 2283.193561]  drm_ioctl+0x20c/0x420
[ 2283.193569]  __arm64_sys_ioctl+0xac/0xf0
[ 2283.193580]  invoke_syscall+0x48/0x114
[ 2283.193593]  el0_svc_common.constprop.0+0x44/0xec
[ 2283.193603]  do_el0_svc+0x2c/0xd0
[ 2283.193613]  el0_svc+0x2c/0x84
[ 2283.193626]  el0t_64_sync_handler+0xf4/0x120
[ 2283.193637]  el0t_64_sync+0x18c/0x190
[ 2283.193646] ---[ end trace 0000000000000000 ]---

[thenameisluk]

@rakslice not really
i've used 10e for some time and never encountered that issue
you can try installing some wayland compositor and seeing if it gets any better

sudo apt install gnome-core

or other desktop environment you like

i've used gnome on this device for some time and haven't had this issue

[hexdump0815]

i'm getting this error message also in the logs on my kukui krane, but xorg is still running stable - maybe the problem with your kukui kodama is somewhere else and not related to this message ... maybe general stability issues, maybe usb-disk related? what luk suggested would be a good test to maybe find out more where the problem is

[rakslice]

Sorry, my question is confusing: The actual symptom is that the X session on screen goes away and the system goes to a black screen and does not respond to anything -- I can't switch vt on the active bluetooth keyboard, normal pressing the power button does nothing, etc. and the system stops responding over wifi -- I can only shut it off by holding down the power button for 10 seconds and then power it on again. I should call it a hang. I set the system to multi-user.target default now while I troubleshoot. The hang has never happened while there are only text console vt's. I isolate graphical target to start a graphics session and sometimes it works and I can log in and use it and the hang happens sometime later, and sometimes it hangs right away after I isolate the graphical target and we go right from the text console to the black screen before X has a chance to display anything else.

This vblank wait timed out on crtc trace is the last thing I get in my remote dmesg tail before the system becomes unresponsive, but very well could be a coincidence or an unrelated knock on effect of whatever is causing the hang. It was my presumption that X is relevant because the hang never happens without it. I'll try to remember when I reproduce the problem again to look at the relevant X log for that run to see if anything else made it to disk that would clarify

I'm running from the onboard storage without any usb connected but a power adapter, so it isn't usb disk related iiuc.

I'll need to figure out some remote kernel debugging solution I guess; normal network remote kernel debugging or whatever the CCD features provide

[thenameisluk]

@rakslice you can use suzyq cable for serial console if you manage to obtain one #243 (comment)

like i said i've never encounted this issue on my lenovo 10e but device hanging sounds like a kernel panic
you can try diffrent kernel version, we are currently testing 6.11, so u can check if the issue arises there too or on any other mt8+ kernel
other than that i would still recommend seeing if it also happends on wayland