You are not logged in.
I have also been experiencing these crashes and lockups for few weeks since upgrading to mesa 24.3.x;
I have AMD Radeon RX 580 gfx card - not the APU. The CPU is AMD Ryzen 5 5600X.
Downgrading mesa and vulkan-radeon to 24.2.7 seems to fix the lockups (also had to install llvm18-libs).
pacman -U https://archive.archlinux.org/packages/m/mesa/mesa-1%3A24.2.7-1-x86_64.pkg.tar.zst
pacman -U https://archive.archlinux.org/packages/v/vulkan-radeon/vulkan-radeon-1%3A24.2.7-1-x86_64.pkg.tar.zst
pacman -S llvm18-libs
Here's the log of one crash:
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State Completed
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx timeout, signaled seq=185596, emitted seq=185598
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Process information: process kwin_wayland pid 1318 thread kwin_wayla:cs0 pid 1369
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset begin!
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: BACO reset
Jan 19 11:45:23 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset succeeded, trying to resume
Jan 19 11:45:23 beeblebrox kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400800000).
Jan 19 11:45:23 beeblebrox kernel: [drm] VRAM is lost due to GPU reset!
Jan 19 11:45:24 beeblebrox kernel: [drm] UVD and UVD ENC initialized successfully.
Jan 19 11:45:24 beeblebrox kernel: [drm] VCE initialized successfully.
Jan 19 11:45:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset(2) succeeded!
Jan 19 11:45:24 beeblebrox kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Jan 19 11:45:24 beeblebrox kwin_wayland[1318]: kwin_scene_opengl: A graphics reset not attributable to the current GL context occurred.
Jan 19 11:45:24 beeblebrox kwin_wayland[1318]: kwin_scene_opengl: 0x2: GL_CONTEXT_LOST in context lost
....
Jan 19 11:45:24 beeblebrox kwin_wayland[1318]: kwin_scene_opengl: 0x2: GL_CONTEXT_LOST in context lost
Jan 19 11:45:24 beeblebrox kwin_wayland[1318]: kwin_wayland_drm: Checking test buffer failed!
....
Jan 19 11:45:24 beeblebrox plasmashell[1599]: amdgpu: The CS has cancelled because the context is lost. This context is innocent.
Jan 19 11:45:24 beeblebrox plasmashell[1599]: KCrash: Application 'plasmashell' crashing... crashRecursionCounter = 2
Executing this causes the freeze with 24.2.7:
sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover
Offline
Split off from https://bbs.archlinux.org/viewtopic.php?id=301798
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 am pretty sure I am affected by this too with the Radeon 6600XT. I have only been lurking because the consensus seemed to be that it only affected the APUs and I don't have any errors in my logs when it happens, but there are too many other similarities with the symptoms and timing for it to be a coincidence.
My computer was so unusable that I ended up hopping distros to Fedora Kinoite and the issue disappeared, confirming that it's a software issue and not a hardware failure. I'm still anxiously following these threads and the various Mesa gitlab issues, hoping the problem is found and fixed before it hits the Fedora packages.
Offline
@maxrd2 @algebro
If I'm not mistaken about the names, then gfx8, gfx9 and gfx10 cards would be affected. The errors also seem comparable to me. Who knows if this even is not the same error. At least one of them.
It would be nice if you could get back here if you gain new insights or if the problem is solved.
Good luck: mesa seems to have a lot of problems at the moment.
I'm pretty annoyed by now...
Offline
After being sure that rollback to 24.2.7 stopped random crashes/freezes, have installed 24.2.8 from this post:
https://bbs.archlinux.org/viewtopic.php … 3#p2220233
OpenGL renderer string: AMD Radeon RX 580 Series (radeonsi, polaris10, LLVM 19.1.6, DRM 3.59, 6.12.10-zen1-1-zen)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.2.8 (git-6552e32957)
Executing this causes the freeze with 24.2.8 and gfx card never recovered I had to reboot afterwards (with 24.2.7 it would recover after 10sec or so):
sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover
Other than that have used it for a day and I didn't notice crashes/freezes, will try mesa-git now.
Logs during crash:
Jan 22 23:09:14 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset begin!
Jan 22 23:09:14 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: BACO reset
Jan 22 23:09:14 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset succeeded, trying to resume
Jan 22 23:09:14 beeblebrox kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400800000).
Jan 22 23:09:14 beeblebrox kernel: [drm] VRAM is lost due to GPU reset!
Jan 22 23:09:14 beeblebrox kernel: [drm] UVD and UVD ENC initialized successfully.
Jan 22 23:09:14 beeblebrox kernel: [drm] VCE initialized successfully.
Jan 22 23:09:14 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset(1) succeeded!
Jan 22 23:09:14 beeblebrox kwin_wayland[1329]: kwin_scene_opengl: 0x2: GL_CONTEXT_LOST in context lost
Jan 22 23:09:14 beeblebrox kwin_wayland[1329]: kwin_scene_opengl: 0x2: GL_CONTEXT_LOST in context lost
...
Jan 22 23:09:21 beeblebrox systemd-coredump[5407]: [?] Process 1609 (plasmashell) of user 1000 dumped core.
...
Jan 22 23:09:24 beeblebrox kwin_wayland[1329]: kwin_wayland_drm: Pageflip timed out! This is a kernel bug
...
Jan 22 23:09:21 beeblebrox systemd[1270]: plasma-ksystemstats.service: Consumed 1.210s CPU time, 9.3M memory peak.
Jan 22 23:09:21 beeblebrox systemd[1270]: plasma-plasmashell.service: Main process exited, code=dumped, status=6/ABRT
Jan 22 23:09:21 beeblebrox systemd[1270]: plasma-plasmashell.service: Failed with result 'core-dump'.
Jan 22 23:09:21 beeblebrox systemd[1270]: plasma-plasmashell.service: Consumed 10.824s CPU time, 864.4M memory peak.
Jan 22 23:09:21 beeblebrox drkonqi-coredump-processor[5408]: "/usr/bin/plasmashell" 1609 "/var/lib/systemd/coredump/core.plasmashell.1000.6adbfb2037be469696ee33487c73f43e.1609.1737583754000000.zst"
Jan 22 23:09:21 beeblebrox systemd[1270]: Started Launch DrKonqi for a systemd-coredump crash (PID 5408/UID 0).
Jan 22 23:09:21 beeblebrox systemd[1]: drkonqi-coredump-processor@1-5406-0.service: Deactivated successfully.
Jan 22 23:09:21 beeblebrox systemd[1270]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 1.
Jan 22 23:09:21 beeblebrox systemd[1270]: Starting KDE Plasma Workspace...
Jan 22 23:09:24 beeblebrox kwin_wayland[1329]: kwin_wayland_drm: Pageflip timed out! This is a kernel bug
Jan 22 23:09:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State
Jan 22 23:09:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State Completed
Jan 22 23:09:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx timeout, signaled seq=65723, emitted seq=65726
Jan 22 23:09:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Process information: process kwin_wayland pid 1329 thread kwin_wayla:cs0 pid 1380
Jan 22 23:09:24 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset begin!
Jan 22 23:09:25 beeblebrox kernel: amdgpu 0000:07:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_0.2.1.0 test failed (-110)
Jan 22 23:09:25 beeblebrox kernel: [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed
Jan 22 23:09:25 beeblebrox kernel: amdgpu: cp is busy, skip halt cp
Jan 22 23:09:25 beeblebrox kernel: amdgpu: rlc is busy, skip halt rlc
Jan 22 23:09:25 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: BACO reset
Jan 22 23:09:26 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset succeeded, trying to resume
Offline
Just had a crash with mesa-git 25.0.0-devel (git-94da1edbe4) installed from post:
https://bbs.archlinux.org/viewtopic.php … 3#p2220233
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State Completed
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx timeout, signaled seq=3386911, emitted seq=3386913
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: Process information: process kwin_wayland pid 1296 thread kwin_wayla:cs0 pid 1347
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset begin!
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: BACO reset
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset succeeded, trying to resume
Jan 23 22:40:55 beeblebrox kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400800000).
Jan 23 22:40:55 beeblebrox kernel: [drm] VRAM is lost due to GPU reset!
Jan 23 22:40:55 beeblebrox kernel: amdgpu 0000:07:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.3.0 test failed (-110)
Jan 23 22:40:56 beeblebrox kernel: amdgpu 0000:07:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.2.1 test failed (-110)
Jan 23 22:40:56 beeblebrox kernel: [drm] UVD and UVD ENC initialized successfully.
Jan 23 22:40:56 beeblebrox kernel: [drm] VCE initialized successfully.
Jan 23 22:40:56 beeblebrox kernel: amdgpu 0000:07:00.0: amdgpu: GPU reset(2) succeeded!
Jan 23 22:40:56 beeblebrox kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Jan 23 22:40:56 beeblebrox kwin_wayland[1296]: kwin_scene_opengl: A graphics reset not attributable to the current GL context occurred.
Jan 23 22:40:56 beeblebrox kwin_wayland[1296]: kwin_scene_opengl: 0x2: GL_CONTEXT_LOST in context lost
Last edited by maxrd2 (2025-01-24 08:31:23)
Offline
@algebro
Please try a recent trunk build, e.g. Lone_Wolf's unpatched build #152 (https://bbs.archlinux.org/viewtopic.php?id=301798&p=7) and see if the error still occurs with that.
@algebro @maxrd2
If a freeze/crash still occurs on trunk, you'll probably need to make a new mesa issue, assuming it's different from the gfx9 one.
Offline
@algebro
Oh right, you can also wait for linux 6.13 in case it's this issue https://gitlab.freedesktop.org/drm/amd/-/issues/3693.
Offline
Sofar I haven't seen reports from the gfx9 users of breakage with the 24.2.8 I build.
That strongly suggests maxrd2 is facing a different bug.
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
Sofar I haven't seen reports from the gfx9 users of breakage with the 24.2.8 I build.
That strongly suggests maxrd2 is facing a different bug.
Does it? Couldn't they just be the first one reporting it? I lurked for a long time before posting because everyone seemed convinced that only APUs were affected
Offline
Mesa 24.3.x has multiple bugs that 24.2.x doesn't have . most related to radeonsi / amd cards .
Atleast 3 separate bugs have been identified, 2 of which didn't affect vega/apus at all. (those 2 have been solved already).
The 3rd is the one found by kclisp .
My personal estimate is that there are atleast 2 other bugs in 24.3 for which the cause hasn't been found yet, possibly more .
The best tool to pinpoint causes is bisecting but that only works if testers can reproduce the crashes .
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
Mesa 24.3.x has multiple bugs that 24.2.x doesn't have . most related to radeonsi / amd cards .
The best tool to pinpoint causes is bisecting but that only works if testers can reproduce the crashes .
I have finished bisecting. The crash occurs during 12 hrs, so it took me awhile to test everything, but have managed.
I'm not 100% sure that "good" commits are good, I have intensively used the PC for at least 1 day on "good" commits without crash so they should be good.
It seems that:
505fd350bc9634a75d73fa92461fc4819309c2f5 is the first bad commit
commit 505fd350bc9634a75d73fa92461fc4819309c2f5
Author: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Date: Sat Aug 17 15:09:39 2024 -0400
hk: handle compressed eMRT
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30981>
src/asahi/vulkan/hk_cmd_draw.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
EDIT: Have used kernel 6.12.10-zen1-1-zen and haven't updated the system between start-finish bisecting
Last edited by maxrd2 (2025-02-09 22:29:56)
Offline
That commit is part of MR 30981 which is for apple macs with apple M* arm processors.
It's very unlikely to have any effect on AMD gpus on X86 .
EDIT: Have used kernel 6.12.10-zen1-1-zen and haven't updated the system between start-finish bisecting
Good call, not introducing new factors helps with bisecting.
For now I suggest you update your system, then build Mesa 25.0 - rc2 and see if the crash still occurs .
The 25.0 branch will be released as stable in a few weeks and has many amd related commits/fixes that were not in 24.3.x .
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
For now I suggest you update your system, then build Mesa 25.0 - rc2 and see if the crash still occurs .
Have built/installed it (1d051e5cb1), and had a crash just now.
That commit is part of MR 30981 which is for apple macs with apple M* arm processors.
It's very unlikely to have any effect on AMD gpus on X86 .
I have noticed that too, but still 48d4c5b4898 worked for couple days.
Are sources under `src/asahi` used exclusively only for asahi platform?
Am reverting back to 48d4c5b4898ec1e60241f101e4a3b67c0210ab1c will see if it still works.
Should I report this upstream?
Last edited by maxrd2 (2025-02-10 19:41:51)
Offline
Try to find the oldest commit that you confirmed to be bad and restart the bisect with that one .
If you do have the bisect log still available, please post it.
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
Try to find the oldest commit that you confirmed to be bad and restart the bisect with that one .
If you do have the bisect log still available, please post it.
Have already restarted bisect because 48d4c5b4898ec1e60241f101e4a3b67c0210ab1c crashed after working fine for more than a day:
I don't have log since I restarted, but have kept history in text file:
Inside `mesa-work` dir, have done:
$ git bisect start
$ git bisect bad # mesa-24.3.4
$ git bisect good mesa-24.2.8
Bisecting: a merge base must be tested
[bb8063e1f4ddaf24b40a27c102a720accdef536a] anv/generated_indirect_draws: Adjust xe2 simd32 sends_count_expectation
# PKGBUILD makepkg failed (due to rust crap) - have marked it `git bisect good` anyway
$ git bisect good
Bisecting: 2732 revisions left to test after this (roughly 12 steps)
[b8782c783c6a2d978a69f59d10f695d907dd3704] intel/ci: track changes to the global driver `*-skips.txt` files
$ git bisect bad # it crashed after a whole day
Bisecting: 1364 revisions left to test after this (roughly 10 steps)
[8cc95baf7b8cbd5e01194bdcba83e5f2b0367550] dri: merge in loader_dri3
$ git bisect good
Bisecting: 682 revisions left to test after this (roughly 9 steps)
[e32989a698a78560c3bce935d6bf1feecd267c91] intel/dev: Enable BMG PCI IDs (without INTEL_FORCE_PROBE)
$ git bisect good
Bisecting: 341 revisions left to test after this (roughly 9 steps)
[b1934057cb7486db84e787c81375a2bdd9f19cfa] pan/cs: Allow sparse register set passed to loads/stores
$ git bisect bad
Bisecting: 170 revisions left to test after this (roughly 7 steps)
[0c81a29db6935381e2e5c00b5aa7c7d45c1f20f3] virgl: set no_integers
$ git bisect bad
Bisecting: 84 revisions left to test after this (roughly 6 steps)
[d29dfc180e94e42c74a7f3cc854e7e550861637b] etnaviv: allow shader machine code dumps in release builds
$ git bisect bad
Bisecting: 42 revisions left to test after this (roughly 5 steps)
[9b4e46e8fc2307577185174124d1a1f0f8126050] radv/ci: update the flakes lists
$ git bisect bad
Bisecting: 20 revisions left to test after this (roughly 4 steps)
[a6c5f7dc2060aa731a1c7d6c0b452609380eddd1] asahi: handle cross-process eMRT
$ git bisect good
Bisecting: 10 revisions left to test after this (roughly 3 steps)
[b5899a2bf9e5253126b3c312252f35e8448a2a60] hk: shrink cmd bo
$ git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[64495653eb9575d86e564a7e959c866b0f61d5a7] hk: remove texel buffers from meta
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
[505fd350bc9634a75d73fa92461fc4819309c2f5] hk: handle compressed eMRT
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[48d4c5b4898ec1e60241f101e4a3b67c0210ab1c] hk: fix bg key with eMRT
$ git bisect good
505fd350bc9634a75d73fa92461fc4819309c2f5 is the first bad commit
commit 505fd350bc9634a75d73fa92461fc4819309c2f5
Author: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Date: Sat Aug 17 15:09:39 2024 -0400
hk: handle compressed eMRT
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30981>
src/asahi/vulkan/hk_cmd_draw.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
### test and `git bisect good` / `git bisect bad`
test 1d051e5cb1f182c8ff51753a3de6af6956bd0954 - 25.0.0.rc2 was bad
returned to 48d4c5b4898ec1e60241f101e4a3b67c0210ab1c - that one failed too, so restarting bisect
$ git bisect start
Previous HEAD position was 48d4c5b4898 hk: fix bg key with eMRT
HEAD is now at 769e51468b4 VERSION: bump for 24.3.4
status: waiting for both good and bad commits
$ git bisect bad 48d4c5b4898ec1e60241f101e4a3b67c0210ab1c
status: waiting for good commit(s), bad commit known
$ git bisect good 8cc95baf7b8cbd5e01194bdcba83e5f2b0367550
Bisecting: 354 revisions left to test after this (roughly 9 steps)
[6ae013a03209f01f0d976e111b696d0e7c88d451] glsl: use generic convertion code for some intrinsics
Offline
Well, after about a month of running Fedora Kinoite without any issues I suddenly started getting this bug. Kinoite uses daily atomic updates, and it looks like it occurred somewhere between 2-7 and 2-20, but I doubt it's worth trying to pin down at this point.
Let me know if there is some way I can help with troubleshooting although I am no longer running arch.
Offline
@algebro
Did you see if your problem matches https://gitlab.freedesktop.org/drm/amd/-/issues/3693? What kernel version are you using?
Offline
@kclisp
Sorry for the noise, but I think I spoke too soon. After rolling back and spending a few more weeks on the 02-07-2025 build, I updated to to 02-22-2025 and the issue seems to have gone away (I've been stable for ~4 days). As part of troubleshooting I've disabled automatic sleep as that seemed to exacerbate it, but I need to re-enable that and see if that triggers it.
Kernel is Linux fedora 6.12.15-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Feb 18 15:24:05 UTC 2025 x86_64 GNU/Linux
Mesa is 24.3.4, at least as reported by glxinfo: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.3.4
Hard to tell if that's the exact problem you posted, I got the "dumping IP state" error that I'd seen in a number of similar threads to this one.
Last edited by algebro (2025-02-25 14:20:25)
Offline
Try to find the oldest commit that you confirmed to be bad and restart the bisect with that one .
Just finished that.. and this time it makes even less sense - don't see anything wrong with strdup there :-/
Each good commit was tested for at least 2 days
$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# bad: [48d4c5b4898ec1e60241f101e4a3b67c0210ab1c] hk: fix bg key with eMRT
git bisect bad 48d4c5b4898ec1e60241f101e4a3b67c0210ab1c
# status: waiting for good commit(s), bad commit known
# good: [8cc95baf7b8cbd5e01194bdcba83e5f2b0367550] dri: merge in loader_dri3
git bisect good 8cc95baf7b8cbd5e01194bdcba83e5f2b0367550
# bad: [6ae013a03209f01f0d976e111b696d0e7c88d451] glsl: use generic convertion code for some intrinsics
git bisect bad 6ae013a03209f01f0d976e111b696d0e7c88d451
# bad: [e19871bd6ad0651a5b8ea8215eab686ace5d08e1] nak: Use F2FP for nir_op_pack_half_2x16_split on SM86+
git bisect bad e19871bd6ad0651a5b8ea8215eab686ace5d08e1
# bad: [2b2b66f497bf8c5f91067752995a5c1003255a6f] vk/sync: Use the proper type in vk_filter_{src,dst}_access_flags2()
git bisect bad 2b2b66f497bf8c5f91067752995a5c1003255a6f
# bad: [48e46c71c03b2d7bb32cb7672583f4d539eb1348] iris/gfx20: Enable depth buffer write through for multi sampled images
git bisect bad 48e46c71c03b2d7bb32cb7672583f4d539eb1348
# good: [d19c650c7e7efd1ca4295a02f5a2c85eb434b34b] glx: tweak some drisw context create code
git bisect good d19c650c7e7efd1ca4295a02f5a2c85eb434b34b
# bad: [b89cf3bbaae2abfb13018a31f4f5ed9eaf43b569] glx: rework screen destroy
git bisect bad b89cf3bbaae2abfb13018a31f4f5ed9eaf43b569
# bad: [b06e861dc8eb9afa5f97d27f7c681678d1c66174] glx: unify dri get_driver_name
git bisect bad b06e861dc8eb9afa5f97d27f7c681678d1c66174
# good: [5edfc648580171a3ddcfe8ea10cbff943168fc26] glx: unify renderer query hooks
git bisect good 5edfc648580171a3ddcfe8ea10cbff943168fc26
# good: [f717e67f0cc586f4808177f6c3dffd9cc86dda47] glx/dri3: strdup existing driverName instead of fetching it again
git bisect good f717e67f0cc586f4808177f6c3dffd9cc86dda47
# first bad commit: [b06e861dc8eb9afa5f97d27f7c681678d1c66174] glx: unify dri get_driver_name
Offline
That commit is part of a huge refactoring merge request that changes glx/dri .
It does affect x86_64 systems and gpus , so could be relevant .
I think there is enough rrason to ask input from the commit author (who knows a lot about mesa / opengl / vulkan etc) .
Please file a bug report with mesa.
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
That commit is part of a huge refactoring merge request that changes glx/dri .
It does affect x86_64 systems and gpus , so could be relevant .
I think there is enough rrason to ask input from the commit author (who knows a lot about mesa / opengl / vulkan etc) .
Please file a bug report with mesa.
Of course it froze on the commit I've marked good just few hours later... will keep trying
Offline
I have an update on this one.
Since recently crashes/freezes became very frequent.
I've tried downgrading mesa to old version that was stable, but freezes continued, so I've tried downgrading kernel.
The freezes do not happen with latest mesa (1:25.0.5-2) and latest LTS kernel (6.12.26-1-cachyos-lts-lto)
So for me this seems to be a problem with the kernel and not mesa. Not sure where to report this and whether it makes sense to bisect the kernel between 6.12.26 and 6.14.4.
EDIT: here seems to be one similar bug report with no activity: https://bugzilla.kernel.org/buglist.cgi … %20timeout
Last edited by maxrd2 (2025-05-05 11:51:42)
Offline
-
Last edited by Mechanicus (Today 17:30:42)
Offline