You are not logged in.
Hello, i'm suffering from the same problem, and am trying to get the patched mesa version working, but it conflicts with a lot of packages, im not sure if i should remove mesa and all the packages that depend on it.
heres the output i get trying to install the patched mesa::: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and mesa-1:24.3.3-3 are in conflict. Remove mesa? [y/N] y :: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and vulkan-radeon-1:24.3.3-3 are in conflict. Remove vulkan-radeon? [y/N] y :: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and opencl-rusticl-mesa-1:24.3.3-3 are in conflict. Remove opencl-rusticl-mesa? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: removing opencl-rusticl-mesa breaks dependency 'opencl-rusticl-mesa' required by lib32-opencl-rusticl-mesa
Check if you have any package that depends on lib32-opencl-rusticl-mesa for uninstalling it.
And if you have some, check if you can replace lib32-opencl-rusticl-mesa with lib32-mesa.
Last edited by pacoandres (2025-01-21 20:35:47)
Offline
I have around 2 days total testing on Lone_Wolfs patched mesa 25 version below. It runs well with nothing unexpected to report.
mesa-test-git 25.0.0_devel.200085.94da1edbe49-1
I've also just clean chroot built the latest mesa-git version below using the default extra/llvm, and have switched to it.
mesa-git 25.0.0_devel.200505.bdd85c83937.d41d8cd-1
@Lone_Wolf, has the patch you added to mesa 25 been merged upstream yet?
If not, I'd expect this latest mesa-git to eventually crash.
Is it possible to track/watch that patch from the mesa gitlab page?
Last edited by NuSkool (2025-01-22 07:57:45)
Offline
mesa issue where patch is posted
The patch is not part of a MR as far as i know and won't be considered for adding to mesa trunk until it is.
Currently it's an unofficial out-of-tree 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
It looks a bit like mesa 24.3.4 is on the way to release...
Mesa push back the remaining 24.3.x releases by one week.
Offline
I left my system running overnight on the desktop with yesterdays build of mesa-git w/o patch.
mesa-git 25.0.0_devel.200505.bdd85c83937.d41d8cd-1
As expected it was near completely frozen this morning, not responding to keyboard input, did a hard reboot.
There was some interesting results in the journal this time. Hopefully something useful.... Search for 'Call Trace:'.
Journal: http://0x0.st/8XrC.txt
Thanks Lone_Wolf....
EDIT:
Looking at the patch, and see 'gfx9'....
Then looking at the output of 'AMD_DEBUG=info glxgears' I notice it 'has_gfx9_scissor_bug = 1' along with 7 additional '....bug = '...
I know absolutely nothing about any of this but it did get me thinking about a potential previous bug fix/workaround for our problematic hardware?
That said thinking result '1' would be false and '0' true, so my system doesn't have 'scissor_bug'? This was wrong, was thinking exit codes in bash.
Zero is used to represent false, and One is used to represent true.
.... rambling out loud ....
How to check if my system is 'gfx9' (in case the patch is working for other hardware)?
Maybe this?
$ sudo dmesg | grep gfx
...
[ 6.384416] [drm] add ip block number 6 <gfx_v9_0>
Last edited by NuSkool (2025-01-22 20:39:27)
Offline
xyznoobb wrote:Hello, i'm suffering from the same problem, and am trying to get the patched mesa version working, but it conflicts with a lot of packages, im not sure if i should remove mesa and all the packages that depend on it.
heres the output i get trying to install the patched mesa::: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and mesa-1:24.3.3-3 are in conflict. Remove mesa? [y/N] y :: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and vulkan-radeon-1:24.3.3-3 are in conflict. Remove vulkan-radeon? [y/N] y :: mesa-test-git-25.0.0_devel.200085.94da1edbe49-1 and opencl-rusticl-mesa-1:24.3.3-3 are in conflict. Remove opencl-rusticl-mesa? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: removing opencl-rusticl-mesa breaks dependency 'opencl-rusticl-mesa' required by lib32-opencl-rusticl-mesa
Check if you have any package that depends on lib32-opencl-rusticl-mesa for uninstalling it.
And if you have some, check if you can replace lib32-opencl-rusticl-mesa with lib32-mesa.
Alright, thanks. The patch is installed, and for now no errors. Thanks lonewolf you saved me so much suffering
Offline
How to check if my system is 'gfx9' (in case the patch is working for other hardware)?
Maybe this?$ sudo dmesg | grep gfx ... [ 6.384416] [drm] add ip block number 6 <gfx_v9_0>
That is a good way to confirm, my RX580 is gfx8 .
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
Test result
mesa-test-git-25.0.0_devel.200085.94da1edbe49-2-x86_64.pkg.tar.zst
I have to revise my last assumption that the mesa-test-git *without the patch* will not crash on my system, after it had been running stable for days. Why I did this test at all is explained further up.
The mesa-test-git now crashed after several days and about 48 hours of normal use.
In this respect, the strange experiences of @bernd_b are to be confirmed by me. Unfortunately, he is no longer writing here at the moment.
At least I now have some certainty.
I may also now understand even better why Pierre-Eric Pelloux-Prayer said not to be able to reproduce the error (...And I can't get a freeze on a 2700u, using a Mesa build at the problematic commit...).
It's good that users are now writing here who can cause the crash/freeze faster with their applications (Gimp, Blender, Steam, ...).
Perhaps these applications should be highlighted and reported even more so that the mesa developers can reproduce the error.
I am on mesa 1:24.3.4-1 now...
Offline
Test result
mesa-test-git-25.0.0_devel.200085.94da1edbe49-2-x86_64.pkg.tar.zstI have to revise my last assumption that the mesa-test-git *without the patch* will not crash on my system, after it had been running stable for days. Why I did this test at all is explained further up.
The mesa-test-git now crashed after several days and about 48 hours of normal use.In this respect, the strange experiences of @bernd_b are to be confirmed by me. Unfortunately, he is no longer writing here at the moment.
At least I now have some certainty.
I may also now understand even better why Pierre-Eric Pelloux-Prayer said not to be able to reproduce the error (...And I can't get a freeze on a 2700u, using a Mesa build at the problematic commit...).It's good that users are now writing here who can cause the crash/freeze faster with their applications (Gimp, Blender, Steam, ...).
Perhaps these applications should be highlighted and reported even more so that the mesa developers can reproduce the error.I am on mesa 1:24.3.4-1 now...
I can say that working with Android Studio and having Firefox or Chromium opened the 24.3.3 version, and the git unpatched and self-compiled version, freezes the system in less than one hour.
I've also checked my GPU and it's a gfx9. This is the dmesg output:
[ 7.344107] [drm] add ip block number 6 <gfx_v9_0>
With the patch, no freezes since Jan, 20.
Offline
Testing:
mesa 24.3.4
Linux 6.12.10-zen
GNOME, KDE
Ryzen 3 3200G Picasso Vega 8
gfx_v9_0
No crashes +8 hours with intense GPU/CPU loads.
The only way to ''crash'' is by manually entering
sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover
Which produces an error and forces you to log out. (GNOME) After a reboot session not crashes and it was recovered successfully.
Last edited by SnowF (2025-01-23 19:12:41)
Offline
Testing:
mesa 24.3.4
Linux 6.12.10-zen
GNOME, KDE
Ryzen 3 3200G Picasso Vega 8
gfx_v9_0
No crashes +8 hours with intense GPU/CPU loads.
The only way to ''crash'' is by manually entering
sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover
Which produces an error and forces you to log out. (GNOME)After a reboot session not crashes and it was recovered successfully.
That's good. With high probability we can expect the driver to work correctly for GFX 8/9.
Offline
No crashes +8 hours with intense GPU/CPU loads.
That's good. With high probability we can expect the driver to work correctly for GFX 8/9.
sorry no: as to be nearly expected, mesa 24.3.4-1 crashes within the first few hours with normal office applications, just like in every other version of 24.3.x...
Offline
No crashes +8 hours with intense GPU/CPU loads.
That's good. With high probability we can expect the driver to work correctly for GFX 8/9.
sorry no: as to be nearly expected, mesa 24.3.4-1 crashes within the first few hours with normal office applications, just like in every other version of 24.3.x...
I just spent a while testing in KDE (x11 & Wayland) and eventually there was a crash, unlike GNOME which did not experience any, neither in the most basic tasks, nor in the heaviest ones as it did before.
The crash occurs when resizing windows, this time it was on Steam with x11 and Brave with Wayland, just watching videos.
Offline
@orbit-oc
Thanks for the continued testing. It's good to see that confusing point be resolved. Please try the patched version and see how stable it is.
Offline
Well, after nearly four days running Lone_Wolf's patched mesa-test-git 25.0.0_devel.200085.94da1edbe49-1, the system froze while opening mpv, reisub didn't work this time, the logs as usual in my case have nothing but: amdgpu 0000:05:00.0: amdgpu: Dumping IP State.
I believe I'm the second person confirming a crash on patched mesa.
(AMD Ryzen 5 3400G)
EDIT: actually there was something new i the logs that I've never seen before
kernel: amdgpu 0000:05:00.0: amdgpu: failed to write reg 28b4 wait reg 28c6
Last edited by nek0panchi (2025-01-24 04:50:27)
Offline
@nek0panchi
You're the first I think, unless I missed a message. Sounds like more evidence that there's another bug. Try to find a reproducer?
Offline
@kclisp
I've been trying since I installed the patched version, but things that increased the chances of crashing the system in the unpatched versions like using gimp, firefox, and opening mpv, don't seem increase the chances anymore in the patched version.
Offline
Guys, I can't tell you how fed up I am.
After the code of conduct, the exclusion of Russian kernel developers and now this week-long mesa-disaster, the reputation of Linux will be tarnished in a way that will be remembered for years. At least if they don't hurry now, because the majority of users with the more conservative distributions are not yet affected.
‘Waiting for Godot’ is not a good thing in the long run. I will probably take a break now, continue reading here and think about whether and how I will have to switch. My system isn't just a tinkering corner, it's also intended for completing tasks.
‘Shut the fuck up and buy new hardware’
Bill Gates
The hell I won't...
Last edited by orbit-oc (2025-01-24 09:59:52)
Offline
For all we can tell this isn't a kernel issue nor political so you're smashing unrelated things together.
Speaking of political and CoC you may want to check ours, but it's not like Linus had any choice here and there's obviously exactly one individual on the planet who can just accept that your dick breaks when you're getting old, the evil west sends him some viagra and we can all have normal relations again.
I will agree though that the kernel quality was higher when Linus was swearing his opinions unfiltered - and from the sideline it was also very entertaining
Offline
Guys, I can't tell you how fed up I am.
After the code of conduct, the exclusion of Russian kernel developers and now this week-long mesa-disaster, the reputation of Linux will be tarnished in a way that will be remembered for years. At least if they don't hurry now, because the majority of users with the more conservative distributions are not yet affected.
Thanks for your words, these - or similar words - came also into my mind. And that's another thing: thinking loud these things are "political incorrect"
Obey our words! And buy new Hardware...
Offline
Please try to stick to the topic, and keep the conspiracy theories in your head: https://terms.archlinux.org/docs/code-o … ial-topics
Offline
Guys, I can't tell you how fed up I am.
After the code of conduct, the exclusion of Russian kernel developers and now this week-long mesa-disaster, the reputation of Linux will be tarnished in a way that will be remembered for years. At least if they don't hurry now, because the majority of users with the more conservative distributions are not yet affected.‘Waiting for Godot’ is not a good thing in the long run. I will probably take a break now, continue reading here and think about whether and how I will have to switch. My system isn't just a tinkering corner, it's also intended for completing tasks.
‘Shut the fuck up and buy new hardware’
Bill Gates
The hell I won't...
What? They really excluded Russian developers? Now that's pathetic..., not to mention it's xenophobic or add your own thing here, those people need a brain/reality check.
Aside from that, mesa 1:24.3.4-1, Blender + Firefox, crashes happen quite often on 3400G, if it's of any relevance, 32GB RAM, integrated memory reserved 64MB (I think, minimum board allows).
Offline
A bunch of developers were taken from the maintainer list because they work for companies that are under sanction for unrelated global events that are completely out of the kernel maintainers control. This was in the news, maybe get off social media for your world view.
This is however completely unrelated to mesa having a bug or Linus having agreed to no longer rant at people - and having an opinion on any of that isn't "politically incorrect" but simply vastly off topic.
Speaking of which, what's the status quo here?
The patched build provided by Lone_Wolf solves some problem but not all?
Do the remainders get the same backtraces or are they now different?
Offline
Speaking of which, what's the status quo here?
The patched build provided by Lone_Wolf solves some problem but not all?
It can still crash from this post, but i think that's the first case i've seen reported:
https://bbs.archlinux.org/viewtopic.php … 4#p2222164
But it's by far the most stable solution we have for now, mine has been running for 15 hours and i use mpv a lot and constantly spawn new windows.
With 24.3 i would never make it past one hour without crashing.
Last edited by pacmancrashedagain (2025-01-24 14:32:52)
Offline
Why mesa-test-git 25.0.0 without patch *won't* crash for me and @bernd_b in the past is another question.
I have nothing new to add, but to clarify:
my mesa-git from AUR did(!) crash, although it took much longer (not only max a few hours) until it occurred.
After the crash, I went back to an own built of 24.2.8 to verify that mesa is really the culprit. mesa-24.2.8 didn't let me down for days until now.
I just switched to 24.3.4 from the repo, but as I just read, it is unlikely that I will have luck with this one.
Offline