You are not logged in.
Since Firefox 146, I have regular crashes if I play video with enabled hardware acceleration.
Disabling hardware acceleration makes Firefox stable, again, but puts more stress on my CPU.
The crash dump has "some traces of mesa" in it, so maybe it's driver related?
The GPU is the one built into my Intel CPU.
Any chance to narrow this down?
Probably I'll try a mesa downgrade, next, to check if this fixes it.
Offline
After updating mesa above version 25.2.7, Firefox also started to crash. I've rolled back for now and I'm keeping version 25.2.7.
Offline
So this at least confirms that it may have something to do with mesa. Unfortunately, I have t run video for several minutes to trigger the crash. So any "debugging" would be pretty time consuming.
Someone else with similar experience?
Offline
Same issue here. Downgrading mesa solved the problem.
P.S. I've got already three downgraded packages on my machine. It's becoming ridiculous. Seems, Arch slowly but steadily is going to hell.
:: Starting full system upgrade...
warning: gdk-pixbuf2: ignoring package upgrade (2.44.1-3 => 2.44.4-1)
warning: librsvg: ignoring package upgrade (2:2.61.1-1 => 2:2.61.3-1)
warning: mesa: ignoring package upgrade (1:25.2.7-1 => 1:25.3.1-2)
P.P.S For the last several months I've also got several hard freezes for no reason that never happened years and years before.
What's the heck is going on? lol
Quality of software or OS is getting lower and lower.
For the same reason I returned to pulseaudio because the new kernels (> 6.12) made using pipewire unbearable.
I like Arch and I've been using it since 2009. And it's very sad what's happening. Who to blame? Hell knows.
Last edited by qwer1234 (2025-12-13 05:22:06)
Offline
For the gdk-pixbuf2 situation you'll probably have to migrate away from using it.
Upstream seems dead-set on that slapstick and holding old packages will at some point no longer be an option and even the -noglyin builds in the AUR might at some point become unreasonable to maintain.
Mesa is probably just a bug, a backtrace might be useful.
You're getting the hard freezes despite or because of using an old kernel? Zen?
But generally please open new threads for that and the pipewire situation and keep the focus here on FF/mesa
Offline
About 2 monthes ago firefox started needing ffmpeg4.4 instead ffmpeg. I had firefox crashes with ffmpeg.
Now it doesn't need ffmpeg4.4 anymore and crashes are back.
Maybe ffmpeg crashes firefox.
Offline
a backtrace might be useful
Offline
seth wrote:a backtrace might be useful
Can you please point me to some instructions on how to create one?
I would create a new, fresh, Firefox profile just for this test, to be sure nothing like Add-ons or settings are causing this.
Should take less than half an hour to get a crash. They are pretty consistent for me.
Edit: Or are the Firefox crash dumps helpful here? If so, then I can upload one somewhere.
Last edited by M-Reimer (2025-12-13 17:19:02)
Offline
https://wiki.archlinux.org/title/Core_d … _core_dump
Also open "about:crashes" in firefox
Offline
From about:crashes (not OP, but having very frequent crashes lately)
0 libgallium-25.3.1-arch1.2.so crocus_mocs /usr/src/debug/mesa/mesa-25.3.1/src/gallium/drivers/crocus/crocus_resource.h:303 inlined
0 libgallium-25.3.1-arch1.2.so emit_vertex_buffer_state /usr/src/debug/mesa/mesa-25.3.1/src/gallium/drivers/crocus/crocus_state.c:5855 context
1 libgallium-25.3.1-arch1.2.so crocus_upload_dirty_render_state /usr/src/debug/mesa/mesa-25.3.1/src/gallium/drivers/crocus/crocus_state.c:7622 cfi
2 libgallium-25.3.1-arch1.2.so crocus_upload_render_state /usr/src/debug/mesa/mesa-25.3.1/src/gallium/drivers/crocus/crocus_state.c:7816 cfi
3 libgallium-25.3.1-arch1.2.so crocus_simple_draw_vbo /usr/src/debug/mesa/mesa-25.3.1/src/gallium/drivers/crocus/crocus_draw.c:332 inlined
Seems indeed mesa-related. I found a few discussions of similar issues in other distros' discussion boards, but no mesa or firefox bug.
Offline
lspcicrocus is a driver for old intel chips - do you get better performance w/ mesa-amber and i965 ?
Offline
[joel@panda ~]$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Desktop SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 06)
I have a very old computer, should I really try the new stuff?
Offline
I read up on mesa-amber and I got it, it's the legacy non-gallium driver for these chips. I've installed it and will use it for a while, and report back. Thank you!
Offline
That's probably the cleanest dump, I can get. New user profile extra for this test with a completely unmodified Firefox profile. Was watching some random twitch stream until the crash happened:
Offline
Yeah, I also use the crocus driver on old hardware.
Crocus works great (except the current mesa). So there is no need to use mesa-amber.
I switched to xLibre as well. Works great. And no need of picom anymore to eliminate screen tearing. Without picom everything works much faster with much lower temperatures.
So recommend everybody to switch to xLibre.
The only issue is gtk4 applications. Without a compositor gtk4 applications have ugly shadows. But if you are ok with it, using xLibre without a compositor adds more power to your old hardware.
Last edited by qwer1234 (2025-12-14 13:21:04)
Offline
OK, I've been using mesa-amber for a few hours without any crashes. Probably going to stay on that for a while. Thanks @seth!
Offline
@M-Reimer you're also in the crocus camp => try mesa-amber
---- OFF TOPIC ----
@qwer12345
Crocus works great (except the current mesa).
The "current mesa" /is/ crocus - and apparently r/n there's a bug in the crocus driver…
You may or not also wanna test whether you're getting generally better performance out of i965
afaiu w/ xlibre you probably got the tearfree patch for the modesetting driver (though w/ HW this old you can also test the intel driver which had that feature for i965)
wrt gtk4 you can look around to adapt https://wiki.archlinux.org/title/GTK#Cl … ecorations or test https://aur.archlinux.org/packages/gtk-nocsd-git
Offline
you can also test the intel driver which had that feature for i965)
I tried it several years ago. The Intel driver was causing random xorg freezes. Then I switched to modesetting. And zero problems after that. Also in the wiki it's recommended not to use the Intel driver anymore.
The mesa-amber also had some minor issues - don't remember what exactly. So crocus was an excellent option until recently. So I suggest everybody just downgrade the package and wait until a newer working version.
In gtk4 applications I mean this issue:
I tried your suggestions - they don't solve the issue.
gtk4 applications need a compositor but it takes too much resources from the old machines especially while watching YouTube, for example.
So the ideal solution is xLibre without a compositor like picom + modesetting + crocus.
No screen tearing and everything works with maximum speed.
And I use just a tiling window manager without any DE.
It was a super stable solution until recently. Maybe until vibe coding took place. lol
Last edited by qwer1234 (2025-12-14 17:41:13)
Offline
Looks like its already been fixed and merged: https://gitlab.freedesktop.org/mesa/mes … 1b71211b85 . Dont know when it will be added to release. You can always test this with mesa-git repo or aur.
Offline
Main patch is https://gitlab.freedesktop.org/robclark … b0a12584eb
Offline
Was just gonna post that I have an old Intel CPU and had the same problem and mesa-amber fixed it. Glad to see it's already fixed upstream
Offline
Same issue here (actually just join the forum to see if I was the only one), right now just using mesa-amber, the legacy driver compatible with my old Intel HD Graphics 3000 of the Sandy Bridge era is available, it looks like it's not affected. Doing some research just found this pull request that should be release upstream in a few days. Hopefully everything will work after Archlinux update the package with the latest upstream mesa that include this patch.
My kingdom is not from this world.
Offline
Just tested the new mesa package from testing. Seems they fixed the issue.
Offline
Just tested the new mesa package from testing. Seems they fixed the issue.
Excellent news ?
My kingdom is not from this world.
Offline