Created attachment 141236 [details] Xorg.pid-1154.gdb.log I have updated my old Asus F3Ke notebook with "ATI Mobility Radeon X2300 (ChipID = 0x718a)" after neglecting it for 1-2 years and now I can't launch desktop session because X immediately segfaults. This is what I was able to get after installing debug data and launching Xgdb script.
Created attachment 141237 [details] Xorg.0.log Normal X log.
Created attachment 141238 [details] Asus_F3Ke.dmesg dmesg from affected machine.
GCC's libstdc++ code crashes trying to use an instruction not supported by your CPU. You need to report this to your distro.
(In reply to Michel Dänzer from comment #3) > GCC's libstdc++ code crashes trying to use an instruction not supported by > your CPU. You need to report this to your distro. So, I've bothered my distro's bugzilla, and gcc's, then figured out why it was crashing: Mesa doesn't like being built with clang/gold and ThinLTO (Mesa doesn't build via gcc with LTO and openSUSE's OBS can't handle gcc's LTO implementation even if it would). I don't know the actual reason of the crash but the guys there figured out that the crash was coming from AVX instruction in Mesa's SWR code. The affected machine does not support any kind of AVX, so it threw out the error. But it's unclear why SWR even been trying to initialize during the load of r300_dri. If built without any {C,LD}FLAGS and with gcc, nothing crashes even with SWR built and installed. And there is no trace of SWR doing things at boot on AVX-capable amdgpu/radeonsi machine even with clang's build.
(In reply to Sergey Kondakov from comment #4) > I don't know the actual reason of the crash but the guys there figured out that > the crash was coming from AVX instruction in Mesa's SWR code. The affected > machine does not support any kind of AVX, so it threw out the error. But it's > unclear why SWR even been trying to initialize during the load of r300_dri. I think it's the combination of two things: * All Gallium drivers are linked into a single binary (so-called mega-driver) * SWR is compiled with AVX support and has initializers which are automatically executed when the above binary is dlopen()ed. Until there's a solution for this, SWR cannot be enabled in a build which has to run on non-AVX capable CPUs.
The intention (and original function) was that this would be safe -- swr would check for AVX support and load the relevant library (libAVX/libAVX2), or bail on load. Something must have regressed in there and no one noticed since AVX has become fairly common.
(In reply to Ilia Mirkin from comment #6) > The intention (and original function) was that this would be safe -- swr > would check for AVX support and load the relevant library (libAVX/libAVX2), > or bail on load. > > Something must have regressed in there and no one noticed since AVX has > become fairly common. Or, I mean, more easily it might be a problem with its special build root? AVX might be common nowadays, but not *that* much (especially considering all <i3 Intel cpus cut it) I, for one, have no problem with these switches on a Zacate (which is pretty near as for extensions) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mesa-git#n48
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/197.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.