When running a Workstation Beta 1.3 image[0] on a Raspberry Pi 4b, graphical decorations (anything in the title bar, graphics in the side bar of Nautilus) are missing. The decorations appear as expected on my x86_64 machines. [0] - https://kojipkgs.fedoraproject.org/compose/40/Fedora-40-20240313.0/compose/Workstation/aarch64/images/Fedora-Workstation-40_Beta-1.3.aarch64.raw.xz Reproducible: Always Steps to Reproduce: 1. Boot Workstation on a Raspberry Pi 4b 2. Open an application (gnome-software, nautilus) Actual Results: Decorations are missing. Expected Results: Decorations to appear.
This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/. This issue should only be kept open if it: 1. Relates to Fedora packaging or integration with other Fedora components 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions If this issue isn't needed for either of these two reasons, please: * create an issue with GNOME * add a link to the GNOME issue here * close this issue as CLOSED/UPSTREAM Thank you!
Created attachment 2021469 [details] Missing decoration in gnome-software
Created attachment 2021470 [details] Missing decorations in title bar and sidebar of nautilus
Created attachment 2021471 [details] More missing decorations in gnome-software
On Fedora-Workstation-40_Beta-1.8.aarch64, some GUI assets (e.g. UI icons in nautilus, overly controls in loupe) won't load. System booted with nomodeset doesn't have the issue. This happens both on Raspberry Pi 4 and Pi 400. It seems that this bug is present only in GTK 4 applications, firefox or gnome-terminal works as expected. Journal is full of kernel v3d errors such as (see the attachment for complete log): Mar 19 12:07:38 fedora kernel: v3d fec00000.v3d: MMU error from client L2T (0) at 0x179f7e00, pte invalid These errors appear exactly the moment GTK 4 application is launched. Nautilus works as expected (all GUI assets are loaded) if launched using the old gl renderer instead of the new ngl renderer: $ GSK_RENDERER=gl nautilus
Created attachment 2022521 [details] journalctl -b
kernel-6.8.0-0.rc6.49.fc40.aarch64 mesa-dri-drivers-24.0.0-2.fc40.aarch64 mesa-libEGL-24.0.0-2.fc40.aarch64 mesa-libGL-24.0.0-2.fc40.aarch64 gtk4-4.13.9-1.fc40.aarch64 mutter-46.0-1.fc40.aarch64
Proposed as a Blocker for 40-beta by Fedora user lbrabec using the blocker tracking app because: This bug violates basic criterion: Window manager functionality (common application content such as regular application windows must be displayed correctly). Also violates beta criterion: Installing, removing and updating software (usability of GNOME Software is terrible without icons).
Can you give me the output of "dmesg |grep Memory"
$ sudo dmesg | grep Memory [ 0.000000] Memory: 3440812K/4050948K available (18688K kernel code, 4410K rwdata, 16144K rodata, 10624K init, 10509K bss, 347992K reserved, 262144K cma-reserved) [ 19.883530] systemd[1]: Listening on systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket.
In /boot/efi/config.txt can you update the dtoverlay=cma,cma-256 line to dtoverlay=cma,cma-512 and see if that helps
> Mar 19 12:07:38 fedora kernel: v3d fec00000.v3d: MMU error from client L2T (0) at 0x179f7e00, pte invalid > These errors appear exactly the moment GTK 4 application is launched. According to upstream reports those aren't meant to be a problem but TBH it's hard to tell. I feel if it's GTK4 and doesn't happen for others it must be mesa, or maybe GPU memory usage by GTK4 apps.
(In reply to Peter Robinson from comment #11) > In /boot/efi/config.txt can you update the dtoverlay=cma,cma-256 line to > dtoverlay=cma,cma-512 and see if that helps No, that did not help
Did the "262144K cma-reserved" line update to 512Mb? I think this is a mesa issue.
Would also be useful to know how KDE and other desktops fare
Was this broken (on Pi 4b, obviously, since Pi 400 was untestable) with earlier Beta candidates? Say, check 1.2 and 1.7?
(In reply to Adam Williamson from comment #16) > Was this broken (on Pi 4b, obviously, since Pi 400 was untestable) with > earlier Beta candidates? Say, check 1.2 and 1.7? You mean prior to the latest gnome update being tagged in?
(In reply to Adam Williamson from comment #16) > Was this broken (on Pi 4b, obviously, since Pi 400 was untestable) with > earlier Beta candidates? Say, check 1.2 and 1.7? Broken on a Pi 4b with 1.2.
Peter: I was wondering about the GNOME update and the Pi 400 fix. But it sounds like until recent candidates we had to test with 'nomodeset', so it seems likely this was broken all along but we just didn't know because we couldn't test with acceleration...
(In reply to Peter Robinson from comment #11) > In /boot/efi/config.txt can you update the dtoverlay=cma,cma-256 line to > dtoverlay=cma,cma-512 and see if that helps At least for me, Gnome just crashes back to GDM if I try to login with that set (on 1.2 anyway). I verified the "262144K cma-reserved" line updated to 512Mb at a virtual console.
(In reply to Brandon Nielsen from comment #20) > (In reply to Peter Robinson from comment #11) > > In /boot/efi/config.txt can you update the dtoverlay=cma,cma-256 line to > > dtoverlay=cma,cma-512 and see if that helps > > At least for me, Gnome just crashes back to GDM if I try to login with that > set (on 1.2 anyway). > > I verified the "262144K cma-reserved" line updated to 512Mb at a virtual > console. 1.8 doesn't crash on login with the CMA reserved change, but it also doesn't fix the missing graphics issue.
> 1.8 doesn't crash on login with the CMA reserved change, but it also doesn't > fix the missing graphics issue. Most of the GPU driver is in mesa hence why I think it's there, I'm pinged a few people upstream to see where they believe it may be. Either way this is somewhere in the graphics/gnome stack so not me.
Confirmed mesa, filed upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10853
There's a couple of minor v3d fixes in stable mesa between 24.0.0 and 24.0.3 but it's currently FTB but I'm not sure they'll fix the problem: 24.0.2: v3d,v3dv: fix BO allocation for shared vars 24.0.3: v3d: add load_fep_w_v3d intrinsic v3d: fix line coords with perspective projection
(In reply to Peter Robinson from comment #15) > Would also be useful to know how KDE and other desktops fare well, I just tried KDE on RPi4: https://bugzilla.redhat.com/show_bug.cgi?id=2270430
*** Bug 2270430 has been marked as a duplicate of this bug. ***
+3 blocker in https://pagure.io/fedora-qa/blocker-review/issue/1534 , so marking accepted. We may well ultimately waive this for Beta, though.
From the screenshots at https://discussion.fedoraproject.org/t/do-i-need-to-setup-more-permissions-to-upload-relval-results/109085/2 , it looks like something rather similar is affecting VMWare.
discussed at the F40 Beta Go/No-Go meeting on 2024-03-21 - https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.html . This was waived to Fedora 40 Final per the "Exceptional cases" waiver policy - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases - as being both "last minute" *and* "difficult to fix" - we are at the mercy of upstream mesa for a fix here, and they say it is not necessarily straightforward to fix. We will document the workarounds for this (using nomodeset, or the old GTK renderer) in the common bugs entry.
Can folks please test with this scratch build of mesa? https://koji.fedoraproject.org/koji/taskinfo?taskID=115518788 It includes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28414 , which upstream thinks should fix the problem. Thanks!
(In reply to Adam Williamson from comment #30) > Can folks please test with this scratch build of mesa? > https://koji.fedoraproject.org/koji/taskinfo?taskID=115518788 > > It includes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28414 > , which upstream thinks should fix the problem. Thanks! I can confirm that this build of mesa fixes the problem on both Raspberry Pi 4 and Pi 400.
(In reply to Adam Williamson from comment #30) > Can folks please test with this scratch build of mesa? > https://koji.fedoraproject.org/koji/taskinfo?taskID=115518788 > > It includes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28414 > , which upstream thinks should fix the problem. Thanks! I have been unable to test: https://bugzilla.redhat.com/show_bug.cgi?id=2272089 Is there some clever koji oneliner I can use to install that scratch build? I've been downloading the packages manually and installing.
oh, sorry, yes there is: koji download-task --arch=aarch64 --arch=noarch 115518788 dnf update *.rpm
(In reply to Adam Williamson from comment #33) > oh, sorry, yes there is: > > koji download-task --arch=aarch64 --arch=noarch 115518788 > dnf update *.rpm Thanks for that, a lot easier! I can confirm that build of mesa fixes the issue on my Pi 4b.
FEDORA-2024-1ac841849f (mesa-24.0.3-3.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ac841849f
FEDORA-2024-1ac841849f has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1ac841849f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ac841849f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6adf7226be has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6adf7226be` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6adf7226be See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6adf7226be (mesa-24.0.4-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Lukas Brabec from comment #5) > On Fedora-Workstation-40_Beta-1.8.aarch64, some GUI assets (e.g. UI icons in > nautilus, overly controls in loupe) won't load. > System booted with nomodeset doesn't have the issue. This happens both on > Raspberry Pi 4 and Pi 400. > It seems that this bug is present only in GTK 4 applications, firefox or > gnome-terminal works as expected. > > Journal is full of kernel v3d errors such as (see the attachment for > complete log): > Mar 19 12:07:38 fedora kernel: v3d fec00000.v3d: MMU error from client L2T > (0) at 0x179f7e00, pte invalid > These errors appear exactly the moment GTK 4 application is launched. > > Nautilus works as expected (all GUI assets are loaded) if launched using the > old gl renderer instead of the new ngl renderer: > $ GSK_RENDERER=gl nautilus The V3D Mesa fix to solve this particular MMU errors generated by the shaders of ngl GSK_RENDERER has landed upstream. https://gitlab.freedesktop.org/mesa/mesa/-/commit/97f5721bfc4bbbce5c3a39cf48eeb6ad1fb9cf97
Thanks for the heads up Chema, added your patch in https://src.fedoraproject.org/rpms/mesa/c/06834ca2a36064659ff3ac7bb29543653dc2cd11?branch=rawhide