Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: When KDE Plasma Wayland (kwin_wayland) starts on a Raspberry Pi 4, the vc4 DRM driver produces a kernel WARNING at drivers/gpu/drm/vc4/vc4_hvs.c:744 in __vc4_hvs_stop_channel(). The HVS hardware fails to acknowledge a channel stop request within the expected timeout during an atomic modesetting commit. GNOME (mutter) on the same hardware with the same kernel does not trigger this warning. HDMI device connected is a generic HDMI frame grabber at 1920x1080 resolution. System: - Hardware: Raspberry Pi 4 Model B Rev 1.5 (BCM2711, 4GB) - GPU: Broadcom V3D 4.2, vc4-drm kernel driver - U-Boot BIOS: 2026.10-rc1 - RPi firmware: 2026-07-23T12:47:27 - Mesa: 26.2.0-1.fc45 - kwin: 6.7.4-1.fc45 (Plasma 6.7.4) - Qt6: qt6-qtbase-6.11.1-5.fc45 - systemd: 261.2-1.fc45 2. What is the Version-Release number of the kernel: 7.2.0-0.rc6.260806g0d8395707651.51.fc45.aarch64 (Fedora 45 rawhide) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Not sure, will investigate 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1. Install Fedora 45 Rawhide 20260807.n.0 KDE Plasma Desktop Edition (Prerelease) on a Raspberry Pi 4 Model B 2. Boot the system (first boot or subsequent) 3. kwin_wayland starts and performs initial display configuration via DRM atomic modesetting 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attaching boot log. Also adding kernel warning here: Jul 25 02:00:45 fedora kernel: ------------[ cut here ]------------ Jul 25 02:00:45 fedora kernel: WARNING: drivers/gpu/drm/vc4/vc4_hvs.c:744 at __vc4_hvs_stop_channel+0x24c/0x278 [vc4], CPU#0: kwin_wayland/1732 Jul 25 02:00:45 fedora kernel: Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bnep nf_tables hci_uart cpufreq_dt snd_bcm2835(C) btqca btrtl brcmfmac_wcc btsdio btbcm brcmfmac btintel brcmutil bluetooth cfg80211 qrtr vc4 snd_soc_hdmi_codec raspberrypi_cpufreq bcm2711_thermal drm_exec broadcom iproc_rng200 bcm_phy_ptp bcm_phy_lib snd_soc_core genet rfkill snd_compress ac97_bus mdio_bcm_unimac vchiq snd_pcm_dmaengine i2c_mux_pinctrl ledtrig_default_on i2c_mux leds_gpio joydev sunrpc vfat fat binfmt_misc zram lz4hc_compress mmc_block rpmb_core reset_gpio dwc2 snd_pcm udc_core snd_timer pwrseq_simple clk_bcm2711_dvp i2c_brcmstb snd soundcore drm_display_helper bcm2835_dma gpio_raspberrypi_exp bcm2835_wdt sdhci_iproc pwm_bcm2835 i2c_bcm2835 sdhci_pltfm v3d cec sdhci phy_generic drm_dma_helper Jul 25 02:00:45 fedora kernel: gpu_sched raspberrypi_hwmon mmc_core nvmem_rmem fuse i2c_dev aes_neon_bs Jul 25 02:00:45 fedora kernel: CPU: 0 UID: 979 PID: 1732 Comm: kwin_wayland Tainted: G C ------ --- 7.2.0-0.rc6.260806g0d8395707651.51.fc45.aarch64 #1 PREEMPT(lazy) Jul 25 02:00:45 fedora kernel: Tainted: [C]=CRAP Jul 25 02:00:45 fedora kernel: Hardware name: raspberrypi Raspberry Pi 4 Model B Rev 1.5/Raspberry Pi 4 Model B Rev 1.5, BIOS 2026.10-rc1 10/01/2026 Jul 25 02:00:45 fedora kernel: pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) Jul 25 02:00:45 fedora kernel: pc : __vc4_hvs_stop_channel+0x24c/0x278 [vc4] Jul 25 02:00:45 fedora kernel: lr : __vc4_hvs_stop_channel+0x50/0x278 [vc4] Jul 25 02:00:45 fedora kernel: sp : ffff8000839f34f0 Jul 25 02:00:45 fedora kernel: x29: ffff8000839f3500 x28: ffff000044db0d00 x27: 0000000000000000 Jul 25 02:00:45 fedora kernel: x26: 00000000ffffffff x25: 000000000000000a x24: ffff000057a9f000 Jul 25 02:00:45 fedora kernel: x23: ffff00005621a498 x22: ffffa5a369b6b9e0 x21: 0000000000000040 Jul 25 02:00:45 fedora kernel: x20: 0000000000000048 x19: ffff000056218080 x18: 0000000000000000 Jul 25 02:00:45 fedora kernel: x17: 0000000000000000 x16: ffffa5a3c1a7f9b0 x15: ffffa5a3c45a4f08 Jul 25 02:00:45 fedora kernel: x14: ffffa5a3c39a9d00 x13: 0000000000000180 x12: ffff0000fb50bd00 Jul 25 02:00:45 fedora kernel: x11: 00000000000000c0 x10: 0000000000002090 x9 : ffffa5a3c1a7f9e4 Jul 25 02:00:45 fedora kernel: x8 : ffff000081b2c630 x7 : 00000000000015ea x6 : 0000000000000000 Jul 25 02:00:45 fedora kernel: x5 : ffffa5a3c3996fd0 x4 : 0000000000000001 x3 : 0000000000000004 Jul 25 02:00:45 fedora kernel: x2 : ffff000081b2a540 x1 : 0000000010000000 x0 : 0000000000000000 Jul 25 02:00:45 fedora kernel: Call trace: Jul 25 02:00:45 fedora kernel: __vc4_hvs_stop_channel+0x24c/0x278 [vc4] (P) Jul 25 02:00:45 fedora kernel: vc4_hvs_stop_channel+0x38/0x50 [vc4] Jul 25 02:00:45 fedora kernel: vc4_crtc_disable+0x160/0x280 [vc4] Jul 25 02:00:45 fedora kernel: vc4_crtc_atomic_disable+0x9c/0xd8 [vc4] Jul 25 02:00:45 fedora kernel: drm_atomic_helper_commit_crtc_disable+0x114/0x1f8 Jul 25 02:00:45 fedora kernel: drm_atomic_helper_commit_modeset_disables+0x3c/0x80 Jul 25 02:00:45 fedora kernel: vc4_atomic_commit_tail+0x17c/0x558 [vc4] Jul 25 02:00:45 fedora kernel: commit_tail+0xc8/0x208 Jul 25 02:00:45 fedora kernel: drm_atomic_helper_commit+0x180/0x1a0 Jul 25 02:00:45 fedora kernel: drm_atomic_commit+0x94/0xe0 Jul 25 02:00:45 fedora kernel: drm_mode_atomic_ioctl+0x694/0x820 Jul 25 02:00:45 fedora kernel: drm_ioctl_kernel+0xc8/0x138 Jul 25 02:00:45 fedora kernel: drm_ioctl+0x288/0x5c0 Jul 25 02:00:45 fedora kernel: __arm64_sys_ioctl+0xac/0x118 Jul 25 02:00:45 fedora kernel: invoke_syscall.constprop.0+0xac/0x110 Jul 25 02:00:45 fedora kernel: el0_svc_common.constprop.0+0x40/0xf0 Jul 25 02:00:45 fedora kernel: do_el0_svc+0x24/0x40 Jul 25 02:00:45 fedora kernel: el0_svc+0x40/0x198 Jul 25 02:00:45 fedora kernel: el0t_64_sync_handler+0xa0/0xf0 Jul 25 02:00:45 fedora kernel: el0t_64_sync+0x1b0/0x1b8 Jul 25 02:00:45 fedora kernel: ---[ end trace 0000000000000000 ]--- Reproducible: Always
Created attachment 2153914 [details] KDE boot log with added kernel option swiotlb=131072 to avoid another issue
> When KDE Plasma Wayland (kwin_wayland) starts on a Raspberry Pi 4, the vc4 > DRM driver produces a kernel WARNING at drivers/gpu/drm/vc4/vc4_hvs.c:744 in This is a warn once so it's not fatal. Does KDE continue to run as expected or does kwin crash (or something)? > __vc4_hvs_stop_channel(). The HVS hardware fails to acknowledge a channel > stop request within the expected timeout during an atomic modesetting commit. This stop channel is for shutting down/disconnecting an interface, it feels strange that kwin would be doing this on startup. > GNOME (mutter) on the same hardware with the same kernel does not trigger > this warning. On wayland the compositor drives the HW more directly, we've seen a few bugs on KDE vs GNOME where the desktops do things slightly differently so I'm not particularly surprised. > HDMI device connected is a generic HDMI frame grabber at 1920x1080 > resolution. How well does that respond to generic screen off style events generally? I think I might have a generic one of those somewhere I'll see if I can find it. > Not sure, will investigate Maybe even just a F-44 GA image would be a useful test point. > 3. kwin_wayland starts and performs initial display configuration via DRM > atomic modesetting What do you mean by that?
(In reply to Peter Robinson from comment #2) > > When KDE Plasma Wayland (kwin_wayland) starts on a Raspberry Pi 4, the vc4 > > DRM driver produces a kernel WARNING at drivers/gpu/drm/vc4/vc4_hvs.c:744 in > > This is a warn once so it's not fatal. > > Does KDE continue to run as expected or does kwin crash (or something)? Yes, that is correct, it is just a momentary glitch (blank screen) during desktop load. After that GUI seems to behave correctly. > > > __vc4_hvs_stop_channel(). The HVS hardware fails to acknowledge a channel > > stop request within the expected timeout during an atomic modesetting commit. > > This stop channel is for shutting down/disconnecting an interface, it feels > strange that kwin would be doing this on startup. I have no idea about that. Maybe this is related to display enumeration? > > > GNOME (mutter) on the same hardware with the same kernel does not trigger > > this warning. > > On wayland the compositor drives the HW more directly, we've seen a few bugs > on KDE vs GNOME where the desktops do things slightly differently so I'm not > particularly surprised. > > > HDMI device connected is a generic HDMI frame grabber at 1920x1080 > > resolution. > > How well does that respond to generic screen off style events generally? I > think I might have a generic one of those somewhere I'll see if I can find > it. My device is marked as PremiumCord KU2GRAB4, USB reports: 345f:2130 MACROSILICON USB3.0 UHD I'll test with standard HDMI display as well. > > > Not sure, will investigate > > Maybe even just a F-44 GA image would be a useful test point. Tested with current Fedora-KDE-Desktop-Disk-44-1.7.aarch64.raw.xz (kernel 6.19.10-300.fc44, mesa 26.0.3) RPI4 was barely usable, very slow and unresposive/hanging. This is strange as I tested pre-release KDE images and did not notice any such behaviour. I retrieved boot log from the SD card and the vc4 HVS warning is there as well, along with swioltb buffer exhaustion. Attaching the boot log. > > > 3. kwin_wayland starts and performs initial display configuration via DRM > > atomic modesetting > > What do you mean by that? It is just that desktop starts, background is displayed, then video temporarily blanks out and after that displays again. The "DRM atomic modesetting" part was suggested by Claude. Not sure how correct / relevant is that.
Created attachment 2153935 [details] Fedora-KDE-Desktop-Disk-44-1.7.aarch64.raw.xz boot log
> > > 3. kwin_wayland starts and performs initial display configuration via DRM > > > atomic modesetting > > > > What do you mean by that? > > It is just that desktop starts, background is displayed, then video > temporarily blanks out and after that displays again. > The "DRM atomic modesetting" part was suggested by Claude. Not sure how > correct / relevant is that. AFAICT it seems Kwin randomly just goes and probes all outputs it can find, then KWin's DRM backend explicitly disables any CRTC that aren't cleanly assigned to a working output as part of normal output (re)configuration. This it seems it why it turns things off and something in the vc4 isn't in the right state so we get the warn once output. I'm going to report it upstream but it doesn't appear critical.