Hi all,
I have just installed the latest nVidia driver (version IA32 x86-1.0-6106) with the Fedora 2 kernel 2.6.6-1.435 on an i686 athlon (1.3 Ghz Thunderbird). I jumped to test the new config (to sum it up : Fedora 2 kernel 2.6.6-1.435, nVidia driver x86-1.0-6106, athlon 1.3 Ghz Thunderbird, GeForce 4 Ti 4200, RAM 768 Mo, Asus A7V133 with NorthBridge Via KT133A) with the ultimate benchmark (at least to that proc generation) Quake 3 (version 1.32b) ! End result : it works but it's hardly playable, as it swaps every 10 sec. The system did not show that kind of behavior with Fedora 1 and 2.4 kernels (with the corresponding nVidia drivers and of course XFree86). So my questions are : has anyone observed the same behavior, and what component should I blame for it (the kernel, the nVidia driver, Xorg..) ?
Thanks,
On Sun, 2004-07-04 at 12:35, Alexandre Van Haecke wrote:
I jumped to test the new config (to sum it up : Fedora 2 kernel 2.6.6-1.435, nVidia driver x86-1.0-6106, athlon 1.3 Ghz Thunderbird, GeForce 4 Ti 4200, RAM 768 Mo, Asus A7V133 with NorthBridge Via KT133A) with the ultimate benchmark (at least to that proc generation) Quake 3 (version 1.32b) ! End result : it works but it's hardly playable, as it swaps every 10 sec. The system did not show that kind of behavior with Fedora 1 and 2.4 kernels (with the corresponding nVidia drivers and of course XFree86). So my questions are : has anyone observed the same behavior, and what component should I blame for it (the kernel, the nVidia driver, Xorg..)
I can't play Quake 3 either although not for the same reason as you. I have a GeForce4 440 Go graphics card and the latest (6106) NVidia driver installed on FC2 with kernel 2.6.6-1.435.2.3. Tux Racer, Chromium, the OpenGL X Screensavers, and Unreal Tournament 2004 Demo are all absolutely fine and play/work as expected. However, in Quake 3 the 3D rendering is all messed up, and everything looks "blocky" -- screenshot here:
http://www.dzr-web.com/q3shot.png
Any ideas what might be wrong?
Best, Darren
It's an easy one : you must have some libraries left corresponding to the mesa driver (the "nv" driver). I'm sending you a script that should check out your config for the nvidia driver. You have to create a symbolic link from Xorg.conf to XF86Config before running it (it was designed for previous releases). Hopefully the script should indicate you where are the old mesa libraries : remove them and everything should work ok. If you're in doubt remove them anyway and rerun the nvidia installer... (which I would rerun anyway). If you do not exactly want to run an unknown script (can't blame you) :
ldconfig -v | grep libGL | grep -v libGLU
on the command line (as root) Here, it is :
[root@Titanic root]# ldconfig -v | grep libGL | grep -v libGLU libGLw.so.1 -> libGLw.so.1.0 libGL.so.1 -> libGL.so.1.0.6106 libGLcore.so.1 -> libGLcore.so.1.0.6106
In your case you should see conflicting libraries (for GL or GLcore), to remove them :
locate <name of the library>
and once you have the full path :
rm <full_path/name_of_the_library>
And 3 D rendering in quake should now be ok.
Le mar 06/07/2004 à 18:32, D. D. Brierton a écrit :
On Sun, 2004-07-04 at 12:35, Alexandre Van Haecke wrote:
I jumped to test the new config (to sum it up : Fedora 2 kernel 2.6.6-1.435, nVidia driver x86-1.0-6106, athlon 1.3 Ghz Thunderbird, GeForce 4 Ti 4200, RAM 768 Mo, Asus A7V133 with NorthBridge Via KT133A) with the ultimate benchmark (at least to that proc generation) Quake 3 (version 1.32b) ! End result : it works but it's hardly playable, as it swaps every 10 sec. The system did not show that kind of behavior with Fedora 1 and 2.4 kernels (with the corresponding nVidia drivers and of course XFree86). So my questions are : has anyone observed the same behavior, and what component should I blame for it (the kernel, the nVidia driver, Xorg..)
I can't play Quake 3 either although not for the same reason as you. I have a GeForce4 440 Go graphics card and the latest (6106) NVidia driver installed on FC2 with kernel 2.6.6-1.435.2.3. Tux Racer, Chromium, the OpenGL X Screensavers, and Unreal Tournament 2004 Demo are all absolutely fine and play/work as expected. However, in Quake 3 the 3D rendering is all messed up, and everything looks "blocky" -- screenshot here:
http://www.dzr-web.com/q3shot.png
Any ideas what might be wrong?
Best, Darren
--
D. D. Brierton darren@dzr-web.com www.dzr-web.com Trying is the first step towards failure (Homer Simpson) =====================================================================
On Tue, 2004-07-06 at 19:15, Alexandre Van Haecke wrote:
It's an easy one : you must have some libraries left corresponding to the mesa driver (the "nv" driver).
I should note that I didn't install the nvidia driver via NVidia's official installer, but rather was testing out the beta rpm.livna.org RPMs (see http://bugzilla.livna.org/show_bug.cgi?id=83#c33).
I'm sending you a script that should check out your config for the nvidia driver. You have to create a symbolic link from Xorg.conf to XF86Config before running it (it was designed for previous releases). Hopefully the script should indicate you where are the old mesa libraries : remove them and everything should work ok.
Well, I read through the script carefully before running it. When I ran it said:
Checking /usr/X11R6/lib/modules/extensions/libglx.a... You seem to have a libglx.a file in your /usr/X11R6/lib/modules/extensions directory. This will most likely cause a conflict with the current drivers. Remove or rename this file, then run this script again.
However
$ rpm -qf /usr/X11R6/lib/modules/extensions/libglx.a xorg-x11-6.7.0-2
So this isn't a file from mesa, but from xorg-x11 itself. I am not happy with the idea of deleting or renaming that file, and anyway it will just be replaced the next time an upgrade for xorg-x11 comes out. I use rpm for managing everything on my system, which is why I didn't install the driver using NVidia's installer. I'd rather determine exactly what the problem is with Quake 3 and submit that information back the livna.org packagers.
If you're in doubt remove them anyway and rerun the nvidia installer... (which I would rerun anyway). If you do not exactly want to run an unknown script (can't blame you) :
ldconfig -v | grep libGL | grep -v libGLU
on the command line (as root) Here, it is :
[root@Titanic root]# ldconfig -v | grep libGL | grep -v libGLU libGLw.so.1 -> libGLw.so.1.0 libGL.so.1 -> libGL.so.1.0.6106 libGLcore.so.1 -> libGLcore.so.1.0.6106
In your case you should see conflicting libraries (for GL or GLcore), to remove them :
locate <name of the library>
and once you have the full path :
rm <full_path/name_of_the_library>
And 3 D rendering in quake should now be ok.
The above seems like a good way for possibly determining what the conflict is, but I can't decipher what it is trying to tell me:
# ldconfig -v | grep libGL | grep -v libGLU ldconfig: Cannot stat /usr/lib/nvidia/tls/libGLcore.so: No such file or directory ldconfig: Cannot stat /usr/lib/nvidia/tls/libGL.so: No such file or directory libGLcore.so.1 -> libGLcore.so.1.0.6106 libGL.so.1 -> libGL.so.1.2 libGLw.so.1 -> libGLw.so.1.0 libGL.so.1 -> libGL.so.1.2
When I look in /usr/lib/nvidia/tls/ I see two broken symlinks:
# ls -al /usr/lib/nvidia/tls/ total 12 drwxr-xr-x 2 root root 4096 Jul 6 10:39 . drwxr-xr-x 3 root root 4096 Jul 6 10:39 .. lrwxrwxrwx 1 root root 21 Jul 6 10:39 libGLcore.so -> libGLcore.so.1.0.6106 lrwxrwxrwx 1 root root 17 Jul 6 10:39 libGL.so -> libGL.so.1.0.6106 lrwxrwxrwx 1 root root 25 Jul 6 10:38 libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.6106 -rwxr-xr-x 1 root root 1836 Jul 6 10:35 libnvidia-tls.so.1.0.6106
Note that the first two symlinks point to non-existent files.
# rpm -qa | grep nvidia | xargs rpm -ql | grep libGL /usr/lib/nvidia/libGL.so /usr/lib/nvidia/libGLcore.so /usr/lib/nvidia/tls/libGL.so /usr/lib/nvidia/tls/libGLcore.so /usr/lib/nvidia/libGL.so.1 /usr/lib/nvidia/libGL.so.1.0.6106 /usr/lib/nvidia/libGL.so.1.2 /usr/lib/nvidia/libGLcore.so.1.0.6106 /usr/lib/nvidia/tls/libGL.so.1 /usr/lib/nvidia/tls/libGL.so.1.2
I've no idea if the above could be the source of the Quake 3 problem, or why it would affect Quake 3 but not Unreal Tournament, Tux Racer, Chromium or any of the OpenGL X screensavers.
Does any of the above mean anything to anyone here?
Best, Darren
Le mar 06/07/2004 à 21:44, D. D. Brierton a écrit :
Well, I read through the script carefully before running it. When I ran it said:
Checking /usr/X11R6/lib/modules/extensions/libglx.a... You seem to have a libglx.a file in your /usr/X11R6/lib/modules/extensions directory. This will most likely cause a conflict with the current drivers. Remove or rename this file, then run this script again.However
$ rpm -qf /usr/X11R6/lib/modules/extensions/libglx.a xorg-x11-6.7.0-2So this isn't a file from mesa, but from xorg-x11 itself. I am not happy with the idea of deleting or renaming that file, and anyway it will just be replaced the next time an upgrade for xorg-x11 comes out. I use rpm for managing everything on my system, which is why I didn't install the driver using NVidia's installer. I'd rather determine exactly what the problem is with Quake 3 and submit that information back the livna.org packagers.
As indicated in post "nvidia users: about the xorg-x11 update" : "The xorg-x11 update re-installs the un-accellerated GL libraries" and "If you used nvidia's installer for the 6106 driver, you will need to re-run the installer after the new xorg-x11 update." So yes : any update from xorg-x11 must be followed by a nvidia driver install, through the installer or the rpm (I don't know : I use the installer).
The above seems like a good way for possibly determining what the conflict is, but I can't decipher what it is trying to tell me:
# ldconfig -v | grep libGL | grep -v libGLU ldconfig: Cannot stat /usr/lib/nvidia/tls/libGLcore.so: No such file or directory ldconfig: Cannot stat /usr/lib/nvidia/tls/libGL.so: No such file or directory libGLcore.so.1 -> libGLcore.so.1.0.6106 libGL.so.1 -> libGL.so.1.2 libGLw.so.1 -> libGLw.so.1.0 libGL.so.1 -> libGL.so.1.2 When I look in /usr/lib/nvidia/tls/ I see two broken symlinks:
# ls -al /usr/lib/nvidia/tls/ total 12 drwxr-xr-x 2 root root 4096 Jul 6 10:39 . drwxr-xr-x 3 root root 4096 Jul 6 10:39 .. lrwxrwxrwx 1 root root 21 Jul 6 10:39 libGLcore.so -> libGLcore.so.1.0.6106 lrwxrwxrwx 1 root root 17 Jul 6 10:39 libGL.so -> libGL.so.1.0.6106 lrwxrwxrwx 1 root root 25 Jul 6 10:38 libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.6106 -rwxr-xr-x 1 root root 1836 Jul 6 10:35 libnvidia-tls.so.1.0.6106
Note that the first two symlinks point to non-existent files.
# rpm -qa | grep nvidia | xargs rpm -ql | grep libGL /usr/lib/nvidia/libGL.so /usr/lib/nvidia/libGLcore.so /usr/lib/nvidia/tls/libGL.so /usr/lib/nvidia/tls/libGLcore.so /usr/lib/nvidia/libGL.so.1 /usr/lib/nvidia/libGL.so.1.0.6106 /usr/lib/nvidia/libGL.so.1.2 /usr/lib/nvidia/libGLcore.so.1.0.6106 /usr/lib/nvidia/tls/libGL.so.1 /usr/lib/nvidia/tls/libGL.so.1.2
Well : I would check (or correct manually since it is not the case ) that in /usr/lib/nvidia you have :
libGLcore.so.1 -> libGLcore.so.1.0.6106 libGLcore.so.1.0.6106 libGL.so -> libGL.so.1 libGL.so.1 -> libGL.so.1.0.6106 libGL.so.1.0.6106
You have a libGL.so.1.2 that needs to go... For the /usr/lib/nvidia/tls directory, I don't know why you get another libGL.so.* and libGLcore.so.* (libnvidia-tls is ok), they should also go...and at least the libGL.so.1.2 (a guess). Granted, I don't really know what the rpm installation does, removing your libraries might wreck your system etc... But with the nvidia installer as a last resort, you can take the chances. If everything breaks, you can always run the installer.
-
avhaecke＠club-internet.fr -
D. D. Brierton