|
Bugzilla – Full Text Bug Listing |
| Summary: | Undefined symbol "MemoryManager25getSymbolAddressInProcess" in "swrast_dri.so" | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Markus Elfring <Markus.Elfring> |
| Component: | X.Org | Assignee: | E-mail List <xorg-maintainer-bugs> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | Markus.Elfring |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Markus Elfring
2016-01-25 11:36:46 UTC
(In reply to Markus Elfring from comment #0) > libGL: dlopen /usr/lib64/dri/swrast_dri.so failed > (/usr/lib64/dri/swrast_dri.so: undefined symbol: > _ZN4llvm19RTDyldMemoryManager25getSymbolAddressInProcessERKSs) I am curious on how the mentioned software dependencies can be resolved in a safer way. elfring@Sonne:~> nm --demangle /usr/lib64/dri/swrast_dri.so|grep getSymbolAddressInProcess U llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::string const&) I'm not convinced that no NVIDIA component is installed any longer. Attach Xserver logfile. And please, check this out. https://en.opensuse.org/SDB:NVIDIA_drivers Easy way to get NVIDIA drivers [...] The packages contain the correct 'supplements:' so Zypper will find the correct modules for your card. Unfortunately on openSUSE Leap 42.1 these 'supplemements' are being ignored by default by YaST (boo#953522). Therefore you need to select 'Extras/Install All Matching Recommended Packages' in 'Software Management' for autoselection and installation of the appropriate NVIDIA driver packages. When using 'zypper inr' you're not affected by this issue on openSUSE Leap 42.1. And for Tumbleweed we can't provide any driver RPMs, since we cannot guarantee kABI compatibily. So there you're on your own. Install the driver manually via their shell script archive. Make sure to rebuild the kernel module after each kernel update. (In reply to Stefan Dirsch from comment #2) > I'm not convinced that no NVIDIA component is installed any longer. Excerpt from the requested log file: [ 53.170] X.Org X Server 1.18.0 Release Date: 2015-11-09 [ 53.170] X Protocol Version 11, Revision 0 [ 53.170] Build Operating System: openSUSE SUSE LINUX [ 53.170] Current Operating System: Linux Sonne 4.1.1-1-desktop #1 SMP PREEMPT Wed Jul 8 14:23:40 UTC 2015 (cac28b3) x86_64 [ 53.170] Kernel command line: root=/dev/duda/root resume=LABEL=SSHD-temp splash=silent quiet vga=0x31b nomodeset [ 53.170] Build Date: 21 January 2016 06:09:24AM [ 53.170] [ 53.170] Current version of pixman: 0.33.6 … [ 53.170] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan 25 08:19:11 2016 [ 53.193] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 53.193] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 53.262] (==) No Layout section. Using the first Screen section. [ 53.262] (==) No screen section available. Using defaults. [ 53.262] (**) |-->Screen "Default Screen Section" (0) [ 53.262] (**) | |-->Monitor "<default monitor>" [ 53.263] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 53.264] (==) Automatically adding devices [ 53.264] (==) Automatically enabling devices [ 53.264] (==) Automatically adding GPU devices [ 53.264] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 53.402] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist. [ 53.402] Entry deleted from font path. [ 53.403] (==) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/ghostscript/, /usr/share/fonts/cyrillic:unscaled, /usr/share/fonts/truetype/, built-ins [ 53.403] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 53.403] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 53.403] (II) Loader magic: 0x80fd00 [ 53.403] (II) Module ABI versions: [ 53.403] X.Org ANSI C Emulation: 0.4 [ 53.403] X.Org Video Driver: 20.0 [ 53.403] X.Org XInput driver : 22.1 [ 53.403] X.Org Server Extension : 9.0 [ 53.405] (++) using VT number 7 [ 53.405] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 53.408] (--) PCI:*(0:4:0:0) 10de:1287:1043:84d6 rev 161, Mem @ 0xfa000000/16777216, 0xd8000000/134217728, 0xd6000000/33554432, I/O @ 0x0000ec00/128, BIOS @ 0x????????/524288 [ 53.409] (II) LoadModule: "glx" [ 53.486] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 53.585] (II) Module glx: vendor="X.Org Foundation" [ 53.585] compiled for 1.18.0, module version = 1.0.0 [ 53.585] ABI class: X.Org Server Extension, version 9.0 [ 53.585] (==) AIGLX enabled [ 53.585] (==) Matched nvidia as autoconfigured driver 0 [ 53.585] (==) Matched nouveau as autoconfigured driver 1 [ 53.585] (==) Matched nv as autoconfigured driver 2 [ 53.585] (==) Matched modesetting as autoconfigured driver 3 [ 53.585] (==) Matched fbdev as autoconfigured driver 4 [ 53.585] (==) Matched vesa as autoconfigured driver 5 [ 53.586] (==) Assigned the driver to the xf86ConfigLayout [ 53.586] (II) LoadModule: "nvidia" [ 53.598] (WW) Warning, couldn't open module nvidia [ 53.598] (II) UnloadModule: "nvidia" [ 53.598] (II) Unloading nvidia [ 53.598] (EE) Failed to load module "nvidia" (module does not exist, 0) [ 53.598] (II) LoadModule: "nouveau" [ 53.598] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so [ 53.623] (II) Module nouveau: vendor="X.Org Foundation" [ 53.623] compiled for 1.18.0, module version = 1.0.12 [ 53.623] Module class: X.Org Video Driver [ 53.623] ABI class: X.Org Video Driver, version 20.0 [ 53.623] (II) LoadModule: "nv" [ 53.623] (II) Loading /usr/lib64/xorg/modules/drivers/nv_drv.so [ 53.635] (II) Module nv: vendor="X.Org Foundation" [ 53.635] compiled for 1.18.0, module version = 2.1.20 [ 53.635] Module class: X.Org Video Driver [ 53.635] ABI class: X.Org Video Driver, version 20.0 [ 53.635] (II) LoadModule: "modesetting" [ 53.636] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 53.647] (II) Module modesetting: vendor="X.Org Foundation" [ 53.648] compiled for 1.18.0, module version = 1.18.0 [ 53.648] Module class: X.Org Video Driver [ 53.648] ABI class: X.Org Video Driver, version 20.0 [ 53.648] (II) LoadModule: "fbdev" [ 53.648] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 53.649] (II) Module fbdev: vendor="X.Org Foundation" [ 53.649] compiled for 1.18.0, module version = 0.4.4 [ 53.649] Module class: X.Org Video Driver [ 53.649] ABI class: X.Org Video Driver, version 20.0 [ 53.649] (II) LoadModule: "vesa" [ 53.650] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 53.665] (II) Module vesa: vendor="X.Org Foundation" [ 53.665] compiled for 1.18.0, module version = 2.3.4 [ 53.665] Module class: X.Org Video Driver [ 53.665] ABI class: X.Org Video Driver, version 20.0 [ 53.665] (II) NOUVEAU driver … [ 53.666] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 53.666] (II) FBDEV: driver for framebuffer: fbdev [ 53.666] (II) VESA: driver for VESA chipsets: vesa [ 53.890] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19 [ 54.109] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19 [ 54.109] (EE) open /dev/dri/card0: No such file or directory [ 54.109] (WW) Falling back to old probe method for modesetting [ 54.109] (EE) open /dev/dri/card0: No such file or directory [ 54.110] (II) Loading sub module "fbdevhw" [ 54.110] (II) LoadModule: "fbdevhw" [ 54.110] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 54.293] (II) Module fbdevhw: vendor="X.Org Foundation" [ 54.293] compiled for 1.18.0, module version = 0.0.2 [ 54.293] ABI class: X.Org Video Driver, version 20.0 [ 54.293] (**) FBDEV(1): claimed PCI slot 4@0:0:0 [ 54.293] (II) FBDEV(1): using default device [ 54.293] (WW) Falling back to old probe method for vesa [ 54.293] (EE) Screen 0 deleted because of no matching config section. [ 54.293] (II) UnloadModule: "modesetting" [ 54.293] (II) FBDEV(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 54.293] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32 [ 54.293] (==) FBDEV(0): RGB weight 888 [ 54.293] (==) FBDEV(0): Default visual is TrueColor [ 54.293] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) [ 54.293] (II) FBDEV(0): hardware: VESA VGA (video memory: 10240kB) [ 54.293] (II) FBDEV(0): checking modes against framebuffer device... [ 54.293] (II) FBDEV(0): checking modes against monitor... [ 54.293] (--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280) [ 54.293] (**) FBDEV(0): Built-in mode "current": 131.1 MHz, 80.3 kHz, 76.6 Hz [ 54.293] (II) FBDEV(0): Modeline "current"x0.0 131.09 1280 1312 1472 1632 1024 1028 1032 1048 -hsync -vsync -csync (80.3 kHz b) [ 54.293] (==) FBDEV(0): DPI set to (96, 96) [ 54.293] (II) Loading sub module "fb" [ 54.293] (II) LoadModule: "fb" [ 54.293] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 54.303] (II) Module fb: vendor="X.Org Foundation" [ 54.303] compiled for 1.18.0, module version = 1.0.0 [ 54.304] ABI class: X.Org ANSI C Emulation, version 0.4 [ 54.304] (**) FBDEV(0): using shadow framebuffer [ 54.304] (II) Loading sub module "shadow" [ 54.304] (II) LoadModule: "shadow" [ 54.304] (II) Loading /usr/lib64/xorg/modules/libshadow.so [ 54.309] (II) Module shadow: vendor="X.Org Foundation" [ 54.310] compiled for 1.18.0, module version = 1.1.0 [ 54.310] ABI class: X.Org ANSI C Emulation, version 0.4 [ 54.310] (II) UnloadModule: "vesa" [ 54.310] (II) Unloading vesa [ 54.310] (==) Depth 24 pixmap format is 32 bpp [ 54.310] (II) FBDEV(0): FBIOBLANK: Invalid argument (Screen blanking not supported by kernel - disabling) [ 54.314] (==) FBDEV(0): Backing store enabled [ 54.316] (==) FBDEV(0): DPMS enabled [ 54.316] (==) RandR enabled [ 54.327] (II) AIGLX: Screen 0 is not DRI2 capable [ 54.327] (EE) AIGLX: reverting to software rendering [ 55.071] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 55.073] (II) AIGLX: Loaded and initialized swrast [ 55.073] (II) GLX: Initialized DRISWRAST GL provider for screen 0 … > https://en.opensuse.org/SDB:NVIDIA_drivers > > Easy way to get NVIDIA drivers I am going to try the reactivation for such proprietary graphic driver components out once more in a moment after I generated another Linux configuration variant for my needs. > The packages contain the correct 'supplements:' so Zypper will find the > correct modules for your card. Unfortunately on openSUSE Leap 42.1 these > 'supplemements' are being ignored by default by YaST (boo#953522). Thanks for your background information. I am using the following tools. * YaST2 3.1.163-1.2 * zypper-1.12.28-1.2 > And for Tumbleweed we can't provide any driver RPMs, How is the status for the installation source "ftp://download.nvidia.com/opensuse/42.1/x86_64/"? > since we cannot guarantee kABI compatibily. This is fine in principle. How many control have you got on the maintenance of the corresponding RPM specifications? > So there you're on your own. Please distinguish the affected details more for this bug report between my difficulties with software evolution around Nvidia graphic drivers and the current surprise for the Mesa library "swrast_dri.so". elfring@Sonne:~> c++filt _ZN4llvm19RTDyldMemoryManager25getSymbolAddressInProcessERKSs llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (In reply to Markus Elfring from comment #3) > elfring@Sonne:~> c++filt > _ZN4llvm19RTDyldMemoryManager25getSymbolAddressInProcessERKSs > llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::basic_string<char, > std::char_traits<char>, std::allocator<char> > const&) I don't have any issues running glxinfo using swrast on a freshly updated TW. What does 'ldd /usr/lib64/dri/swrast_dri.so' give you? [ 53.890] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19 [ 54.109] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19 [ 54.109] (EE) open /dev/dri/card0: No such file or directory This looks definitely broken. Why can't the nouveau kernel module not be loaded? Still blacklisted or what? Make sure any NVIDIA component has been uninstalled and nouveau is no longer blacklisted. > How is the status for the installation source "ftp://download.nvidia.com/opensuse/42.1/x86_64/"? This is the repo for Leap, not Tumbleweed! > Please distinguish the affected details more for this bug report between my > difficulties with software evolution around Nvidia graphic drivers and the > current surprise for the Mesa library "swrast_dri.so". I shouldn't. They might be related. (In reply to Egbert Eich from comment #4) > I don't have any issues running glxinfo using swrast on a freshly updated TW. Do you get different effects from the software packages "Mesa-11.1.0-130.1" and "Mesa-11.1.1-535.1"? > What does 'ldd /usr/lib64/dri/swrast_dri.so' give you? linux-vdso.so.1 (0x00007ffc99bac000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fc8cdf8a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc8cdd6d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc8cdb68000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fc8cd93f000) libdrm_nouveau.so.2 => /usr/lib64/libdrm_nouveau.so.2 (0x00007fc8cd737000) libdrm_radeon.so.1 => /usr/lib64/libdrm_radeon.so.1 (0x00007fc8cd52a000) libdrm_amdgpu.so.1 => /usr/lib64/libdrm_amdgpu.so.1 (0x00007fc8cd322000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fc8cd113000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x00007fc8ccefb000) libLLVMAMDGPUCodeGen.so.3.7 => /usr/lib64/libLLVMAMDGPUCodeGen.so.3.7 (0x00007fc8ccc10000) libLLVMipo.so.3.7 => /usr/lib64/libLLVMipo.so.3.7 (0x00007fc8cc9a5000) libLLVMAMDGPUDesc.so.3.7 => /usr/lib64/libLLVMAMDGPUDesc.so.3.7 (0x00007fc8cc6a4000) libLLVMAMDGPUInfo.so.3.7 => /usr/lib64/libLLVMAMDGPUInfo.so.3.7 (0x00007fc8cc4a2000) libLLVMX86Disassembler.so.3.7 => /usr/lib64/libLLVMX86Disassembler.so.3.7 (0x00007fc8cc13e000) libLLVMX86CodeGen.so.3.7 => /usr/lib64/libLLVMX86CodeGen.so.3.7 (0x00007fc8cbd80000) libLLVMScalarOpts.so.3.7 => /usr/lib64/libLLVMScalarOpts.so.3.7 (0x00007fc8cba49000) libLLVMX86Desc.so.3.7 => /usr/lib64/libLLVMX86Desc.so.3.7 (0x00007fc8cb69f000) libLLVMMCDisassembler.so.3.7 => /usr/lib64/libLLVMMCDisassembler.so.3.7 (0x00007fc8cb497000) libLLVMX86Info.so.3.7 => /usr/lib64/libLLVMX86Info.so.3.7 (0x00007fc8cb295000) libLLVMMCJIT.so.3.7 => /usr/lib64/libLLVMMCJIT.so.3.7 (0x00007fc8cb089000) libLLVMExecutionEngine.so.3.7 => /usr/lib64/libLLVMExecutionEngine.so.3.7 (0x00007fc8cae6c000) libLLVMTarget.so.3.7 => /usr/lib64/libLLVMTarget.so.3.7 (0x00007fc8cac5e000) libLLVMRuntimeDyld.so.3.7 => /usr/lib64/libLLVMRuntimeDyld.so.3.7 (0x00007fc8caa13000) libLLVMBitReader.so.3.7 => /usr/lib64/libLLVMBitReader.so.3.7 (0x00007fc8ca7df000) libLLVMMC.so.3.7 => /usr/lib64/libLLVMMC.so.3.7 (0x00007fc8ca56f000) libLLVMCore.so.3.7 => /usr/lib64/libLLVMCore.so.3.7 (0x00007fc8ca148000) libLLVMSupport.so.3.7 => /usr/lib64/libLLVMSupport.so.3.7 (0x00007fc8c9e66000) libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007fc8c9ae4000) libm.so.6 => /lib64/libm.so.6 (0x00007fc8c97e6000) libc.so.6 => /lib64/libc.so.6 (0x00007fc8c9440000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fc8c9229000) libz.so.1 => /lib64/libz.so.1 (0x00007fc8c9013000) /lib64/ld-linux-x86-64.so.2 (0x000055e64b15e000) libLLVMAMDGPUAsmPrinter.so.3.7 => /usr/lib64/../lib64/libLLVMAMDGPUAsmPrinter.so.3.7 (0x00007fc8c8deb000) libLLVMAMDGPUUtils.so.3.7 => /usr/lib64/../lib64/libLLVMAMDGPUUtils.so.3.7 (0x00007fc8c8be9000) libLLVMAnalysis.so.3.7 => /usr/lib64/../lib64/libLLVMAnalysis.so.3.7 (0x00007fc8c8852000) libLLVMAsmPrinter.so.3.7 => /usr/lib64/../lib64/libLLVMAsmPrinter.so.3.7 (0x00007fc8c85e2000) libLLVMCodeGen.so.3.7 => /usr/lib64/../lib64/libLLVMCodeGen.so.3.7 (0x00007fc8c819d000) libLLVMSelectionDAG.so.3.7 => /usr/lib64/../lib64/libLLVMSelectionDAG.so.3.7 (0x00007fc8c7dd9000) libLLVMTransformUtils.so.3.7 => /usr/lib64/../lib64/libLLVMTransformUtils.so.3.7 (0x00007fc8c7b37000) libLLVMInstCombine.so.3.7 => /usr/lib64/../lib64/libLLVMInstCombine.so.3.7 (0x00007fc8c78a2000) libLLVMVectorize.so.3.7 => /usr/lib64/../lib64/libLLVMVectorize.so.3.7 (0x00007fc8c7649000) libLLVMipa.so.3.7 => /usr/lib64/../lib64/libLLVMipa.so.3.7 (0x00007fc8c7428000) libLLVMX86AsmPrinter.so.3.7 => /usr/lib64/../lib64/libLLVMX86AsmPrinter.so.3.7 (0x00007fc8c71e3000) libLLVMX86Utils.so.3.7 => /usr/lib64/../lib64/libLLVMX86Utils.so.3.7 (0x00007fc8c6fdd000) libLLVMProfileData.so.3.7 => /usr/lib64/../lib64/libLLVMProfileData.so.3.7 (0x00007fc8c6db9000) libLLVMObject.so.3.7 => /usr/lib64/../lib64/libLLVMObject.so.3.7 (0x00007fc8c6b43000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fc8c6918000) libLLVMMCParser.so.3.7 => /usr/lib64/../lib64/../lib64/libLLVMMCParser.so.3.7 (0x00007fc8c66ec000) libLLVMInstrumentation.so.3.7 => /usr/lib64/../lib64/../lib64/libLLVMInstrumentation.so.3.7 (0x00007fc8c648c000) (In reply to Stefan Dirsch from comment #5) > [ 54.109] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19 > [ 54.109] (EE) open /dev/dri/card0: No such file or directory > > This looks definitely broken. Thanks for your interest. > Why can't the nouveau kernel module not be loaded? I am unsure at the moment. > Still blacklisted or what? Make sure any NVIDIA component has been > uninstalled and nouveau is no longer blacklisted. > > > How is the status for the installation source "ftp://download.nvidia.com/opensuse/42.1/x86_64/"? > > This is the repo for Leap, not Tumbleweed! How big is the probability that the version for "Leap 42.1" will "accidentally" work also for my current software configuration? > > Please distinguish the affected details more for this bug report between my > > difficulties with software evolution around Nvidia graphic drivers and the > > current surprise for the Mesa library "swrast_dri.so". > > I shouldn't. They might be related. These software components are related to some degree because they can become occasionally responsible for the desired displays on my screens. You cannot rule out that nvidia packages installed for leap will also work for TW. But then TW kernel needs to be and remain kABI compatible to the one in Leap. I'm pretty sure sooner or later this kABI compatibily will break in TW. Please, really make sure there are no nvidia components installed any longer. Try this nvidia-installer --uninstall Search for "blacklist nouveau" in /etc/modprobe.d/* and remove it. Run 'mkinitrd' afterwards and reboot your kernel. (In reply to Stefan Dirsch from comment #7) > You cannot rule out that nvidia packages installed for leap will also work > for TW. Thanks that you can agree to this aspect around software chances for openSUSE Tumbleweed. > But then TW kernel needs to be and remain kABI compatible to the one in Leap. Can this information be appropriately expressed in RPM specifications? > I'm pretty sure sooner or later this kABI compatibily will break in TW. This might happen again. > Please, really make sure there are no nvidia components installed any longer. Sonne:~ # nvidia-installer --uninstall If 'nvidia-installer' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf nvidia-installer > Search for "blacklist nouveau" in /etc/modprobe.d/* and remove it. Sonne:~ # grep nouveau /etc/modprobe.d/50-blacklist.conf Nothing found. (In reply to Markus Elfring from comment #8) > > But then TW kernel needs to be and remain kABI compatible to the one in Leap. > > Can this information be appropriately expressed in RPM specifications? It is. Check 'rpm --requires -q kernel-<flavor>' | grep ksym > > Please, really make sure there are no nvidia components installed any longer. > > Sonne:~ # nvidia-installer --uninstall > If 'nvidia-installer' is not a typo you can use command-not-found to lookup > the package that contains it, like this: > cnf nvidia-installer > > > > Search for "blacklist nouveau" in /etc/modprobe.d/* and remove it. > > Sonne:~ # grep nouveau /etc/modprobe.d/50-blacklist.conf > > Nothing found. Ok. Seems your GPU isn't supported by nouveau driver then. (In reply to Stefan Dirsch from comment #9) > > Can this information be appropriately expressed in RPM specifications? > > It is. Check 'rpm --requires -q kernel-<flavor>' | grep ksym Which command variant should I try out once more? Is a "flavour" generally different from the item "kABI" (kernel application binary interface) according to my concerns for consistent software dependency resolution? https://wiki.ubuntu.com/KernelTeam/Stable_kABI > Seems your GPU isn't supported by nouveau driver then. I am curious if the desired device support will ever happen for my model by this approach. http://www.asus.com/Graphics-Cards/GT730SL2GD3BRK/ Corrected command: rpm --requires -q kernel-<flavor> | grep ksym <flavor> is likely "default" (check with 'rpm -qa|grep kernel') I would have GT730 expected to be supported. Apparently I'm wrong. (In reply to Stefan Dirsch from comment #11) > Corrected command: There are no data found so far for the item you might be looking for. Sonne:~ # rpm -q kernel-default --requires | grep ksym Sonne:~ # rpm -q kernel-desktop --requires | grep ksym Should I try another query out for my flavour? Damn. Of course I mean rpm --requires -q nvidia-gfxG04-kmp-default | grep ksym rpm --requires -q nvidia-gfxG04-kmp-desktop | grep ksym But since you're using TW, you cannot check this, since there are no such packages available. Example output: [...] ksym(default:wait_for_completion) = 6d0aba34 ksym(default:warn_slowpath_null) = 16305289 ksym(default:x86_dma_fallback_dev) = f218b897 (In reply to Stefan Dirsch from comment #13) > Damn. Of course I mean It seems that a few small communication difficulties can be distracting for an easier solution. > rpm --requires -q nvidia-gfxG04-kmp-desktop | grep ksym The suggested search pattern might be more clear now. > But since you're using TW, you cannot check this, But I guess that you (or even me eventually) can perform further interesting queries on the RPM package database. > since there are no such packages available. How many repositories should I add to my local list of installation sources so that the approximation of desired software dependencies will become better for my needs. > ksym(default:x86_dma_fallback_dev) = f218b897 Thanks for your excerpt. Corresponding open issues can be clarified by other discussions later. How are the chances to improve the reported situation around the shared library "swrast_dri.so" from a software package like "Mesa 11.1.1-535.1"? (In reply to Markus Elfring from comment #6) > (In reply to Egbert Eich from comment #4) > > I don't have any issues running glxinfo using swrast on a freshly updated TW. > > Do you get different effects from the software packages "Mesa-11.1.0-130.1" > and "Mesa-11.1.1-535.1"? You should use Mesa-11.1.1-537.1. Mesa-11.1.1-535.1 is for Leap 42.1. (In reply to Markus Elfring from comment #14) > (In reply to Stefan Dirsch from comment #13) > > Damn. Of course I mean > > It seems that a few small communication difficulties can be distracting for > an easier solution. > > > > rpm --requires -q nvidia-gfxG04-kmp-desktop | grep ksym > > The suggested search pattern might be more clear now. > > > > But since you're using TW, you cannot check this, > > But I guess that you (or even me eventually) can perform further interesting > queries on the RPM package database. > > > > since there are no such packages available. > > How many repositories should I add to my local list of installation sources > so that the approximation of desired software dependencies will become > better for my needs. > You don't want to add any more repositories but remove some instead. A repo for the NVIDIA binary only driver doesn't exist for TW. So you don't want to use any repo for it because in case it isn't working (and it may stop working with any TW update) you will have to fix the mess. The easiest would be to remove (or disable) the nvidia repo and run for i in $(rpm -qa | grep -i nvidia); do zypper rm $i; done > > > ksym(default:x86_dma_fallback_dev) = f218b897 > > Thanks for your excerpt. > > Corresponding open issues can be clarified by other discussions later. > > > How are the chances to improve the reported situation around the shared > library "swrast_dri.so" from a software package like "Mesa 11.1.1-535.1"? This problem doesn't exist on a regular TW system. As I've already stated in comment #4, I've tested this today with the latest TW update. I can run 'glxinfo' with the swrast driver without any problem. To me it looks like your installation is hosed - probably due to too many experiments you've done. It might require some knowledge to pull it 'straight' again so your best option might be to reinstall it from scratch. This really looks like a support issue and shouldn't be discussed here on bugzilla. (In reply to Egbert Eich from comment #15) > You should use Mesa-11.1.1-537.1. Mesa-11.1.1-535.1 is for Leap 42.1. Thanks for your interesting information. Did the software package "Mesa 11.1.1-537.1" became available two days ago? By which repository should the desired versions be provided usually? > You don't want to add any more repositories but remove some instead. Can you accept that the selection and maintenance of installation sources can become more dynamic because of different usage patterns? > This problem doesn't exist on a regular TW system. As I've already stated > in comment #4, I've tested this today with the latest TW update. Was my view for the published software situation accidentally outdated? (In reply to Markus Elfring from comment #16) > (In reply to Egbert Eich from comment #15) > > You should use Mesa-11.1.1-537.1. Mesa-11.1.1-535.1 is for Leap 42.1. > > Thanks for your interesting information. > > Did the software package "Mesa 11.1.1-537.1" became available two days ago? > By which repository should the desired versions be provided usually? > It became available together with Mesa-11.1.1-535.1. As I already said: Mesa-11.1.1-535.1 for Leap 42.1 Mesa-11.1.1-537.1 for TW. Just check the respective package repos on download.opensuse.org. > > You don't want to add any more repositories but remove some instead. > > Can you accept that the selection and maintenance of installation sources > can become more dynamic because of different usage patterns? Of course! But then you should be very careful what you do. If you do something wrong, your system will be messed up. > > This problem doesn't exist on a regular TW system. As I've already stated > > in comment #4, I've tested this today with the latest TW update. > > Was my view for the published software situation accidentally outdated? It's not a matter of views being 'outdated'. It is a matter of being wrong combining repos for different products: While it may work in many cases and thus not become obvious immediately, it may break in some cases where the ABI for the same API has changed between products. These ABI differences are impossible to map onto provides and requires. (In reply to Egbert Eich from comment #17) > Mesa-11.1.1-535.1 for Leap 42.1 > Mesa-11.1.1-537.1 for TW. > Just check the respective package repos on download.opensuse.org. How do you think about the view that users and system administrators can get from another listing? https://software.opensuse.org/package/Mesa openSUSE Tumbleweed official release 9.0.3 openSUSE Leap 42.1 official update 11.0.8 > It is a matter of being wrong combining repos for different products: Is such a mixture occasionally needed to achieve the desired resolution of advanced software dependencies? > While it may work in many cases and thus not become obvious immediately, I have got some hopes in this direction. > it may break in some cases where the ABI for the same API has changed between products. I guess that such events will need further considerations. > These ABI differences are impossible to map onto provides and requires. I have got an other opinion here. I imagine some possibilities to improve the maintenance of corresponding RPM specifications. |