Fedora Account System
Red Hat Associate
Red Hat Customer
As a consequence of the recent F43 mesa update kerfuffle - https://discussion.fedoraproject.org/t/is-most-recent-mesa-push-to-stable-mesa-25-2-7-2-fc43-reasonable/173585 - I wrote a new test to run `vkcube --validate`. As I hoped, on F43, even in a VM with llvmpipe, that crashes with the known-broken mesa (mesa-25.2.7-2.fc43), but passes with the previous build (mesa-25.2.7-1.fc43) and the fixed build (mesa-25.2.7-3.fc43). However, an interesting plot twist: it also crashes on Rawhide, with mesa-25.3.0-4.fc44 , which does not (AFAICT) have any version of airlied's backported fix that caused the trouble on F43. It also crashes on Rawhide if I downgrade mesa to mesa-25.2.6-5.fc44 . It also still crashes if I downgrade vulkan-validation-layers and vulkan-validation-tools to the previous f43 builds, 1.4.321.0-3.fc43 and 1.4.321.0-4.fc43 . So...that seems bad. The crash is caused by a segfault, it seems: Nov 27 16:21:05 fedora kernel: vkcube[5803]: segfault at 7ffd71c51ff8 ip 00007f470365f1e6 sp 00007ffd71c52000 error 6 in libVkLayer_khronos_validation.so[65f1e6,7f4703000000+a4d000] likely on CPU 2 (core 0, socket 2) Nov 27 16:21:05 fedora kernel: Code: 06 89 da c1 ea 0c 31 d0 31 c3 89 d8 83 e0 3f 89 85 60 ff ff ff 83 e3 3f 48 89 d8 48 c1 e0 06 4c 8d ac 06 40 0e 00 00 4c 89 ef <e8> e5 21 9a ff 83 f8 0b 74 f3 83 f8 23 74 37 85 c0 75 51 8b b5 60 The backtrace is *huge* and has like 50,000 frames in it, not sure what's going on there. I'll attach it. This should be easily reproducible by installing a current Fedora Workstation Rawhide in a virt-manager or Boxes VM, install vulkan-tools and vulkan-validation-layers , and running `vkcube --validate`.
Created attachment 2116454 [details] extremely long backtrace
Downgrading kernel to 6.17 doesn't help. Neither does downgrading glibc to 2.42-4.fc43 (which required a lot of dep hell solving). Bit baffled.
Ah, it looks like the mesa I downgraded to wasn't old enough; Dave actually did an earlier backport for Rawhide, in https://src.fedoraproject.org/rpms/mesa/c/c69e2123eea0cd311d3b7715ec74acefd36418f9?branch=rawhide , and the build I tested came after that commit. He's updating Rawhide to have the latest version with the layer fix now, so hopefully that will fix this.
Aha, yeah, downgrading all the way to 25.2.5-1.fc44 makes the crash go away. Mystery solved.
FYI I could see segfault running at system without any GPU, like cloud https://bugzilla.redhat.com/show_bug.cgi?id=2416951 But its segfaulted for longer time, it seems like not a regression. With my personal machine with GPU it was segfaulting only with "problematic MESA", now it looks fine.
@Adam I thing this is good reproducer of the original mesa issue, with -2 version at headless machines: by xwfb-run - Run X11 clients on a dedicated Xwayland server headless SETUP: koji download-build --arch x86_64 mesa-25.2.7-2.fc43 dnf install ./mesa-vulkan-drivers-25.2.7-2.fc43.x86_64.rpm dnf install ./mesa-vulkan-drivers-25.2.7-2.fc43.x86_64.rpm ./mesa-filesystem-25.2.7-2.fc43.x86_64.rpm dnf install ./mesa-dri-drivers* ./mesa-libi* -y dnf install vulkan-loader vulkan-validation-layers vulkan-tools dnf install mutter xwayland-run REPRODUCER: xwfb-run -c mutter -- vkcube --validate # coredumpctl list mesa-vulkan-drivers-25.2.7-2.fc43.x86_64 segfault mesa-vulkan-drivers-25.2.7-3.fc43.x86_64 no segfault --- Still I can see segfault of 'vkcube --validate', in terminal + defining DISPLAY=:0 (not in xwfb-run )
Thanks! That might certainly help the mesa maintainers add this as a package-level test. Maintainers, are you interested in doing that?
The updated mesa for Rawhide definitely did solve this, so closing.