Bug 2269412 - Raspberry Pi 4/400: some GUI assets won't load
Summary: Raspberry Pi 4/400: some GUI assets won't load
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 40
Hardware: aarch64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://discussion.fe...
Depends On:
Blocks: F40FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2024-03-13 18:45 UTC by Brandon Nielsen
Modified: 2024-04-16 14:03 UTC (History)
36 users (show)

Fixed In Version: mesa-24.0.4-1.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-04-02 14:17:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Missing decoration in gnome-software (22.46 KB, image/png)
2024-03-13 18:45 UTC, Brandon Nielsen
no flags Details
Missing decorations in title bar and sidebar of nautilus (35.74 KB, image/png)
2024-03-13 18:46 UTC, Brandon Nielsen
no flags Details
More missing decorations in gnome-software (21.28 KB, image/png)
2024-03-13 18:47 UTC, Brandon Nielsen
no flags Details
journalctl -b (1.77 MB, text/plain)
2024-03-19 11:30 UTC, Lukas Brabec
no flags Details


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab mesa mesa issues 10853 0 None opened Issues rendering gtk4 window decorations on v3d on Fedora-40/mesa-24.0 2024-03-20 09:03:30 UTC
freedesktop.org Gitlab mesa mesa merge_requests 28414 0 None opened Draft: v3d: fix GFXH-930 workaround 2024-03-27 17:29:57 UTC

Description Brandon Nielsen 2024-03-13 18:45:27 UTC
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.

Comment 1 Fedora Admin user for bugzilla script actions 2024-03-13 18:45:36 UTC
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!

Comment 2 Brandon Nielsen 2024-03-13 18:45:59 UTC
Created attachment 2021469 [details]
Missing decoration in gnome-software

Comment 3 Brandon Nielsen 2024-03-13 18:46:35 UTC
Created attachment 2021470 [details]
Missing decorations in title bar and sidebar of nautilus

Comment 4 Brandon Nielsen 2024-03-13 18:47:01 UTC
Created attachment 2021471 [details]
More missing decorations in gnome-software

Comment 5 Lukas Brabec 2024-03-19 11:29:40 UTC
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

Comment 6 Lukas Brabec 2024-03-19 11:30:36 UTC
Created attachment 2022521 [details]
journalctl -b

Comment 7 Lukas Brabec 2024-03-19 11:35:25 UTC
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

Comment 8 Fedora Blocker Bugs Application 2024-03-19 11:47:55 UTC
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).

Comment 9 Peter Robinson 2024-03-19 13:09:46 UTC
Can you give me the output of "dmesg |grep Memory"

Comment 10 Lukas Brabec 2024-03-19 13:44:46 UTC
$ 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.

Comment 11 Peter Robinson 2024-03-19 13:48:45 UTC
In /boot/efi/config.txt can you update the dtoverlay=cma,cma-256 line to dtoverlay=cma,cma-512 and see if that helps

Comment 12 Peter Robinson 2024-03-19 13:50:27 UTC
> 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.

Comment 13 Lukas Brabec 2024-03-19 14:02:14 UTC
(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

Comment 14 Peter Robinson 2024-03-19 14:23:24 UTC
Did the "262144K cma-reserved" line update to 512Mb?

I think this is a mesa issue.

Comment 15 Peter Robinson 2024-03-19 14:26:50 UTC
Would also be useful to know how KDE and other desktops fare

Comment 16 Adam Williamson 2024-03-19 14:54:55 UTC
Was this broken (on Pi 4b, obviously, since Pi 400 was untestable) with earlier Beta candidates? Say, check 1.2 and 1.7?

Comment 17 Peter Robinson 2024-03-19 15:00:02 UTC
(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?

Comment 18 Brandon Nielsen 2024-03-19 16:00:45 UTC
(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.

Comment 19 Adam Williamson 2024-03-19 16:03:59 UTC
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...

Comment 20 Brandon Nielsen 2024-03-19 16:11:20 UTC
(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.

Comment 21 Brandon Nielsen 2024-03-19 18:52:57 UTC
(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.

Comment 22 Peter Robinson 2024-03-19 18:57:02 UTC
> 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.

Comment 23 Peter Robinson 2024-03-20 09:03:31 UTC
Confirmed mesa, filed upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10853

Comment 24 Peter Robinson 2024-03-20 09:19:40 UTC
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

Comment 25 Lukas Brabec 2024-03-20 11:58:08 UTC
(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

Comment 26 Peter Robinson 2024-03-20 12:01:42 UTC
*** Bug 2270430 has been marked as a duplicate of this bug. ***

Comment 27 Adam Williamson 2024-03-20 17:30:32 UTC
+3 blocker in https://pagure.io/fedora-qa/blocker-review/issue/1534 , so marking accepted. We may well ultimately waive this for Beta, though.

Comment 28 Adam Williamson 2024-03-21 15:40:26 UTC
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.

Comment 29 Adam Williamson 2024-03-21 21:54:14 UTC
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.

Comment 30 Adam Williamson 2024-03-27 17:29:30 UTC
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!

Comment 31 Lukas Brabec 2024-03-28 09:44:57 UTC
(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.

Comment 32 Brandon Nielsen 2024-03-28 18:36:58 UTC
(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.

Comment 33 Adam Williamson 2024-03-28 18:57:51 UTC
oh, sorry, yes there is:

koji download-task --arch=aarch64 --arch=noarch 115518788
dnf update *.rpm

Comment 34 Brandon Nielsen 2024-03-28 21:13:04 UTC
(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.

Comment 35 Fedora Update System 2024-03-28 22:08:46 UTC
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

Comment 36 Fedora Update System 2024-03-29 02:55:34 UTC
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.

Comment 37 Fedora Update System 2024-04-02 02:09:18 UTC
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.

Comment 38 Fedora Update System 2024-04-02 14:17:50 UTC
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.

Comment 39 Chema Casanova 2024-04-16 11:40:07 UTC
(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

Comment 40 José Expósito 2024-04-16 14:03:58 UTC
Thanks for the heads up Chema, added your patch in https://src.fedoraproject.org/rpms/mesa/c/06834ca2a36064659ff3ac7bb29543653dc2cd11?branch=rawhide


Note You need to log in before you can comment on or make changes to this bug.