I believe this is causing firefox crashes on Asahi

https://gitlab.freedesktop.org/mesa/mesa/-/issues/14309

There are more reports of crashing firefoxes (on Arch with Intel graphics): https://gitlab.freedesktop.org/mesa/mesa/-/issues/14312

NixOS user with AMD graphics: https://crash-stats.mozilla.org/report/index/b0976a91-66ae-47ce-80b4-a64620251118

OpenSuse user with Intel graphics: https://crash-stats.mozilla.org/report/index/4fcdbf88-a682-4f0f-b2fa-a8cd50251117

And 82 crashes from (based on RAM size at least 3 distinct) NixOS Asahi users.

After all, upstream wrote as usual

Mesa 25.3.0 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 25.3.1.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/gnome-flickers-and-unresponsiveness-after-an-upgrade-to-kernel-version-6-17-8/72218/9

I don't know. This mesa update seems problematic for some people (e.g. another case here) and we're supposed to ship a stable NixOS 25.11 within a week. Maybe we go back to 25.2.x for now?

I'm going to talk to upstream, but I'm down to revert to 25.2 on 25.11 if it doesn't get fixed quickly.

One week after reporting the issue upstream, I see that more users (and device types) are affected, but no attempt for a fix yet.

That crash signature is unfortunately very incomplete so it will count every single Mesa crash. That said, I think we may have to revert, unless someone steps up to investigate this upstream, because the person who wrote the original change is on vacation...

Could these have also been caused by the gtk4 bug which got fixed in nixpkgs in the meantime?

No, Firefox is GTK3.

The cause on Asahi / Crocus / Freedreno is well identified and documented. It's commit https://gitlab.freedesktop.org/mesa/mesa/-/commit/b3133e250e1c40496d98c4ba52386b7ae423d194 / merge request https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296.

The offending commit is known, what is not known is why it's causing issues and how to fix them without reintroducing the overhead the original series was attempting to address.

Generally I'd expect to revert such a commit until more is known, but I don't know mesa's codebase and workflows in particular...

Just reverting that commit without context is extremely unlikely to work.

That crash signature is unfortunately very incomplete so it will count every single Mesa crash.

Basically true, except we have some very good clues: Looking at the list of libgalium-25.2.6.so & libgallium-25.2.7.so, I only see a single crash (1 of 147) dereferencing the jemalloc poison address (0xe5e5e5e5e5e5e5e5). Most are null pointer derefs.

Meanwhile in the list of crashes with libgallium-25.3.0.so signature I see 585/632 or 92.6% with the jemalloc poison address (which all the reports of the crash, investigated by 3 distinct people had in common).

Just reverting that commit without context is extremely unlikely to work.

Why is that? The merge request makes it sound like a performance improvement / fix. Reverting to the old behavior of re-adding refcounting to those buffers until someone can re-do the change properly would make a lot of sense to me (except of course it doesn't cleanly revert, because 2 months of development happened since this wide-ranging change).

Because future changes in the drivers already depend on newer APIs introduced by this change.

NixOS 25.11 release should happen quite soon, and I haven't noticed much progress, so we now revert to mesa 25.2.x on release-25.11, right?

And I'm not sure about 25.2.7, as regressions were reported with it on Fedora and they had to backport some fixes.

Inexperienced user here. Mesa 25.3.0 destabilized my GNOME until gtk4 was upgraded to 4.20.3. My GNOME has been rock solid since then.

I might be late for release announcement, but opened
#466009