Raspberry Pi monitor off -> on on Pi4 triggers splat on 6.18.32

[nbuchwitz]

Describe the bug

Quick observation while debugging the genet issue on a Pi 4:

I have a Pi 4 with a Raspberry Pi monitor connected via HDMI. The monitor was switched off when I left my office and switched on today to see what happened to the device, because the genet network issue finally hit.

Everything is working, but the kernel log shows:

[Wed May 20 10:52:13 2026] ------------[ cut here ]------------
[Wed May 20 10:52:13 2026] WARNING: CPU: 1 PID: 1259 at drivers/gpu/drm/vc4/vc4_hvs.c:1064 __vc4_hvs_stop_channel+0x158/0x180 [vc4]
[Wed May 20 10:52:13 2026] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfcomm cmac algif_hash aes_arm64 algif_skcipher af_alg bnep brcmfmac_cyw binfmt_misc brcmfmac hci_uart btbcm bluetooth brcmutil vc4 cfg80211 snd_soc_hdmi_codec drm_exec bcm2835_v4l2(C) drm_display_helper bcm2835_codec(C) bcm2835_isp(C) ecdh_generic v3d cec ecc bcm2835_mmal_vchiq(C) drm_dma_helper gpu_sched drm_client_lib snd_soc_core drm_shmem_helper rpi_hevc_dec drm_kms_helper rfkill vc_sm_cma(C) v4l2_mem2mem videobuf2_vmalloc snd_bcm2835(C) snd_compress videobuf2_dma_contig snd_pcm_dmaengine i2c_brcmstb videobuf2_memops joydev raspberrypi_hwmon videobuf2_v4l2 videodev snd_pcm videobuf2_common raspberrypi_gpiomem mc snd_timer snd nvmem_rmem sch_fq_codel i2c_dev zram lz4_compress drm drm_panel_orientation_quirks backlight fuse nfnetlink ipv6 libsha1
[Wed May 20 10:52:13 2026] CPU: 1 UID: 1000 PID: 1259 Comm: labwc Tainted: G         C          6.18.32-v8+ #1 PREEMPT 
[Wed May 20 10:52:13 2026] Tainted: [C]=CRAP
[Wed May 20 10:52:13 2026] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[Wed May 20 10:52:13 2026] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[Wed May 20 10:52:13 2026] pc : __vc4_hvs_stop_channel+0x158/0x180 [vc4]
[Wed May 20 10:52:13 2026] lr : __vc4_hvs_stop_channel+0x50/0x180 [vc4]
[Wed May 20 10:52:13 2026] sp : ffffffc0848c38b0
[Wed May 20 10:52:13 2026] x29: ffffffc0848c38c0 x28: 0000000000000028 x27: 0000000000000001
[Wed May 20 10:52:13 2026] x26: 000000000000000a x25: 0000000000418958 x24: ffffff8043eb6000
[Wed May 20 10:52:13 2026] x23: ffffff80830f4000 x22: 0000000000000000 x21: ffffff8080490500
[Wed May 20 10:52:13 2026] x20: ffffff80427b8080 x19: 0000000000000000 x18: 0000000000000000
[Wed May 20 10:52:13 2026] x17: 0000000000000000 x16: ffffffd34cf57ff8 x15: 00000055a2fd8b20
[Wed May 20 10:52:13 2026] x14: 000007183ad0ac80 x13: 0000000000000000 x12: 0000000000000000
[Wed May 20 10:52:13 2026] x11: 00000000000000c0 x10: 0000000000001ac0 x9 : ffffffd32e57d15c
[Wed May 20 10:52:13 2026] x8 : ffffff8043ecbca0 x7 : 0000000000000000 x6 : 0000000000000007
[Wed May 20 10:52:13 2026] x5 : 00000000000a38be x4 : 0000000000000000 x3 : 0000000040000000
[Wed May 20 10:52:13 2026] x2 : 0000000000000000 x1 : 0000000010000000 x0 : 0000000000000000
[Wed May 20 10:52:13 2026] Call trace:
[Wed May 20 10:52:13 2026]  __vc4_hvs_stop_channel+0x158/0x180 [vc4] (P)
[Wed May 20 10:52:13 2026]  vc4_hvs_stop_channel+0x38/0x50 [vc4]
[Wed May 20 10:52:13 2026]  vc4_crtc_disable+0x14c/0x200 [vc4]
[Wed May 20 10:52:13 2026]  vc4_crtc_atomic_disable+0x9c/0xe0 [vc4]
[Wed May 20 10:52:13 2026]  drm_atomic_helper_commit_crtc_disable+0x110/0x1f0 [drm_kms_helper]
[Wed May 20 10:52:13 2026]  drm_atomic_helper_commit_modeset_disables+0x3c/0x78 [drm_kms_helper]
[Wed May 20 10:52:13 2026]  vc4_atomic_commit_tail+0x16c/0x970 [vc4]
[Wed May 20 10:52:13 2026]  commit_tail+0xac/0x1a0 [drm_kms_helper]
[Wed May 20 10:52:13 2026]  drm_atomic_helper_commit+0x184/0x1a8 [drm_kms_helper]
[Wed May 20 10:52:13 2026]  drm_atomic_commit+0x94/0xe0 [drm]
[Wed May 20 10:52:13 2026]  drm_mode_atomic_ioctl+0xa80/0xd28 [drm]
[Wed May 20 10:52:13 2026]  drm_ioctl_kernel+0xc8/0x138 [drm]
[Wed May 20 10:52:13 2026]  drm_ioctl+0x214/0x4d8 [drm]
[Wed May 20 10:52:13 2026]  __arm64_sys_ioctl+0xb4/0x118
[Wed May 20 10:52:13 2026]  invoke_syscall+0x4c/0xf8
[Wed May 20 10:52:13 2026]  el0_svc_common.constprop.0+0x48/0xf0
[Wed May 20 10:52:13 2026]  do_el0_svc+0x24/0x38
[Wed May 20 10:52:13 2026]  el0_svc+0x38/0x120
[Wed May 20 10:52:13 2026]  el0t_64_sync_handler+0xa0/0xe8
[Wed May 20 10:52:13 2026]  el0t_64_sync+0x198/0x1a0
[Wed May 20 10:52:13 2026] ---[ end trace 0000000000000000 ]---

Haven't had time to dig deeper, just wanted to report it in case others see this too. Not sure if this is really a driver issue and not eventually a labwc bug?

Steps to reproduce the behaviour

1. Turn monitor off
2. Go to sleep
3. Turn monitor on

Device (s)

Raspberry Pi 4 Mod. B

System

Linux rpi4 6.18.32-v8+ #1 SMP PREEMPT Tue May 19 08:18:37 UTC 2026 aarch64 GNU/Linux

nbw@rpi4:~ $ cat /boot/firmware/.firmware_revision 
d126e159e5c1efa734cb5a7afa3c9c7e5247acd3

Logs

No response

Additional context

No response

[pelwell]

The corresponding section of the hvs driver says (in __vc4_hvs_stop_channel):

	WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
		      (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
		     SCALER_DISPSTATX_EMPTY);

which by my reading says that the channel is not empty (although I'm surprised that both the FULL and EMPTY bits are looked at - I hope they are mutually exclusive).

A quick test here on top-of-tree (01f7332) didn't show anything unusual, but I did miss out the sleep step.

[nbuchwitz]

Thanks. Seems to be hard to reproduce - tried again with waiting a bit between off and on again, but hadn't' had any "luck" so far. So maybe this is just a rare racy where the cleanup in userspace during hdmi off didn't work. As I said, everything is working correctly besides the warning, so this isn't bothering me much at the moment.

[pelwell]

Understood. I have no problem with reports like this as a means of potentially gathering supporting evidence from other users.