1. Please describe the problem: RPi4 booted with Fedora-KDE-Desktop-Disk-44-1.1.aarch64.raw.xz image fails to start GUI. UBoot and kernel boot log are displayed fine but there is no display once boot switches to graphical mode. After nomodeset is added to kernel options the GUI shows up fine. Fedora-Workstation-Disk-44-1.1.aarch64.raw.xz works fine on the same HW. Filing against kernel as there are some vc4 driver related errors in boot log but definitely not sure what is the real cause here. 2. What is the Version-Release number of the kernel: Linux version 6.19.10-300.fc44.aarch64 (mockbuild@fea49c8fbab948b09d95fb7305196ad4) (gcc (GCC) 16.0.1 20260321 (Red Hat 16.0.1-0), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT_DYNAMIC Wed Mar 25 17:45:07 UTC 2026 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 : I see the same behavior even with Fedora-KDE-Desktop-Disk-43-1.6.aarch64.raw.xz image. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Just boot the image mentioned above and observe no GUI. 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``: N/A 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. Reproducible: Always
Created attachment 2136418 [details] Boot log - failed GUI
Created attachment 2136419 [details] Boot log - nomodeset
Created attachment 2136420 [details] Package list
Also tried enabling hdmi_enable_4kp60=1 in config.txt as suggested by vc4-drm driver boot message, but no change in observed behavior. Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough to support 4k @ 60Hz. Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] Please change your config.txt file to add hdmi_enable_4kp60. Including boot log of this attempt.
Created attachment 2136422 [details] Boot log - hdmi_enable_4kp60
Proposed as a Blocker for 44-final by Fedora user jgroman using the blocker tracking app because: A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
What is the reported CMA memory allocated? What monitor is attached to the device?
Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough to support 4k @ 60Hz. Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] Please change your config.txt file to add hdmi_enable_4kp60. Mar 13 00:00:22 fedora kernel: Console: switching to colour frame buffer device 240x67 Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device Can you try what it's asking you to do, there's limitation on the RPi4 with 4K 06hz monitors.
(In reply to Peter Robinson from comment #7) > What is the reported CMA memory allocated? > > What monitor is attached to the device? The device connected is this KVM: https://github.com/sipeed/NanoKVM-USB I collected its EDID info and will include it here. I connected my RPi4 to 2K display and KDE booted there into GUI just fine. However Fedora Workstation (GNOME) shows up OK even on my KVM. Including boot log as well. Not sure how can I get memory report. I do not know how to login to the system even using text console because there is no user created yet and that is done in GUI. GNOME workstation reports: CmaTotal: 262144 kB CmaFree: 1560 kB
Created attachment 2136940 [details] KVM_EDID.txt
Created attachment 2136941 [details] Boot log - Workstation (GNOME)
(In reply to Peter Robinson from comment #8) > Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] The core clock cannot > reach frequencies high enough to support 4k @ 60Hz. > Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] Please change your > config.txt file to add hdmi_enable_4kp60. > Mar 13 00:00:22 fedora kernel: Console: switching to colour frame buffer > device 240x67 > Mar 13 00:00:22 fedora kernel: vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer > device > > Can you try what it's asking you to do, there's limitation on the RPi4 with > 4K 06hz monitors. Yes, please see included log file. There was no visible change.
Please include your adjusted config.txt file
(In reply to Jaroslav Groman from comment #9) > (In reply to Peter Robinson from comment #7) > > What is the reported CMA memory allocated? > > > > What monitor is attached to the device? > > The device connected is this KVM: https://github.com/sipeed/NanoKVM-USB > I collected its EDID info and will include it here. Can you set the resolutions is says it supports? > I connected my RPi4 to 2K display and KDE booted there into GUI just fine. So both work as expected with accelerated graphics on a 2K display? > However Fedora Workstation (GNOME) shows up OK even on my KVM. Including > boot log as well. So GNOME works fine without change, but KDE needs nomodeset? Including boot log for what?
(In reply to Peter Robinson from comment #14) > (In reply to Jaroslav Groman from comment #9) > > (In reply to Peter Robinson from comment #7) > > > What is the reported CMA memory allocated? > > > > > > What monitor is attached to the device? > > > > The device connected is this KVM: https://github.com/sipeed/NanoKVM-USB > > I collected its EDID info and will include it here. > > Can you set the resolutions is says it supports? Yes, but it has no effect on reported problem. > > > I connected my RPi4 to 2K display and KDE booted there into GUI just fine. > > So both work as expected with accelerated graphics on a 2K display? Yes. Both KDE and GNOME work fine on 2K display. > > > However Fedora Workstation (GNOME) shows up OK even on my KVM. Including > > boot log as well. > > So GNOME works fine without change, but KDE needs nomodeset? Including boot > log for what? Yes: GNOME works out of the box, KDE needs nomodeset when connected to my 4K KVM. Included GNOME boot log with successful boot just for reference.
(In reply to Peter Robinson from comment #13) > Please include your adjusted config.txt file I am using config.txt already being present in EFI partition. For hdmi_enable_4kp60 I just uncommented hdmi_enable_4kp60=1 line in [pi4] section.
Created attachment 2136944 [details] config.txt
> > So GNOME works fine without change, but KDE needs nomodeset? Including boot > > log for what? > > Yes: GNOME works out of the box, KDE needs nomodeset when connected to my 4K > KVM. > Included GNOME boot log with successful boot just for reference. So this feels like something that the KDE login manager is doing, I think it changed to PLM as part of a F-44 change [1] so let's see if they can provide more info. [1] https://fedoraproject.org/wiki/Changes/PlasmaLoginManager
This is likely a kwin issue.
When you write "fails to start GUI", do you mean that you don't get any interface (but a cursor is visible), that it's completely black, or that the display turns off completely? In the log, > plasma-ksplash.service: start operation timed out. is rather weird, I don't think it's supposed to even run on the login screen. Other than that, there's nothing I'd consider relevant. Can you ssh into the system while it's not working, and get the output of drm_info?
I added nomodeset to complete initial user setup and then removed it again so that the problem would occur. After booting I was able to login using text console and now there is some more info in the boot log: Apr 13 14:42:21 kernel: ------------[ cut here ]------------ Apr 13 14:42:21 kernel: WARNING: drivers/gpu/drm/vc4/vc4_hvs.c:744 at __vc4_hvs_stop_channel+0x24c/0x278 [vc4], CPU#1: kwin_wayland/1682 Apr 13 14:42:21 kernel: Modules linked in: 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 nf_tables qrtr bnep sunrpc cpufreq_dt brcmfmac_wcc snd_bcm2835(C) hci_uart btqca btsdio btrtl brcmfmac btbcm btintel vc4 bluetooth brcmutil snd_soc_hdmi_codec drm_exec cfg80211 binfmt_misc snd_soc_core pwrseq_core raspberrypi_cpufreq snd_compress broadcom rfkill ac97_bus bcm_phy_ptp snd_pcm_dmaengine bcm_phy_lib i2c_mux_pinctrl iproc_rng200 genet ledtrig_default_on bcm2711_thermal vchiq i2c_mux mdio_bcm_unimac leds_gpio vfat fat joydev nfnetlink zram lz4hc_compress lz4_compress mmc_block rpmb_core reset_gpio gpio_raspberrypi_exp raspberrypi_hwmon snd_pcm dwc2 i2c_brcmstb sdhci_iproc udc_core pwrseq_simple i2c_bcm2835 pwm_bcm2835 sdhci_pltfm snd_timer v3d clk_bcm2711_dvp snd bcm2835_wdt sdhci gpu_sched bcm2835_dma soundcore mmc_core drm_display_helper cec nvmem_rmem Apr 13 14:42:21 kernel: phy_generic drm_dma_helper fuse i2c_dev aes_neon_bs Apr 13 14:42:21 kernel: CPU: 1 UID: 985 PID: 1682 Comm: kwin_wayland Tainted: G C 6.19.10-300.fc44.aarch64 #1 PREEMPT(voluntary) Apr 13 14:42:21 kernel: Tainted: [C]=CRAP Apr 13 14:42:21 kernel: Hardware name: raspberrypi Raspberry Pi 4 Model B Rev 1.5/Raspberry Pi 4 Model B Rev 1.5, BIOS 2026.04-rc5 04/01/2026 Apr 13 14:42:21 kernel: pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) Apr 13 14:42:21 kernel: pc : __vc4_hvs_stop_channel+0x24c/0x278 [vc4] Apr 13 14:42:21 kernel: lr : __vc4_hvs_stop_channel+0x50/0x278 [vc4] Apr 13 14:42:21 kernel: sp : ffff80008425b780 Apr 13 14:42:21 kernel: x29: ffff80008425b790 x28: ffff000051438e80 x27: 0000000000000000 Apr 13 14:42:21 kernel: x26: 00000000ffffffff x25: 000000000000000a x24: ffff00005b3ce000 Apr 13 14:42:21 kernel: x23: ffff00004d492560 x22: ffffa9039ac37848 x21: 0000000000000040 Apr 13 14:42:21 kernel: x20: 0000000000000048 x19: ffff0000443aa080 x18: 0000000000000001 Apr 13 14:42:21 kernel: x17: 00000000fffffff9 x16: ffffa903cd5eb618 x15: ffffa903cff171b8 Apr 13 14:42:21 kernel: x14: ffffa903cf34f500 x13: 0000000000000191 x12: ffff0000fb536500 Apr 13 14:42:21 kernel: x11: 00000000000000c0 x10: 0000000000001ef0 x9 : ffffa903cd5eb64c Apr 13 14:42:21 kernel: x8 : ffff0000521d4310 x7 : 000000000000004b x6 : 0000000000000000 Apr 13 14:42:21 kernel: x5 : ffffa903cf361e10 x4 : 0000000000000001 x3 : 0000000000000004 Apr 13 14:42:21 kernel: x2 : ffff0000521d23c0 x1 : 0000000010000000 x0 : 0000000000000000 Apr 13 14:42:21 kernel: Call trace: Apr 13 14:42:21 kernel: __vc4_hvs_stop_channel+0x24c/0x278 [vc4] (P) Apr 13 14:42:21 kernel: vc4_hvs_stop_channel+0x38/0x50 [vc4] Apr 13 14:42:21 kernel: vc4_crtc_disable+0x160/0x280 [vc4] Apr 13 14:42:21 kernel: vc4_crtc_atomic_disable+0x9c/0xd8 [vc4] Apr 13 14:42:21 kernel: drm_atomic_helper_commit_crtc_disable+0x114/0x1f8 Apr 13 14:42:21 kernel: drm_atomic_helper_commit_modeset_disables+0x3c/0x80 Apr 13 14:42:21 kernel: vc4_atomic_commit_tail+0x17c/0x558 [vc4] Apr 13 14:42:21 kernel: commit_tail+0xc8/0x208 Apr 13 14:42:21 kernel: drm_atomic_helper_commit+0x180/0x1a0 Apr 13 14:42:21 kernel: drm_atomic_commit+0x94/0xe0 Apr 13 14:42:21 kernel: drm_mode_atomic_ioctl+0x654/0x790 Apr 13 14:42:21 kernel: drm_ioctl_kernel+0xc8/0x138 Apr 13 14:42:21 kernel: drm_ioctl+0x234/0x4b8 Apr 13 14:42:21 kernel: __arm64_sys_ioctl+0xac/0x110 Apr 13 14:42:21 kernel: invoke_syscall.constprop.0+0x64/0xe8 Apr 13 14:42:21 kernel: el0_svc_common.constprop.0+0x40/0xe8 Apr 13 14:42:21 kernel: do_el0_svc+0x24/0x38 Apr 13 14:42:21 kernel: el0_svc+0x3c/0x180 Apr 13 14:42:21 kernel: el0t_64_sync_handler+0xa0/0xe8 Apr 13 14:42:21 kernel: el0t_64_sync+0x1b0/0x1b8 Apr 13 14:42:21 kernel: ---[ end trace 0000000000000000 ]---
Created attachment 2136946 [details] drm_info
(In reply to Xaver Hugl from comment #20) > When you write "fails to start GUI", do you mean that you don't get any > interface (but a cursor is visible), that it's completely black, or that the > display turns off completely? No cursor, display is completely black. Since it is KVM, I cannot say if it is turned off. > > In the log, > > plasma-ksplash.service: start operation timed out. > is rather weird, I don't think it's supposed to even run on the login > screen. Other than that, there's nothing I'd consider relevant. Can you ssh > into the system while it's not working, and get the output of drm_info? Uploaded.
> After booting I was able to login using text console and now there is some more info in the boot log: I don't know if that's related, but if the driver fails to turn off a crtc properly, it might have more issues. > │ │ ├───Format: RGB565 (0x36314752) Well that's certainly unusual. KWin will only use that format if any other format didn't work. One possibility I see is that the driver maybe has a problem with 10bpc over the wire. If you set KWIN_DRM_PREFER_COLOR_DEPTH=24, does that help?
Unfortunately setting KWIN_DRM_PREFER_COLOR_DEPTH=24 does not help. I just realized I was uploading boot logs filtered to kernel only. I apologize for that. Uploading a complete boot journal dump with KWIN_DRM_PREFER_COLOR_DEPTH=24.
Created attachment 2136973 [details] Boot log - color depth 24
AGREED RejectedFinalBlocker Discussed at the 2026-04-13 (blocker / freeze exception) review meeting: It seems like this issue is not a general problem affecting all Pi 4s and all 4K displays, but rather a specific problem between kwin and some strange EDID data from the tested KVM switch. Consequently, the bug is rejected. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-13/f44-blocker-review.2026-04-13-16.00.log.txt