You are not logged in.
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.
Isn't it simpler just to switch to mesa-amber for a while? No conflicts, just install mesa-amber and it`ll replace the mesa package.
Online
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.
Yes, that's the same behavior that I saw with the original freezes. So trunk probably still has the bug. Can you test with Lone_Wolf's most recent trunk build without patch so that we're consistent with our builds (everyone who wants to help should test this as well)? Because the freezes seem somewhat random, we'll have to test for a lot longer than the expected time for a freeze in order to be confident in the build's stability.
I'll continue testing with the patched version to help isolate the freeze cause if I encounter one.
Offline
@Mechanicus There might not be any conflicts, but it took about a minute from starting X for my wallpaper to appear, and the rest of my desktop never actually did, so I'm not sure mesa-amber is a viable solution on this hardware (3200g like a couple others).
Offline
Scimmia wrote: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.
Isn't it simpler just to switch to mesa-amber for a while? No conflicts, just install mesa-amber and it`ll replace the mesa package.
Do you know where hardware support for the radeon non-gallium driver stopped? I don't. If your card is newer, that would just switch you to software rendering, which isn't a good option.
Offline
After what @bernd_b recently said, I can understand @kclisp's suggestion to test the mesa-test-git 25.0.0 without the patch again, as the situation has now become even more confusing.
Even without @kclisp's suggestion, I had already considered this.
In post #156 I had also decided to use this test-git after testing the overdue release 24.3.4, *also* to make sure whether it works or not.
Maybe I will actually do this beforehand. It also depends on whether 24.3.4 is released in the next few hours or not...
by the way: mesa 24.3.3-2 is running almost the best for me so far. It has only crashed once up to now...
Last edited by orbit-oc (2025-01-17 23:09:20)
Offline
by the way: mesa 24.3.3-2 is running almost the best for me so far. It has only crashed once up to now...
Sorry orbit-oc, i've lost track with all the different versions and patches going around, this is the version from the repos without any modifications at all?
Online
@pacmancrashedagain
Yes, I mean the current version of the official repository...
Offline
Unfortunately, I'm lost with troubleshooting at this point. Fortunately there are more knowledgeable people here than myself testing and reporting results...
It's also looking like a fix could be quite a while down the road. That in mind I rolled up my sleeves and rebuild the repo version of mesa against the current packages.
I'm running it now and it passed the 'glxinfo -B' and 'vainfo' tests.
In case others may find this useful or would provide feedback if I obviously f##ked up somewhere, I'll provide the build process I used.
It took about 20 min to build on my system.
git clone https://gitlab.archlinux.org/archlinux/packaging/packages/mesa.git
Rename: PKGBUILD-bu and .SRCINFO-bu
Used my git-rollback script to make this selection:
commit 825be1410117ed165a6eee7a11e3a3e3cce2ae4b
Author: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Date: Wed Nov 13 18:25:53 2024 +0100
1:24.2.7-1: Unsplit vdpau/vaapi drivers
They are part of libgallium and only symlinks remain.
.SRCINFO
PKGBUILD
Recreate files needed:
$ git cat-file -p 825be1410117ed165a6eee7a11e3a3e3cce2ae4b:./.SRCINFO > .SRCINFO
$ git cat-file -p 825be1410117ed165a6eee7a11e3a3e3cce2ae4b:./PKGBUILD > PKGBUILD
Verify PKGBUILD version '24.2.7' and edit: 'pkgrel=2' to differentiate it from my cached version mesa 1:24.2.7-1
Use a script to fetch a PGP key:
$ aurt -pgp 8D8E31AFC32428A6
Used devtools script to clean chroot build the package.
$ pkgctl build
And the build output: http://0x0.st/8HrS.txt
Would it be correct to assume a rebuild required whenever libva updates? Anything else I should be aware of?
EDIT:
Any advise or info on the soname warnings in the output?
Would symlinks be a possible bandaid for whatever programs/packages may need them?
==> Running checkpkg
-> Checking packages
> usr/lib/bellagio/
> usr/lib/bellagio/libomx_mesa.so
usr/lib/gbm/ <
usr/lib/gbm/dri_gbm.so <
usr/lib/libgallium-24.3.3-arch1.2.so | usr/lib/libgallium-24.2.7-arch1.2.so
==> WARNING: Sonames differ in mesa!
dri_gbm.so=dri_gbm.so-64 <
libgallium-24.3.3-arch1.2.so=libgallium-24.3.3-arch1.2.so-64 | libgallium-24.2.7-arch1.2.so=libgallium-24.2.7-arch1.2.so-64
> libomx_mesa.so=libomx_mesa.so-64
==> No soname differences for opencl-clover-mesa.
==> No soname differences for opencl-rusticl-mesa.
==> No soname differences for vulkan-intel.
usr/bin/mesa-screenshot-control.py <
usr/lib/libVkLayer_MESA_screenshot.so <
usr/share/vulkan/explicit_layer.d/VkLayer_MESA_screenshot.json <
==> WARNING: Sonames differ in vulkan-mesa-layers!
libVkLayer_MESA_screenshot.so=libVkLayer_MESA_screenshot.so-6 <
==> No soname differences for vulkan-nouveau.
==> No soname differences for vulkan-radeon.
==> No soname differences for vulkan-swrast.
==> No soname differences for vulkan-virtio.
usr/share/doc/mesa/relnotes/24.1.5.html <
usr/share/doc/mesa/relnotes/24.1.6.html <
usr/share/doc/mesa/relnotes/24.1.7.html <
usr/share/doc/mesa/relnotes/24.3.0.html | usr/share/doc/mesa/relnotes/24.2.7.html
usr/share/doc/mesa/relnotes/24.3.1.html <
usr/share/doc/mesa/relnotes/24.3.2.html <
usr/share/doc/mesa/relnotes/24.3.3.html <
usr/share/doc/mesa/rust.html <
==> No soname differences for mesa-docs.
EDIT:
Any way to search for installed pkgs needing either of the two soname warnings?
Maybe:
$ pacman -F libVkLayer_MESA_screenshot.so
extra/vulkan-mesa-layers 1:24.3.3-2
usr/lib/libVkLayer_MESA_screenshot.so
Not installed...
$ pacman -Fx 'libgallium-*'
extra/mesa 1:24.3.3-2 [installed: 1:24.2.7-2]
usr/lib/libgallium-24.3.3-arch1.2.so
aur/mesa-git 25.0.0_devel.200083.776199ea77f.d41d8cd-1
usr/lib/libgallium-25.0.0-devel.so
Only mesa.
Last edited by NuSkool (2025-01-18 02:07:02)
Scripts I use: https://github.com/Cody-Learner
Offline
To continue tracking I did the following, I updated all the packages to the latest version, which made me crash in 2 hours, with the system in ''default''.
I continued to edit
/etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
Identifier "AMD"
MatchDriver "amdgpu"
Driver "amdgpu"
Option "EnablePageFlip" "off"
Option "TearFree" "false"
EndSection
and downgrade bios to AMD AM4 AGESA Combo V2 PI 1.2.0.A
I've had 8 hours without crashes.
EDIT: freezes during accelerated video decoding.
I try to replicate the error after editing
/etc/environment
MESA_SHADER_CACHE_DIR=/home/user/.cache/mesa_shader_cache
After several attempts, I have not been able to replicate any crash.
Last edited by SnowF (2025-01-18 07:20:42)
Offline
With AGESA ComboV2PI 1.2.0.Cc after 24h+, I yet have to experience any crash, no custom configs or anything, all default.
EDIT: Still freezing with AGESA ComboV2PI 1.2.0.Cc after 30h+.
Last edited by lpr1 (2025-01-19 04:51:00)
Offline
As announced in #180 I am now using the mesa-test-git 25.0.0' without the patch from Marek Olšák (mesa developer).
The file was built by @Lone_Wolf and is based on the package 'llvm-libs 19.1.6-3' from 09.01.2025 (#152).
Since some users said to have lost the thread in the meantime, I will try to recapitulate the reason for this action here:
@kclisp had found a way to reproduce the mesa error with his i3 installation (#60), so that together with @Lone_Wolf the commit supposedly causal could be tracked down via the bisecting procedure (#50), which presumably causes the system freeze (starting from #60).
First, a test package was created for the lower and upper limit (#55), with @bernd_b selecting the upper limit for a test with 'mesa-test-git 25.0.0' (#56). Since @kclisp was the only user who was able to reproduce the error on his system (#60), all other users had withdrawn from the test procedure.
@bernd_b had not noticed this and was still testing the test package 25.0.0 at this time without getting a crash.
Then I also tested this package for about 12 hours and also came to the conclusion that this package does not cause a crash (#113).
This led to the assumption that there could be several bugs in mesa 24.3.x for AMD APU's with vesa graphics (gfx9).
In the meantime @bernd_b had no contact to the forum, so that it could be assumed that he was still using a version of mesa 25.0.0 without any problems, which suddenly changed in post #157 under unclear circumstances.
Now I want to find out with another slightly longer test if mesa 25.0.0 in the build described above leads to a crash on my system or not.
This insight could be very important for further analysis. See also post #177 by @kclisp.
However, it should also be noted that the conditions have changed slightly in the meantime. The packages 'llvm-libs', 'linux-firmware' and 'amd-ucode' have been updated, the kernel has further updates and mesa itself now has newer packages than in the initial situation.
At least the current version mesa 24.3.3-2 is now running with some fewer crashes on my system (2 crashes in 3 days).
That's my humble view. Let's see if this will lead to anything...
Sources:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12310
Offline
libgallium-24.3.3-arch1.2.so=libgallium-24.3.3-arch1.2.so-64 | libgallium-24.2.7-arch1.2.so=libgallium-24.2.7-arch1.2.so-64
> libomx_mesa.so=libomx_mesa.so-64
pkgctl is designed for use by archlinux devs and checkpkg compares so-names from the build package with the repo package.
The comparison is based on pkgname and has no purpose (that i'm aware of) for building non-repo packages .
If you want to avoid running pkgcheck just give your package a different name like mesa-nuskool .
All (repo) programs should work fine with your build version .
Would it be correct to assume a rebuild required whenever libva updates? Anything else I should be aware of?
Incase you want a warning when soname changes in repo packages (like a newer llvm version) mandate a rebuild of other packages , install rebuild-detector .
It runs on every pacman -Syu and is a very handy tool for aur users. Should probably be installed/active on all systems using non-repo packages.
To all participating in/following this thread :
There is 99.999 % chance of more then 3 bugs being present with mesa 23.3.x and vega / gfx9 hardware .
Two have been fixed in later 23.3.x releases , 3rd is the one found by kclisp which is investigated upstream.
IF someone finds a reproducable bug with the 24.2.8 I provided, bisecting it is still worth it.
Mesa release manager will branch off 25.0 soon (I estimate no sooner then 4 weeks and no later then 8 weeks) and everything that is in trunk/main now will then be in that branch .
Once 25.0.1 is released , the support for 24.2.x will end .period.
Testing a recent git build (see post #133) is the best option for helping to find the remaining bugs .
Last edited by Lone_Wolf (2025-01-18 14:00:20)
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
Testing a recent git build (see post #133) is the best option for helping to find the remaining bugs.
@Lone_Wolf probably means post #131.
llvm-libs is up to 19.1.7-1 now. Is a rebuild needed?
Offline
Yup, 131 is the correct post. #155 also has it.
The sonames in llvm-libs end with 19.1 so stayed the same.
A rebuild should NOT be needed.
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
I've tested Lone_Wolf's 24.2.8 for over 12 hours without crashes and the patched mesa-test-git 25.0.0_devel.200085.94da1edbe49-1for 27 hours also without any crashes, I haven't tested it without the patch though.
I've also tested the current mesa-git package in the AUR (25.0.0_devel.200052.bed748d5f6d.d41d8cd-1) and that one crashes.
Offline
I've also tested the current mesa-git package in the AUR (25.0.0_devel.200052.bed748d5f6d.d41d8cd-1) and that one crashes.
that's only the version it had when it was uploaded, when you built it, it will have updated the version.
pacman -Qi mesa-git will give the correct version.
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 all participating in/following this thread :
There is 99.999 % chance of more then 3 bugs being present with mesa 23.3.x and vega / gfx9 hardware .
Two have been fixed in later 23.3.x releases , 3rd is the one found by kclisp which is investigated upstream.IF someone finds a reproducable bug with the 24.2.8 I provided, bisecting it is still worth it.
Mesa release manager will branch off 25.0 soon (I estimate no sooner then 4 weeks and no later then 8 weeks) and everything that is in trunk/main now will then be in that branch .
Once 25.0.1 is released , the support for 24.2.x will end .period.Testing a recent git build (see post #133) is the best option for helping to find the remaining bugs .
Also important thing to keep in mind: linux-firmware package affects the GPU behavior directly. Maybe it worth the efforts to try the latest trunk since Picasso firmware was updated last week amdgpu: update picasso firmware
BTW: linux 6.12.10 is also out, if you check the log it contains a lot of amdgpu fixes Linux 6.12.10
One of the fixes related to system freeze: https://gitlab.freedesktop.org/drm/amd/-/issues/3729
Last edited by Mechanicus (2025-01-18 17:43:22)
Online
I just got freeze (while working in Blender and running Firefox/youtube) with AGESA ComboV2PI 1.2.0.Cc after 30h+. So it's far more rare but still present, all stock arch packages (linux 6.12.9.arch1-1, mesa 1:24.3.3-2 etc.).
Last edited by lpr1 (2025-01-19 04:54:46)
Offline
It is premature and therefore counterproductive to announce on the mesa-tickets that with 2 further updates (llvm-libs, AGESA Combo V2 PI 1.2.0.Cc) there are no crashes/freezes. Especially not when a mesa developer tries to reproduce another user's report here, which wasn't yet succeeded.
In my opinion one should also wait for the experiences of other users who are represented here. @lpr1 reports for example that there are still crashes with these two updates, even if they are less frequent so far. Thanks for that @lpr1.
This is not a competition to see who comes first. Together we want to get this shit under control...
Last edited by orbit-oc (2025-01-19 17:20:55)
Offline
I've the same error in an APU Ryzen5 3400g, and Lone_Wolf's mesa 24.2.8 is working like a charm for many hours.
With 24.3.3 I can't work with Android Studio or Eclipse without freezing in less than one hour. With 24.2.8 I have no freezes in more than eight hours.
Tomorrow I'm going to test the 25.0.0_devel.200085.94da1edbe49-1 and post logs if freeze again.
Offline
I've the same error in an APU Ryzen5 3400g, and Lone_Wolf's mesa 24.2.8 is working like a charm for many hours.
With 24.3.3 I can't work with Android Studio or Eclipse without freezing in less than one hour. With 24.2.8 I have no freezes in more than eight hours.
Tomorrow I'm going to test the 25.0.0_devel.200085.94da1edbe49-1 and post logs if freeze again.
Has the error occur on Linux 6.12.10?
Online
My small and humble contribution:
System:
OS: Arch Linux
Kernel: linux-zen 6.12.10-zen1-1-zen
Windowing System: Wayland
Compositor: Hyprland 0.46.2-7
Latest system update (pacman -Syyu): 2024-01-19 12:02PM (UTC-5)
Additional details:
Steam Client Version: 1733265492
Firefox Version: 134.0.1-1
Mesa Package: mesa-24.3.3 (24.3.2 also affected) (see PKGBUILD below) (I compiled it myself).
Here is the PKGBUILD: https://gist.github.com/LnxFCA/c76be058 … a8e93e1c5d.
lspci -knn output for related devices:
04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c4)
Subsystem: Acer Incorporated [ALI] Device [1025:1259]
Kernel driver in use: amdgpu
Kernel modules: amdgpu
01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625 Mobile] [1002:6900] (rev d1)
Subsystem: Acer Incorporated [ALI] Device [1025:125a]
Kernel driver in use: amdgpu
Kernel modules: amdgpu
After testing mesa-24.3.3-1 and mesa-24.3.2-1. The most reliable way I found to reproduce the freeze was:
Open Steam and use it for a few minutes (2–3).
Switch to another workspace and open Firefox.
Use Firefox normally or leave it focused.
After 30–40 minutes, switch back to Steam and start using it.
The system will reliably crash (freeze) shortly after this.
My solution:
After compiling mesa-24.3.3 with the patch provided here https://gitlab.freedesktop.org/mesa/mesa/-/issues/12310, my system has been running fine for almost five hours without any freezes.
Based on this, it seems likely that the patch fixes the issue on my hardware, but I cannot completely confirm it yet. I will update if anything happens in a few more hours.
Here is the PKGBUILD for the patched mesa-24.3.3: https://gist.github.com/LnxFCA/4b1dc567 … d5fcca3511.
Last edited by LnxFCA (2025-01-19 23:28:57)
Offline
It is premature and therefore counterproductive to announce on the mesa-tickets that with 2 further updates (llvm-libs, AGESA Combo V2 PI 1.2.0.Cc) there are no crashes/freezes. Especially not when a mesa developer tries to reproduce another user's report here, which wasn't yet succeeded.
In my opinion one should also wait for the experiences of other users who are represented here. @lpr1 reports for example that there are still crashes with these two updates, even if they are less frequent so far. Thanks for that @lpr1.
This is not a competition to see who comes first. Together we want to get this shit under control...
Exactly, we are not seeking a workaround solution, we are attempting to find what's the issue, reproduce it, and then mesa devs can solve it.
Thanks @LnxFCA, hopefully someone who have steam can attempt your method.
Last edited by lpr1 (2025-01-20 01:15:35)
Offline
pacoandres wrote:I've the same error in an APU Ryzen5 3400g, and Lone_Wolf's mesa 24.2.8 is working like a charm for many hours.
With 24.3.3 I can't work with Android Studio or Eclipse without freezing in less than one hour. With 24.2.8 I have no freezes in more than eight hours.
Tomorrow I'm going to test the 25.0.0_devel.200085.94da1edbe49-1 and post logs if freeze again.
Has the error occur on Linux 6.12.10?
No, I haven't update the system yet.
By now I'm using Linux 6.12.9 with firmware 20250109.7673dffd-1.
The freezes started with Linux 6.12.8, firmware 20241210.b00a7f7e-1 and mesa 24.3.3.
As firmware 20241210.b00a7f7e-1 update is previous to this problem, I think there's no error on it.
Today I'll test Linux 6.12.10 with mesa 24.3.3.
Offline
Mechanicus wrote:pacoandres wrote:I've the same error in an APU Ryzen5 3400g, and Lone_Wolf's mesa 24.2.8 is working like a charm for many hours.
With 24.3.3 I can't work with Android Studio or Eclipse without freezing in less than one hour. With 24.2.8 I have no freezes in more than eight hours.
Tomorrow I'm going to test the 25.0.0_devel.200085.94da1edbe49-1 and post logs if freeze again.
Has the error occur on Linux 6.12.10?
No, I haven't update the system yet.
By now I'm using Linux 6.12.9 with firmware 20250109.7673dffd-1.
The freezes started with Linux 6.12.8, firmware 20241210.b00a7f7e-1 and mesa 24.3.3.
As firmware 20241210.b00a7f7e-1 update is previous to this problem, I think there's no error on it.Today I'll test Linux 6.12.10 with mesa 24.3.3.
Working with Eclipse it tooks less than one hour to freeze with Linux 6.12.10 and mesa 24.3.3.
No response to mouse, ctrl-alt-del, REISUB (I think there's no response to any keyboard event) or short power push. I've to hard reset the system.
There is also no log message this time, just the "Dumping IP State" message.
ene 20 09:16:21 monelle kernel: amdgpu 0000:09:00.0: amdgpu: Dumping IP State
ene 20 09:16:39 monelle systemd-logind[633]: Power key pressed short.
ene 20 09:16:39 monelle systemd[1042]: Created slice Slice /app/dbus-:1.2-org.kde.Shutdown.
ene 20 09:16:39 monelle systemd[1042]: Started dbus-:1.2-org.kde.Shutdown@0.service.
ene 20 09:16:47 monelle kernel: INFO: NMI handler (perf_event_nmi_handler) took too long to run: 27.040 msecs
ene 20 09:16:47 monelle kernel: perf: interrupt took too long (211713 > 2500), lowering kernel.perf_event_max_sample_rate to 900
Now Im going to try @Lone_Wolf's mesa 25.0.0_devel.200085.94da1edbe49-1.
Last edited by pacoandres (2025-01-20 09:04:59)
Offline