linux
linux copied to clipboard
raspberrypi
RPi3 B 1.2: 'flip_done timed out' when turning monitor off and on again
I got this error with my RPi3 using 'dtoverlay=vc4-kms-v3d' (on bullseye) I'm using 'hdmi_mode=4' in config.txt It boots up fine (HDMI monitor is on) but when i turn the monitor off and on again i don't get a picture anymore, until i do a hard reset (pull power off)
Mar 26 20:08:28 pi3 kernel: [ 2500.612845] ------------[ cut here ]------------
Mar 26 20:08:28 pi3 kernel: [ 2500.612857] Timeout waiting for VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE
Mar 26 20:08:28 pi3 kernel: [ 2500.612978] WARNING: CPU: 2 PID: 6289 at drivers/gpu/drm/vc4/vc4_hdmi.c:1336 vc4_hdmi_encoder_post_crtc_enable+0x1064/0x11a8 [vc
4]
Mar 26 20:08:28 pi3 kernel: [ 2500.612983] Modules linked in: ccm rfcomm algif_hash algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q
garp stp llc snd_soc_hdmi_codec rt2800usb rt2800lib rt2x00usb rt2x00lib joydev brcmfmac mac80211 brcmutil crc_ccitt vc4 libarc4 cec cfg80211 drm_kms_helper rfk
ill snd_soc_core snd_compress snd_pcm_dmaengine syscopyarea sysfillrect sysimgblt fb_sys_fops raspberrypi_hwmon i2c_bcm2835 bcm2835_codec(C) bcm2835_v4l2(C) bc
m2835_isp(C) bcm2835_mmal_vchiq(C) v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 snd_bcm2835(C) videobuf2_common snd_pcm
snd_timer snd vc_sm_cma(C) videodev mc uio_pdrv_genirq uio i2c_dev aes_neon_bs aes_neon_blk crypto_simd cryptd drm drm_panel_orientation_quirks backlight fuse
ip_tables x_tables ipv6
Mar 26 20:08:28 pi3 kernel: [ 2500.613222] CPU: 2 PID: 6289 Comm: kworker/2:2 Tainted: G C 5.10.92-v8+ raspberrypi/firmware#1514
Mar 26 20:08:28 pi3 kernel: [ 2500.613226] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
Mar 26 20:08:28 pi3 kernel: [ 2500.613294] Workqueue: events output_poll_execute [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.613304] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
Mar 26 20:08:28 pi3 kernel: [ 2500.613331] pc : vc4_hdmi_encoder_post_crtc_enable+0x1064/0x11a8 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613357] lr : vc4_hdmi_encoder_post_crtc_enable+0x1064/0x11a8 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613361] sp : ffffffc0132538a0
Mar 26 20:08:28 pi3 kernel: [ 2500.613365] x29: ffffffc0132538a0 x28: 0000000000000001
Mar 26 20:08:28 pi3 kernel: [ 2500.613375] x27: ffffffc0090e43e8 x26: 0000000000000500
Mar 26 20:08:28 pi3 kernel: [ 2500.613385] x25: ffffff80076d3c50 x24: ffffff80076d3c30
Mar 26 20:08:28 pi3 kernel: [ 2500.613395] x23: ffffffc010e1d178 x22: ffffff80076d3c28
Mar 26 20:08:28 pi3 kernel: [ 2500.613405] x21: 0000024637dffa7e x20: ffffff80076d34b8
Mar 26 20:08:28 pi3 kernel: [ 2500.613415] x19: ffffff80076d3080 x18: 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613425] x17: 0000000000000000 x16: 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613434] x15: 0000007f8adf46a8 x14: 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613444] x13: 0000000000000000 x12: ffffffc0113154f8
Mar 26 20:08:28 pi3 kernel: [ 2500.613453] x11: 0000000000000003 x10: ffffffc0112fd4b8
Mar 26 20:08:28 pi3 kernel: [ 2500.613463] x9 : ffffffc0100e6558 x8 : 0000000000017fe8
Mar 26 20:08:28 pi3 kernel: [ 2500.613473] x7 : c0000000ffffefff x6 : ffffffc013253500
Mar 26 20:08:28 pi3 kernel: [ 2500.613483] x5 : 0000000000000001 x4 : 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613492] x3 : 0000000000000001 x2 : 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613502] x1 : bcd5c0829e029300 x0 : 0000000000000000
Mar 26 20:08:28 pi3 kernel: [ 2500.613511] Call trace:
Mar 26 20:08:28 pi3 kernel: [ 2500.613539] vc4_hdmi_encoder_post_crtc_enable+0x1064/0x11a8 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613565] vc4_crtc_atomic_enable+0x3d0/0x4a8 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613609] drm_atomic_helper_commit_modeset_enables+0x210/0x258 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.613635] vc4_atomic_complete_commit+0x1dc/0x6a8 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613660] vc4_atomic_commit+0x1b0/0x200 [vc4]
Mar 26 20:08:28 pi3 kernel: [ 2500.613785] drm_atomic_commit+0x54/0x68 [drm]
Mar 26 20:08:28 pi3 kernel: [ 2500.613877] drm_client_modeset_commit_atomic.isra.16+0x1ec/0x290 [drm]
Mar 26 20:08:28 pi3 kernel: [ 2500.613963] drm_client_modeset_commit_locked+0x68/0x1a8 [drm]
Mar 26 20:08:28 pi3 kernel: [ 2500.614050] drm_client_modeset_commit+0x38/0x60 [drm]
Mar 26 20:08:28 pi3 kernel: [ 2500.614094] __drm_fb_helper_restore_fbdev_mode_unlocked+0xd4/0x118 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614139] drm_fb_helper_set_par+0x44/0x80 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614184] drm_fb_helper_hotplug_event.part.24+0xb4/0xe8 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614228] drm_fbdev_client_hotplug+0x44/0x1b8 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614314] drm_client_dev_hotplug+0x80/0xc8 [drm]
Mar 26 20:08:28 pi3 kernel: [ 2500.614357] drm_kms_helper_hotplug_event+0x3c/0x50 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614401] output_poll_execute+0x1e0/0x230 [drm_kms_helper]
Mar 26 20:08:28 pi3 kernel: [ 2500.614413] process_one_work+0x1f4/0x4d8
Mar 26 20:08:28 pi3 kernel: [ 2500.614419] worker_thread+0x50/0x480
Mar 26 20:08:28 pi3 kernel: [ 2500.614427] kthread+0x148/0x158
Mar 26 20:08:28 pi3 kernel: [ 2500.614435] ret_from_fork+0x10/0x30
Mar 26 20:08:28 pi3 kernel: [ 2500.614440] ---[ end trace cca87e7ca102e151 ]---
Mar 26 20:08:28 pi3 kernel: [ 2500.614515] ------------[ cut here ]------------
[...]
Mar 26 20:08:39 pi3 kernel: [ 2510.824308] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
$ lsb_release -d
Description: Debian GNU/Linux 11 (bullseye)
$ uname -a
Linux pi3 5.10.92-v8+ raspberrypi/firmware#1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux
So i'm currently using 'dtoverlay=vc4-fkms-v3d' where this doesn't happen.
Can you try running rpi-update to switch to the 5.15 kernel branch? Is the issue still there?
This is intended to become the stable kernel in apt in the very near future.
It doesn't sound good if @simnalamburt can reproduce the issue with 5.15.30.
I didn't see this on my monitor when switching into/out of standby. I didn't see when switching AV indput on monitor. I didn't see when unplugging/replugging hdmi cable. I did see it when unplugging monitor from mains / plugging back in (specifically on plugging back in).
(note: what happens to hotplug signal and ability to read edid in each of these cases tends to be monitor specific).
I have a look, but not seen anything obvious. Increasing the timeout to 10s doesn't help.
HDMI_SCHEDULER_CONTROL=0xcb029 so we've requested hdmi mode but it's not reported as being active.
aside: we are setting VC4_HDMI_SCHEDULER_CONTROL_VERT_ALWAYS_KEEPOUT when I don't think we should - that is only needed with HDCP which we will never support. But I don't believe that is related.
I have seen the failure when replugging hdmi cable, but it's not happening every time. I haven't seen it on my monitor when switching to standby (as monitor doesn't deassert hotplug).
@mripard @timg236 any thoughts? I'm guessing we are in the wrong state to do this (e.g. missing clock, or shutdown or reset of something), but I don't know much about the hdmi block.
10 hdmi unplug/replug cycles on Pi4 hasn't triggered it.
@z0rti adding video=HDMI-A-1:D to end of /boot/cmdline.txt might provide a workaround for this issue (while we continue to look into it).
@mripard before the failure (from /sys/kernel/debug/clk/clk_summary):
fw-clk-pixel 1 1 0 148500000 0 0 50000 Y
$ vcgencmd measure_clock pixel
frequency(29)=148500000
and after:
fw-clk-pixel 0 0 0 148500000 0 0 50000 Y
$ vcgencmd measure_clock pixel
frequency(29)=0
So I guess fw-clk-pixel is not running in the failure mode, and you can't switch hdmi mode (through HDMI_SCHEDULER_CONTROL) without the pixel clock running.
I had a look this morning, but couldn't reproduce it here
I didn't see this on my monitor when switching into/out of standby. I didn't see when switching AV indput on monitor. I didn't see when unplugging/replugging hdmi cable. I did see it when unplugging monitor from mains / plugging back in (specifically on plugging back in).
I'm not sure I understand the difference between the last two. Did you unplug the HDMI cable on the first, and the power plug on the last?
I'll look at the code to see if there's anything obvious
The only case where this could happen is if one of the functions in vc4_hdmi_encoder_pre_crtc_configure that can error (clk_set_rate, clk_set_min_rate, clk_prepare_enable or pm_runtime_resume_and_get) does return an error. Can you print the rest of the logs before that warning? All these functions should have an error message logged if they fail.
Another thing I just remembered, we don't use the hotplug interrupts on the 3B and the polling interval is 10s so plugging/unplugging the monitor fairly fast might be ignored and lead to inconsistent behaviours.
There are no logged error messages before the WARN. e.g. http://sprunge.us/HmP3nh
I just tried unplugging. Waiting a few minutes. Replugging and it failed in the same way: http://sprunge.us/TOxFuc
I'm a bit puzzled by this bug. I did more testing today and neither my 3B or 3B+ shows it on any of the three monitors I tested it with.
Which kind of display did you test it with?
@mripard did you try unplugging hdmi cable? (and replugging ten seconds later). That reliably caused it. Not every time, but more often than not. My monitor didn't provoke it on standby (as it doesn't deassert hotplug then).
I've done that for about 45 minutes now on a 3B, with and without X running, and making sure the kernel would detect the monitor status properly. I'm still not seeing the issue.
Could you share your config.txt file and the mode it's happening in?
Is it with X running?
Just tried at work (so different pi/sdcard and monitor), Failed on second replug. I'm booting to console (no X). config.txt cmdline.txt
pi@b3plus:~ $ uname -a
Linux b3plus 5.15.32-v7+ #1539 SMP Fri Apr 1 11:38:09 BST 2022 armv7l GNU/Linux
pi@b3plus:~ $ vcgencmd version
Mar 24 2022 13:20:54
Copyright (c) 2012 Broadcom
version e5a963efa66a1974127860b42e913d2374139ff5 (clean) (release) (start)
pi@b3plus:~ $ kmsprint
Connector 0 (32) HDMI-A-1 (connected)
Encoder 0 (31) TMDS
Crtc 3 (89) [email protected] 154.000 1920/48/32/80/+ 1200/3/6/26/+ 60 (59.95) 0x5 0x48
Plane 3 (79) fb-id: 291 (crtcs: 3) 0,0 1920x1200 -> 0,0 1920x1200 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU12 YV12 NV12 NV21 NV16 NV61)
FB 291 1920x1200
pi@b3plus:~ $ base64 /sys/devices/platform/soc/soc:gpu/drm/card0/card0-HDMI-A-1/edid
AP///////wAQrLygU002MR0bAQOANCB46gSVqVVNnSYQUFSlSwBxT4GAqUDRwNEAAQEBAQEBKDyA
oHCwI0AwIDYABkQhAAAeAAAA/wA3TVQwMTc3TDE2TVMKAAAA/ABERUxMIFUyNDE1CiAgAAAA/QAx
PR5TEQAKICAgICAgAZ8CAyLxT5AFBAMCBxYBFB8SEyAhIiMJBwdlAwwAIACDAQAAAjqAGHE4LUBY
LEUABkQhAAAeAR2AGHEcFiBYLCUABkQhAACeAR0AclHQHiBuKFUABkQhAAAejArQiiDgLRAQPpYA
BkQhAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAcg==
I'm on a 3B+.
I've tested an upstream kernel (5.18-rc6) and couldn't reproduce this. The comparable downstream kernel did have this issue, so I may be able to bisect it.
Also with:
Linux rothman 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l GNU/Linux
using same model KVM Switches.
I have got the same issue when TV is switched to another source or disabled for a longer time (day or so). Raspberry Pi OS Lite 64 bit with kernel: 5.15.32-v8+ Did you find any temporary workaround for this bugs ?
Did you find any temporary workaround for this bugs ?
Can you try adding video=HDMI-A-1:D to end of /boot/cmdline.txt (on same line).
I think that will avoid the issue.
Can you try adding
video=HDMI-A-1:Dto end of /boot/cmdline.txt (on same line).
Sounds like it will completely disable HDMI port ? . If yes it is not a solution for me.
Do you think @popcornmix would have suggested it if that's what it does?
From https://wiki.archlinux.org/title/kernel_mode_setting:
video=
: x [M][R][- ][@ ][i][m][eDd] ... d: output forced to off D: digital output forced to on (e.g. DVI-I connector)
Ah... forgive me. You are right, I forgot that capital letter has different action. It looks like overscan from /boot/config.txt stop working after adding video parameter but that's ok as temporary solution.
You can add the overscan settings back in. Boot without the change and check /proc/cmdline, and then use that with :D added.
e.g.
video=HDMI-A-1:3840x2160M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48:D
Thank you for suggestion. After reboot /proc/cmdline shows video=with default parameters and second video=with my custom settings but defaults has some kind of higher priority and margin tweaking doesn't work (I don't know maybe I have missed something) . This overscan is not a big problem. I can live with it (at least for a some time).
Add disable_fw_kms_setup=1 to config.txt to stop the firmware adding a video= entry.
https://www.raspberrypi.com/documentation/computers/config_txt.html#disable_fw_kms_setup
