Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: vc4-drm GPU driver repeatedly logs "swiotlb buffer is full" warnings on Raspberry Pi 400 connected to a 2560x1440 HDMI monitor. The warnings occur during normal GNOME desktop usage and accumulate (48 in a single session). No visible display issues were observed - the desktop renders correctly, no graphical glitches or artifacts. Only the kernel log errors. Version-Release number of selected component: kernel-7.2.0-0.rc6.48.fc45.aarch64 How reproducible: Always (100%) Steps to Reproduce: 1. Boot Raspberry Pi 400 with Fedora 45 (aarch64) 2. Connect 2560x1440 HDMI monitor (e.g. Lenovo P27h-20) 3. Log into GNOME desktop 4. Use desktop normally (open/close apps, switch windows) 5. Run: journalctl -b | grep swiotlb Actual Results: Repeated kernel warnings: vc4-drm gpu: swiotlb buffer is full (sz: 1048576 bytes), total 32768 (slots), used 1 (slots) vc4-drm gpu: swiotlb buffer is full (sz: 2097152 bytes), total 32768 (slots), used 1 (slots) vc4-drm gpu: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 1 (slots) Requested sizes: 512KB, 1MB, 2MB, 4MB. 48 occurrences in one session, increasing with desktop activity. Additionally at boot: simple-framebuffer simple-framebuffer.0: [drm] *ERROR* could not acquire memory range: -16 Expected Results: No swiotlb warnings during normal desktop usage. Additional info: - Hardware: Raspberry Pi 400, 4 GB RAM, BCM2711 SoC - Monitor: Lenovo P27h-20 via HDMI, 2560x1440@60Hz - GPU driver: vc4-drm (vc4.ko) - CMA pool: 256 MB at 0x17e00000
ccing
> during normal GNOME desktop usage and accumulate (48 in a single session). What applications are you using? Are there particular things that you're doing when these show up? > Additionally at boot: > simple-framebuffer simple-framebuffer.0: [drm] *ERROR* could not acquire > memory range: -16 Yes, that's a fake warning, it's because the simpledrm driver is loaded (which is the one we want). Already working on a unrelated fix. > Additional info: > - Hardware: Raspberry Pi 400, 4 GB RAM, BCM2711 SoC > - Monitor: Lenovo P27h-20 via HDMI, 2560x1440@60Hz > - GPU driver: vc4-drm (vc4.ko) > - CMA pool: 256 MB at 0x17e00000 What version of mesa etc? There's a new mesa 26.2 just landed for f45
I am seeing the same problem also on KDE image with the latest mesa: System Info - Hardware: Raspberry Pi 4 Model B Rev 1.5 (BCM2711, 4GB RAM) - GPU: Broadcom V3D 4.2 (vc4-drm kernel driver, v3d Mesa driver) - U-Boot BIOS: 2026.10-rc1 - RPi firmware: 2026-07-23T12:47:27 Software - Kernel: 7.2.0-0.rc6.260806g0d8395707651.51.fc45.aarch64 (PREEMPT_DYNAMIC lazy) - systemd: 261.2-1.fc45 - Mesa: 26.2.0-1.fc45 (mesa-dri-drivers, mesa-vulkan-drivers) - KDE Plasma Desktop: 6.7.4-1.fc45 - kwin: 6.7.4-1.fc45 - plasma-workspace: 6.7.4-1.fc45 - plasma-login-manager: 6.7.4-1.fc45 - plasma-setup: 6.7.4-1.fc45 - Qt6: qt6-qtbase-6.11.1-5.fc45 - KDE Frameworks: kf6-kwindowsystem-6.28.0-2.fc45 - kde-settings: 43.101-6.fc45 Issues Observed 1. vc4 HVS channel stop timeout -- WARNING: drivers/gpu/drm/vc4/vc4_hvs.c:744 triggered by kwin_wayland (PID 1732) during drm_mode_atomic_ioctl 2. swiotlb buffer exhaustion -- continuous swiotlb buffer is full (sz: 1-4MB) from vc4-drm, sustained for ~2 minutes after compositor start vc4 HVS channel timeout problem will be reported separately. I have booted the RPi4 with "swiotlb=131072" kernel boot option and can confirm that this fixes the buffer exhaustion issue. Including boot logs before and after adding the kernel option.
Created attachment 2153912 [details] KDE boot log with default kernel options
Created attachment 2153913 [details] KDE boot log with added "swiotlb=131072"
Can you give the following output with/without the swiotlb cmdline option? # dmesg|grep -i "IO TLB"
# Without swiotlb ➜ grep "IO TLB" dmesg2.txt [ 0.000000] software IO TLB: area num 4. [ 0.000000] software IO TLB: mapped [mem 0x0000000035c00000-0x0000000039c00000] (64MB) # With swiotlb ➜ grep "IO TLB" dmesg3.txt [ 0.000000] software IO TLB: area num 4. [ 0.000000] software IO TLB: mapped [mem 0x0000000001400000-0x0000000011400000] (256MB)
With the latest nightly https://fedoraproject.org/wiki/Test_Results:Fedora_45_Branched_20260811.n.1_Installation there are no vc4 HVS channel stop warnings and swiotlb buffer exhaustions neither in Gnome nor in KDE boot logs. KDE image component versions: 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-08-06T15:49:28 Software - Kernel: 7.2.0-0.rc6.260807gf9a2394a2348.52.fc45.aarch64 - systemd: 261.2-1.fc45 - dracut: 111-1.fc45 - Mesa: 26.2.0-1.fc45 (mesa-dri-drivers, mesa-vulkan-drivers) - KDE Plasma: 6.7.4-1.fc45 (plasma-desktop, plasma-workspace) - kwin: 6.7.4-1.fc45 - plasma-login-manager: 6.7.4-1.fc45 - Qt6: qt6-qtbase-6.11.1-5.fc45 - KDE Frameworks: kf6-kwindowsystem-6.29.0-1.fc45 - kde-settings: 43.101-6.fc45 ➜ grep -i "IO TLB" boot_kde_20260811.n.1.txt Jul 25 02:00:01 fedora kernel: software IO TLB: area num 4. Jul 25 02:00:01 fedora kernel: software IO TLB: mapped [mem 0x0000000035800000-0x0000000039800000] (64MB) However KDE boot log now contains new warning which was not present in previously tested nightlies: ➜ grep -i "The main thread" boot_kde_20260811.n.1.txt Aug 12 12:34:20 fedora-kde kwin_wayland[3818]: The main thread was hanging temporarily! Aug 12 12:34:22 fedora-kde kwin_wayland[3818]: The main thread was hanging temporarily! Aug 12 12:34:24 fedora-kde kwin_wayland[3818]: The main thread was hanging temporarily! Aug 12 12:34:37 fedora-kde kwin_wayland[3818]: The main thread was hanging temporarily! Aug 12 12:34:46 fedora-kde kwin_wayland[3818]: The main thread was hanging temporarily!
> However KDE boot log now contains new warning which was not present in > previously tested nightlies: > ➜ grep -i "The main thread" boot_kde_20260811.n.1.txt > Aug 12 12:34:20 fedora-kde kwin_wayland[3818]: The main thread was hanging > temporarily! I think that needs to be a new kwin bug report.
Turns out it is more complicated - swiotlb buffer exhaustion problem seems to depend on the boot device: RPi4 booted from an SD card: swiotlb buffer problem is still present RPi4 booted from USB flash drive: no swiotlb errors but ocassional main thread hanging warning I tested booting from USB and SD card multiple times and swiotlb buffer exhaustion appeared only during SD card boots so that issue is very likely SD card specific. Maybe the swiotlb buffer is shared between SD controller and vc4 driver? My SD card is rated UHS Speed Class 1 and the USB flash drive is USB 2.0 so their data transfer speeds are likely comparable.