Hi,
I experience a crash of X server when I try to run something using openGL. I'm not sure if my approach is correct. I'm using nvidia drivers and I removed the Mesa packages from my system. After this there still seem to be some links left wich where installed by xorg-x11-devel-6.8.2-31
/usr/lib64/libGL.so /usr/lib/libGL.so
The point where they link to doesn't exist anymore so I linked the first one the nvidia provided one. There is however no 32bit one supplied with my driver. What do I need to do with the link /usr/lib/libGL.so ?
Regards, Marcel
On Tue, 2005-05-31 at 19:30 +0200, Marcel Janssen wrote:
Hi,
I experience a crash of X server when I try to run something using openGL. I'm not sure if my approach is correct. I'm using nvidia drivers and I removed the Mesa packages from my system.
You shouldn't remove the Mesa stuff from your system. You should also make sure you're using the livna nvidia packages - stay away from the nvidia binary modules, since they will not install properly on a Fedora system.
After this there still seem to be some links left wich where installed by xorg-x11-devel-6.8.2-31
/usr/lib64/libGL.so /usr/lib/libGL.so
The point where they link to doesn't exist anymore so I linked the first one the nvidia provided one. There is however no 32bit one supplied with my driver. What do I need to do with the link /usr/lib/libGL.so ?
This link is only needed to compile stuff against the GL library. The fact that it's not linked to anything is a bug, IMHO, but this isn't going to get fixed until X is modularized (I've asked). It should be linked to your Mesa libGL (which you should install back). However, that doesn't explain why your system crashes...
Do /sbin/ldconfig -p|grep libGL ...
On Tuesday 31 May 2005 19:45, Ivan Gyurdiev wrote:
You shouldn't remove the Mesa stuff from your system.
I've just put them back.
You should also make sure you're using the livna nvidia packages - stay away from the nvidia binary modules, since they will not install properly on a Fedora system.
I've used the ATrpms provided packages. Anyway, X still crashes when I run glxinfo.
Do /sbin/ldconfig -p|grep libGL ...
/sbin/ldconfig -p|grep libGL libGLw.so.1 (libc6,x86-64) => /usr/X11R6/lib64/libGLw.so.1 libGLw.so.1 (libc6) => /usr/X11R6/lib/libGLw.so.1 libGLcore.so.1 (libc6,x86-64) => /usr/lib64/nvidia-graphics-1.0-7174/libGLcore.so.1 libGLU.so.1 (libc6,x86-64) => /usr/X11R6/lib64/libGLU.so.1 libGLU.so.1 (libc6,x86-64) => /usr/lib64/libGLU.so.1 libGLU.so.1 (libc6) => /usr/X11R6/lib/libGLU.so.1 libGLU.so.1 (libc6) => /usr/lib/libGLU.so.1 libGLU.so (libc6,x86-64) => /usr/X11R6/lib64/libGLU.so libGLU.so (libc6,x86-64) => /usr/lib64/libGLU.so libGLU.so (libc6) => /usr/X11R6/lib/libGLU.so libGLU.so (libc6) => /usr/lib/libGLU.so libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia-graphics-1.0-7174/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/X11R6/lib64/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/X11R6/lib/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/libGL.so.1 libGL.so (libc6,x86-64) => /usr/X11R6/lib64/libGL.so libGL.so (libc6,x86-64) => /usr/lib64/libGL.so libGL.so (libc6) => /usr/X11R6/lib/libGL.so libGL.so (libc6) => /usr/lib/libGL.so
Regards, Marcel
On Tue, May 31, 2005 at 08:38:39PM +0200, Marcel Janssen wrote:
On Tuesday 31 May 2005 19:45, Ivan Gyurdiev wrote:
You shouldn't remove the Mesa stuff from your system.
I've just put them back.
You should also make sure you're using the livna nvidia packages - stay away from the nvidia binary modules, since they will not install properly on a Fedora system.
I don't know why you are saying this. I have installed the Nvidia drivers downloaded from Nvidia on all the fedoras and kernels up to and including the latest kernel on FC4test3 and they have worked every time. What goes wrong when you try the install? ------------------------------------------- Aaron Konstam Computer Science Trinity University telephone: (210)-999-7484
On 5/31/05, akonstam@trinity.edu akonstam@trinity.edu wrote:
What goes wrong when you try the install?
the fact that the installer from nvidia delibrately overwrites libraries from the mesa rpms.. leads to problems.. for users who aren't aware of what the installer is doing. The most problematic scenario is when users need to update their Xorg packages including the Mesa packages. The rpms overwrite the nvidia libs that overwrote the libs from rpm. If you aren't expecting that to happen, users can easily misinterpet the resulting errors with bugs in the xorg update packages. The other problematic scenario is if users are told to remove the mesa packages before doing the install of nvidia, subsequent usage of a package management tool like yum to grab an application that requires gl will pull the mesa libs back in to fill the deps. Again, users too easily assume that resulting problems is with the packages they just installed when it directly related to overwriting system libraries with non-rpm managed libraries. Nvidia packages, such as livna's.. avoid these issues by placing the nvidia libs in their own location instead of blowing away the libs from the mesa package.
-jef
On Tue, May 31, 2005 at 04:46:30PM -0400, Jeff Spaleta wrote:
On 5/31/05, akonstam@trinity.edu akonstam@trinity.edu wrote:
What goes wrong when you try the install?
the fact that the installer from nvidia delibrately overwrites libraries from the mesa rpms.. leads to problems.. for users who aren't aware of what the installer is doing. The most problematic scenario is when users need to update their Xorg packages including the Mesa packages. The rpms overwrite the nvidia libs that overwrote the libs from rpm. If you aren't expecting that to happen, users can easily misinterpet the resulting errors with bugs in the xorg update packages. The other problematic scenario is if users are told to remove the mesa packages before doing the install of nvidia, subsequent usage of a package management tool like yum to grab an application that requires gl will pull the mesa libs back in to fill the deps. Again, users too easily assume that resulting problems is with the packages they just installed when it directly related to overwriting system libraries with non-rpm managed libraries. Nvidia packages, such as livna's.. avoid these issues by placing the nvidia libs in their own location instead of blowing away the libs from the mesa package.
-jef
OK, I admit that you need to remove the Nvidia binaries before you install the mesa rpms , and then install the nvidia again. This is because the two packages have libraries with the same name. What is not clear to me is how if the nvidia rpms put the libraries in a differnt location how are they found when they are needed?
OK, I admit that you need to remove the Nvidia binaries before you install the mesa rpms , and then install the nvidia again. This is because the two packages have libraries with the same name. What is not clear to me is how if the nvidia rpms put the libraries in a differnt location how are they found when they are needed?
They are found, because the include line in ld.so.conf is parsed before the X11R6 line, leading to the nvidia path taking precedence (the nvidia path is /usr/lib/nvidia, added by /etc/ld.so.conf.d/nvidia)
What happens is, you are compiling against the Mesa libGL and headers, which, according to Jeff are more standards compliant than the nvidia one, and then you are linking against the nvidia library later.
I've used the ATrpms provided packages.
I have not used the ATrpms packages - I would recommend trying the ones from livna.org, since they're known to work.
Anyway, X still crashes when I run glxinfo.
Do you see any error messages? Anything in /var/log/*Xorg* that looks bad?
You should also run /sbin/lsmod to check whether the nvidia driver is loaded in the kernel.
On Wednesday 01 June 2005 01:18, Ivan Gyurdiev wrote:
Anyway, X still crashes when I run glxinfo.
Do you see any error messages? Anything in /var/log/*Xorg* that looks bad?
Yes.
/var/log/messages : May 30 19:04:05 superbit kernel: nvidia: no version for "struct_module" found: kernel tainted. May 30 19:04:05 superbit kernel: nvidia: module license 'NVIDIA' taints kernel. ----- I'm not sure if these have something to do with the Nvidia card :
May 30 19:04:05 superbit kernel: PCI: Cannot allocate resource region 0 of device 0000:03:00.0 May 30 19:04:05 superbit kernel: PCI: Cannot allocate resource region 3 of device 0000:05:00.0
/var/log/Xorg.0.log : (WW) NVIDIA(0): OpenGL is not fully supported in Xinerama (EE) NVIDIA(0): Failed to load GLX
I think the last one is serious, but I have no clue why it fails to load. One needs more info than just this, but where can I find it ?
You should also run /sbin/lsmod to check whether the nvidia driver is loaded in the kernel.
Yes, it is loaded.
Regards, Marcel
On Wednesday 01 June 2005 01:18, Ivan Gyurdiev wrote:
Do you see any error messages? Anything in /var/log/*Xorg* that looks bad?
Did a search and I found that it loaded the wrong libglx. I moved my libglx.a and created a link to libglx.so from the nvidia package.
Now it works and glxgears runs with about 7000FPS (don't know if that's good or bad for my card though, it's a PCIe 6600GT).
Regards, Marcel
On Wed, 2005-06-01 at 20:02 +0200, Marcel Janssen wrote:
On Wednesday 01 June 2005 01:18, Ivan Gyurdiev wrote:
Do you see any error messages? Anything in /var/log/*Xorg* that looks bad?
Did a search and I found that it loaded the wrong libglx. I moved my libglx.a and created a link to libglx.so from the nvidia package.
If you have to move things to make it work, then the packaging is broken, and that should be reported to ATrpms. I assume you haven't tried to install anything with the nvidia binary installer...
On Wed, Jun 01, 2005 at 08:01:05PM -0400, Ivan Gyurdiev wrote:
On Wed, 2005-06-01 at 20:02 +0200, Marcel Janssen wrote:
On Wednesday 01 June 2005 01:18, Ivan Gyurdiev wrote:
Do you see any error messages? Anything in /var/log/*Xorg* that looks bad?
Did a search and I found that it loaded the wrong libglx. I moved my libglx.a and created a link to libglx.so from the nvidia package.
If you have to move things to make it work, then the packaging is broken, and that should be reported to ATrpms. I assume you haven't tried to install anything with the nvidia binary installer...
ATrpms sets up proper linking to the desired nvidia libs unless you have installed multiple versions of the nvidia drivers (which the ATrpms packages deliberately allow you to, there have been too many instances, where some groups of nvidia users would perfer driver A due to better 3d accel, while others prefered driver B due to better overscan and vsync control, the endless battle of gamers vs. PVR addicts ...)
For this case ATrpms' nvidia packages have a tool called nvidia-graphics-switch which allows you to switch from one driver to another (with a X restart step in between) called
nvidia-graphics-switch
Call it w/o arguments to see which drivers are installed (and to get a usage information) and then call it with the driver you want to activate as its only argument. You need to do so as root.
BTW ATrpms tracks rawhide in its FC4 repo, so you should get nvidia kmdls for recent rawhide kernels with a very small delay.
HTH
On Thursday 02 June 2005 02:12, Axel Thimm wrote:
ATrpms sets up proper linking to the desired nvidia libs unless you have installed multiple versions of the nvidia drivers (which the ATrpms packages deliberately allow you to, there have been too many instances, where some groups of nvidia users would perfer driver A due to better 3d accel, while others prefered driver B due to better overscan and vsync control, the endless battle of gamers vs. PVR addicts ...)
As far as I can tell there's only one version of this package on my system. My system is a clean FC4test3 install on which I performed a yum upgrade.
For this case ATrpms' nvidia packages have a tool called nvidia-graphics-switch which allows you to switch from one driver to another (with a X restart step in between) called
nvidia-graphics-switch
I did use this.
Call it w/o arguments to see which drivers are installed (and to get a usage information) and then call it with the driver you want to activate as its only argument. You need to do so as root.
=> nvidia-graphics-switch Usage: /usr/sbin/nvidia-graphics-switch <driver> where <driver> is one of 7174
So, the problem I had is that X was using libglx.a which was in /usr/X11R6/lib64/modules/extensions/
Regards, Marcel
On Fri, Jun 03, 2005 at 09:40:30AM +0200, Marcel Janssen wrote:
On Thursday 02 June 2005 02:12, Axel Thimm wrote:
ATrpms sets up proper linking to the desired nvidia libs unless you have installed multiple versions of the nvidia drivers (which the ATrpms packages deliberately allow you to, there have been too many instances, where some groups of nvidia users would perfer driver A due to better 3d accel, while others prefered driver B due to better overscan and vsync control, the endless battle of gamers vs. PVR addicts ...)
As far as I can tell there's only one version of this package on my system. My system is a clean FC4test3 install on which I performed a yum upgrade.
For this case ATrpms' nvidia packages have a tool called nvidia-graphics-switch which allows you to switch from one driver to another (with a X restart step in between) called
nvidia-graphics-switch
I did use this.
Call it w/o arguments to see which drivers are installed (and to get a usage information) and then call it with the driver you want to activate as its only argument. You need to do so as root.
=> nvidia-graphics-switch Usage: /usr/sbin/nvidia-graphics-switch <driver> where <driver> is one of 7174
So, the problem I had is that X was using libglx.a which was in /usr/X11R6/lib64/modules/extensions/
That's taken care of by the
ModulePath "/usr/X11R6/lib/modules/extensions/nvidia"
statement in the supplied /etc/X11/xorg.conf.nvidia file. You need to explicitely copy this into its canonical place.
Check the package description, too:
# rpm -qi nvidia-graphics7174 The NVIDIA Accelerated Linux Driver Set brings both accelerated 2D functionality and high performance OpenGL support to Linux x86 with the use of NVIDIA graphics processing units (GPUs).
These drivers provide optimized hardware acceleration of OpenGL applications via a direct-rendering X Server and support nearly all NVIDIA graphics chips. TwinView, TV-Out and flat panel displays are also supported.
This package includes NVIDIA module for X11 and OpenGL libraries. Older RIVA 128 based video cards are supported by the server module shipping with XFree86/X.org, nv_drv.o.
You must also install a matching nvidia-graphics7174-kmdl rpm, if you want to utilize these drivers.
Add ModulePath "/usr/X11R6/lib/modules/extensions/nvidia" ModulePath "/usr/X11R6/lib/modules/extensions" ModulePath "/usr/X11R6/lib/modules" to `Section "Files"' /etc/X11/XF86Config and remove/comment the dri module.
Check /etc/X11/XF86config.nvidia or /etc/X11/xorg.conf.nvidia for an automatically generated config file.