Raspberry Pi 4 issues with Fedora Rawhide
by Lukas Brabec
Hi all,
I am writing this email to raise awareness well ahead of the F41 branching
on August 6 about the bugs I found while running Fedora Rawhide on the RPi
4.
I have proposed these bugs as blockers for the F41 release:
* gnome-initial-setup: Choosing avatar results in SetIconFile call failed
for
unknown reason [0]
I proposed this as F41 Final blocker, but this is fairly minor bug and I can
imagine that we would waive it if not fixed and create a common issue.
* gsk: vulkan renderer breaks gtk4 apps on Raspberry Pi 4 and 400 [1]
GSK now defaults to vulkan and it causes problems on RPi, I initially
encountered crashing gnome-initial-setup (and later that all GTK4 apps are
crashing upon startup). Thus I proposed it as a F41 Beta blocker. This
crashing on app startup will be resolved in the next GTK release, the fix is
already merged.
However, there are still issues with GTK4 apps [2], all related to vulkan
renderer [3] [4] [5]. It is not yet clear if the problems are bugs in GTK or
mesa. In the end, if proven difficult to fix, we could always switch back to
older renderer as suggested by Adam during F40 cycle [6].
* Raspberry Pi 4 won't wake up from suspend [7]
Although we don't have a criterion for suspend, I proposed this as a blocker
bug. I cannot login every time I keep Raspberry Pi idling for 15 minutes and
I have to restart it, this could also lead to loss of data. This is
something
different compared to the x86_64 situation. On x86_64 we probably wouldn't
block on suspend on some particular hardware configuration, but I think we
should block here since we support only a handful of ARM boards.
Also, suspend on Raspberry Pi OS is disabled, so I'm not sure if suspend on
Raspberry Pi is something we even want in Fedora.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2278845
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2282171
[2] https://gitlab.gnome.org/GNOME/gtk/-/issues/6726#note_2121079
[3] https://gitlab.gnome.org/GNOME/gtk/-/issues/6743
[4] https://gitlab.gnome.org/GNOME/gtk/-/issues/6744
[5] https://gitlab.gnome.org/GNOME/gtk/-/issues/6745
[6] https://gitlab.gnome.org/GNOME/gtk/-/issues/6498#note_2063629
[7] https://bugzilla.redhat.com/show_bug.cgi?id=2283978
---
L.
5 days, 10 hours
Fedora ARM Weekly Meeting Cancelled - 28 May 2024
by Geoffrey Marr
Hi all,
I have a conflict this morning and am cancelling the ARM meeting. If
someone would like to run the meeting, feel free. Otherwise we will plan on
meeting next week.
Geoff Marr
IRC: coremodule
1 week, 1 day
Fedora 40 and Helios64 => success
by Dan Horák
Hi all,
after couple years of sitting under the desk I have thought it's time
to try Fedora on Helios64. There was progress in mainline kernel
regarding the hardware support in the past year or two, so why not to
give it a try. There is no mainline u-boot support for Helios64, thus
the idea was to use Armbian's u-boot, which should support EFI boot,
combined with Fedora minimal disk image. After some head scratching and
resolving 2 issues I got the login prompt.
First issue is that Armbian's u-boot is bigger than 1 MB, thus our disk
layout, where the first partition (EFI) starts at 9 MB, means it gets
overwritten a bit. Solution was to shift all partitions 1 MB further.
Perhaps we should default to the 10 MB in the official images too.
Second issue was a crash quite late in the boot in cpu_idle() for CPU
#5, which seems to be the low-power core. Workaround was to limit the number of
cpus to 4 using kernel's maxcpus= parameter.
The result is
[dan@helios64 ~]$ sudo dmesg | head
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 6.8.5-301.fc40.aarch64 (mockbuild@5efd934e27f44ed09084502b9de5d773) (gcc (GCC) 14.0.1 20240328 (Red Hat 14.0.1-0), GNU ld version 2.41-34.fc40) #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:30:05 UTC 2024
[ 0.000000] KASLR disabled due to lack of seed
[ 0.000000] Machine model: Helios64
[ 0.000000] efi: EFI v2.9 by Das U-Boot
[ 0.000000] efi: RTPROP=0xf4ece040 SMBIOS=0xf4ecd000 MOKvar=0xf4da0000 MEMRESERVE=0xf4d97040
[ 0.000000] NUMA: No NUMA configuration found
[ 0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x00000000f7ffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0xf755c2c0-0xf7572fff]
[ 0.000000] Zone ranges:
With regards,
Dan
3 weeks, 5 days