Created attachment 118864 [details] failing Xorg.0.log -- non-root X X had been working fine (aside from performance) using compiled-from-source xf86-video-amdgpu and mesa. This morning, however, I was greeted with a segfault upon startx. The only thing that seems to have changed though, is an upgrade to debian's xserver-xorg packages which look to have introduced non-root X. Would this be the cause of the following segfault cut from the attached Xorg.0.log? I do have the xserver-xorg-legacy wrapper installed, but startx still fails (unsure if additional configuration might be needed for xserverxorg-legacy?) Please let me know if additional information is needed. I have xserver-xorg-core-dbg debugging symbols installed, but some locations in the backtrace are not resolved... [ 169.888] (==) AMDGPU(0): Silken mouse enabled [ 169.888] (II) AMDGPU(0): Set up textured video (glamor) [ 169.888] (II) AMDGPU(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 169.961] (--) RandR disabled [ 169.965] (II) SELinux: Disabled on system [ 170.012] (EE) [ 170.012] (EE) Backtrace: [ 170.017] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e) [0x56358be445be] [ 170.017] (EE) 1: /usr/lib/xorg/Xorg (0x56358bc8f000+0x1b9809) [0x56358be48809] [ 170.017] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f86b0077000+0x35180) [0x7f86b00ac180] [ 170.017] (EE) 3: /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 (_ZN4llvm2cl16AddLiteralOptionERNS0_6OptionEPKc+0x31) [0x7f86a97131e1] [ 170.018] (EE) 4: /usr/lib/x86_64-linux-gnu/libLLVM-3.5.so.1 (_ZN4llvm12PassRegistry13enumerateWithEPNS_24PassRegistrationListenerE+0x129) [0x7f86a2b4e179] [ 170.018] (EE) 5: /usr/lib/x86_64-linux-gnu/libLLVM-3.5.so.1 (0x7f86a251f000+0x3b2141) [0x7f86a28d1141] [ 170.018] (EE) 6: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0xea0a) [0x7f86b21afa0a] [ 170.018] (EE) 7: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0xeaf3) [0x7f86b21afaf3] [ 170.018] (EE) 8: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0x12c58) [0x7f86b21b3c58] [ 170.018] (EE) 9: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0xe8c4) [0x7f86b21af8c4] [ 170.018] (EE) 10: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0x1244b) [0x7f86b21b344b] [ 170.018] (EE) 11: /lib/x86_64-linux-gnu/libdl.so.2 (0x7f86b1846000+0x102b) [0x7f86b184702b] [ 170.018] (EE) 12: /lib64/ld-linux-x86-64.so.2 (0x7f86b21a1000+0xe8c4) [0x7f86b21af8c4] [ 170.018] (EE) 13: /lib/x86_64-linux-gnu/libdl.so.2 (0x7f86b1846000+0x15dd) [0x7f86b18475dd] [ 170.018] (EE) 14: /lib/x86_64-linux-gnu/libdl.so.2 (dlopen+0x31) [0x7f86b18470c1] [ 170.018] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (0x7f86ae02b000+0x28116) [0x7f86ae053116] [ 170.018] (EE) 16: /usr/lib/xorg/modules/extensions/libglx.so (0x7f86ae02b000+0x2f12e) [0x7f86ae05a12e] [ 170.018] (EE) 17: /usr/lib/xorg/modules/extensions/libglx.so (0x7f86ae02b000+0x270da) [0x7f86ae0520da] [ 170.018] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x43) [0x56358bd5bf33] [ 170.018] (EE) 19: /usr/lib/xorg/Xorg (0x56358bc8f000+0x5c82f) [0x56358bceb82f] [ 170.018] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f86b0098b45] [ 170.018] (EE) 21: /usr/lib/xorg/Xorg (0x56358bc8f000+0x46dee) [0x56358bcd5dee] [ 170.018] (EE) [ 170.018] (EE) Segmentation fault at address 0x19 [ 170.018] (EE) Fatal server error: [ 170.018] (EE) Caught signal 11 (Segmentation fault). Server aborting
(In reply to Brian Paterni from comment #0) > > [ 170.017] (EE) 3: /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 [...] > [ 170.018] (EE) 4: /usr/lib/x86_64-linux-gnu/libLLVM-3.5.so.1 [...] Looks like both 3.8 and 3.5 versions of LLVM are getting pulled in, and LLVM 3.5 wasn't safe against this yet. Is your self-built radeonsi_dri.so available in /usr/lib/x86_64-linux-gnu/dri/ as well? That's where the Xorg glx module looks for the DRI drivers. I suspect it's failing to load radeonsi_dri.so from there and falling back to swrast_dri.so, which is linked against LLVM 3.5.
I think you're right, Michel! The self-built radeonsi_dri.so is actually installed to /usr/local/lib/dri, and I'm relying on LD_LIBRARY_PATH/LIBGL_DRIVERS_PATH to hopefully pick up the local libraries. As soon as I backup the debian-provided /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so and overwrite with the local radeonsi_dri.so, startx works once again! Not only that, but hardware acceleration seems to run much faster than my previous working compile! No more slow redraws when I swap windows across screens, YAY! Thank You, Michel! :)
Glad it's working again, resolving as a setup issue.
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.