You are not logged in.
@Lone_Wolf
Thanks again for the builds - mesa-test-git 25.0.0_devel.200085.94da1edbe49-1 seems fine! It may be worth doing a trunk build without the patch to isolate that it's the patch that fixes it?
Online
Good idea, 94da1edbe49 without patch .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks. mesa-test-git 25.0.0_devel.200085.94da1edbe49-2 is indeed still broken.
Online
Any chance of providing a download link for mesa-test-git 25.0.0_devel.200085.94da1edbe49-1?
Offline
Post #131 has it, but here it is again
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
To clarify, I would like to emphasize once again that mesa-test-git 25.0.0 from posting #131 was not broken when @bernd_b used it. He still uses mesa-git in his own build without a patch. Unfortunately, he did not explicitly confirm my request in posting #127.
For myself, this test had passed about 12 hours without crashing, which was not the case with any other release since 24.3.x.
With the current version 24.3.3-2 I can work for about 4 hours.
After another test of the upcoming mesa 24.3.4 *under normal conditions*, I will switch to 'mesa-test-git 25.0.0_devel.200085.94da1edbe49-2 (without patch)' in case of persistent crashes and then probably stay there until the next release.
Thanks again to @Lone_Wolf
Offline
To clarify, I would like to emphasize once again that mesa-test-git 25.0.0 from posting #131 was not broken when @bernd_b used it. He still uses mesa-git in his own build without a patch. Unfortunately, he did not explicitly confirm my request in posting #127.
Yes, sorry for this. My silence is because of me loosing track in this matter.
The mesa-git version I used seemed very stable to me, but now I count two freezes during the last few days. That's way better than with other 24.3.x-Versions, but shouldn't happen. Of course, who knows if there is not another problem on my pc teasing me?
The freezes happen out of the blue. I can hardly move the mouse pointer (very, very slow reaction) but no input is accepted and the keyboard doesn't react at all. Unfortunately, I cannot reproduce them.
To make things worse:
Doing the "cat /sys/kernel/debug/dri/0/amdgpu_gpu_recover" recover thing, I get a black screen and a frozen keyboard with all version, the git I used and "stable" 24.2.8 which I compiled using the pkgbuild-Files from the repo.
Last edited by bernd_b (Today 09:12:11)
Offline
@bernd_b
That makes things a bit complicated. @Mechanicus had asked to run the gpu reset, but afterwards (hours later) I also got a crash like the one you described, which resulted from it (mesa 24.2.7-1).
The question now is whether you perform this command *before* your crash or after. If before, then the version you are using all the time is not *necessarily* corrupt.
That's why I'm only testing the last few meters under normal conditions until a decision (mine) or clarification (mesa) is made.
I kindly ask for further feedback. Sorry for that.
Last edited by orbit-oc (Today 09:39:40)
Offline
As I said, I lost track.
I did "cat /sys/kernel/debug/dri/0/amdgpu_gpu_recover" command after a reboot because I thought it to be a method which may can reproduce these mysterious crashes.
I gladly deliver every information I can, but I try to prevent to add any further confusion.
Offline
...if 24.2.8 also suddenly crashes, then I would be confused too...
Your builds run for days and then suddenly crash? Never without any change i think.
Thanks @bernd_b
Offline
Guys, I think there's a correlation between AGESA versions and crashes. Yesterday I've updated motherboard firmware to the latest UEFI with AGESA ComboV2PI 1.2.0.Cc, since then I did not experience any crashes (I will update my post if they happen with "EDIT:").
What's interesting, is that on this particular motherboard (ASUS A520M-K) with 3400G I had UEFI with AGESA version ComboV2PI 1.2.0.B and I did experience quite frequent crashes. On another motherboard (ASUS A320M-K) with 3200G I had UEFI with AGESA version ComboV2PI 1.2.0.Ca and did experience far less frequent crashes. Both with same amount/speed/timings of RAM. Hence why I will update the post if it happens with AGESA ComboV2PI 1.2.0.Cc.
Since upgrading motherboard firmware is kinda risky stuff and unrealistic for some users where manufacturers tend to not update older products, the issue still needs to be addressed, but at least it seems there's correlation between AGESA versions and crashes frequency.
Offline
AGESA
see in this context also Posting #10 and #12
thanks to @lpr1
Offline
Just to clarify: my Raven Ridge system with AMD AM4 AGESA Combo V2 PI 1.2.0.Cc experienced freezes with Google Chrome with mesa 1:24.3.3 and llvm-libs 18. After update to llvm-libs-19 at least there is no more crashes with Google Chrome so far. But the crash can be manually triggered by accessing amdgpu_gpu_recover. I can't confirm that the system is rock-solid because that machine is used for light tasks only.
Offline
For one of you who experienced the crash starting from mesa-24.2.8 - check the changes Compare revisions 24.2.8...24.2.7
You can try to build 24.2.8 branch without this commit https://gitlab.freedesktop.org/mesa/mes … 1126daae2b and test. Or disable mesa shader cache via environment variable to isolate related changes.
Last edited by Mechanicus (Today 11:26:37)
Offline
AGESA
see in this context also Posting #10 and #12
thanks to @lpr1
Ye, from what was said in post #12 "The BIOS update to a new AGESA version has significantly extended this period longer again, but did not prevent the system from freezing again, as feared.", still that's on the Ca version, however, considering @Mechanicus is at the same Cc version, it might be that Cc extends the period even more than Ca, or maybe even completely resolves the issue, and the issue with gpu reset he experience might be unrelated issue to this one.
Time will tell, so far, no crashes, but as soon as I get one I will update previous post.
Last edited by lpr1 (Today 12:02:29)
Offline
Your builds run for days and then suddenly crash? Never without any change i think.
The git-build yes. Maybe not days, but about every second.
The 24.2.8 build runs for some hours up to now on my pc. For now, nothing new to report.
Offline
Hey, I make my small contribution to the problem and how I solved it.
Running 6.12.9-zen1-1-zen.
Ryzen 3 3200G (Vega 8).
AsRock B450M-HDV R4.0 (lastest BIOS).
I'll tell you how it started and then I'll continue with the solution.
My experience with KDE, GNOME, Hyprland was the same.
Every time I maximized, moved or resized a window the CPU went through the roof, and eventually crashed the entire system, sometimes the mouse continued to respond, other times it didn't.
I Downgrade and bring everything to previous versions of Vulkan, Mesa and their dependencies.
mesa lib32-mesa vulkan-radeon lib32-vulkan-radeon vulkan-mesa-layers lib32-vulkan-intel lib32-vulkan-mesa-layers vulkan-intel vulkan-swrast
Which in my case (and it's been a week now) worked for me is
24.2.7
(In the case of lib32-llvm-libs I use version 18.1.8-1 and llvm-libs 18.1.8-5)
I hope to help someone in the future or that this is solved quickly, it was 3 months of pure crash and dystrohoping until I found the solution which was very stupid. Cheers!
Last edited by SnowF (Today 15:05:42)
Offline
Hey, I make my small contribution to the problem and how I solved it.
Running 6.12.9-zen1-1-zen.
Ryzen 3 3200G (Vega 8).
AsRock B450M-HDV R4.0 (lastest BIOS).
I'll tell you how it started and then I'll continue with the solution.
My experience with KDE, GNOME, Hyprland was the same.
Every time I maximized, moved or resized a window the CPU went through the roof, and eventually crashed the entire system, sometimes the mouse continued to respond, other times it didn't.
I Downgrade and bring everything to previous versions of Vulkan, Mesa and their dependencies.
mesa lib32-mesa vulkan-radeon lib32-vulkan-radeon vulkan-mesa-layers lib32-vulkan-intel lib32-vulkan-mesa-layers vulkan-intel vulkan-swrast
Which in my case (and it's been a week now) worked for me is
24.2.7
(In the case of lib32-llvm-libs I use version 18.1.8-1 and llvm-libs 18.1.8-5)
I hope to help someone in the future or that this is solved quickly, it was 3 months of pure crash and dystrohoping until I found the solution which was very stupid. Cheers!
Have you tried the same but with mesa shader cache disabled?
Offline
@SnowF
Thanks for the hint, but we already have this pre-solution since 15.12.2024. See Posting#2:
https://bbs.archlinux.org/viewtopic.php … 9#p2214479
Offline
(In the case of lib32-llvm-libs I use version 18.1.8-1 and llvm-libs 18.1.8-5)
And by doing that, you've just broken a whole lot of other things. DO NOT DO THIS.
Offline
I Downgrade and bring everything to previous versions of Vulkan, Mesa and their dependencies.!
Maybe i'm missing some fringe case but i don't think you need vulkan-intel when you are using an AMD apu.
Online
Have you tried the same but with mesa shader cache disabled?
Yes, it lasted 1 day and the next restart using Brave crashed.
@orbit-oc
Yeah.. but no.
I also tried to just downgrade to mesa and vulkan-radeon, but when its dependencies were updated the crashes came back.
@Scimmia
No, for a week now everything has been going too well. Previously, when those two mentioned packages were updated, they caused the system to not start, so I returned them to that version that I mentioned.
@pacmancrashedagain
I think the mesa/vulkan package comes with them by default regardless of whether you have an Intel GPU or not. Just in case I left it there.
Offline
Mechanicus wrote:Have you tried the same but with mesa shader cache disabled?
Yes, it lasted 1 day and the next restart using Brave crashed.
Good results. I guess you didn't clean shader cache inside Brave user profile directories before using it second time? I mean in folders like ~/.config/google-chrome-beta/Default/GPUCache/ for Google Chrome.
Offline
SmillerMP wrote:Hi I'm new to the forum, I've also been experiencing freezing issues with mesa 24.3.x, I have a ryzen 5 3400g,
I recently saw that a recent update of some package on my system breaks the login and the login is recovered after updating mesa and libmesa
so waiting on mesa 24.2.7, it may start to cause a problem.I don't have such deep experience with arch, but I'm here to help in any way I can.
Could you please also add export MESA_SHADER_CACHE_DISABLE=true to your ~/.bashrc, clean ~/.cache directory after reboot and try to do what you usually do when the system freezes?
Use the latest mesa for sure.
I did this and the system crashed 3 hours after the update, even after clearing all cache, mesa version 24.3.3
Offline
[
@Scimmia
No, for a week now everything has been going too well. Previously, when those two mentioned packages were updated, they caused the system to not start, so I returned them to that version that I mentioned.
Really? Tried running rust? clang? postgresql? blender? a whole bunch of other things that are linked to the new lib? You have done a serious partial update, and your system is in a completely unsupported and unsupportable state.
I'll point you to https://bbs.archlinux.org/viewtopic.php … 0#p2219910 for the right way to handle this, downgrading a bunch of things is NOT it.
Last edited by Scimmia (Today 21:03:39)
Offline