I'm having several problems with the nvidia drivers under 2.6.1. I have a Redhat 9.0 system with a brand new kernel. I've been using the nvidia drivers for about a year and a half now, and I've never really had any problems with them. Prior to the 2.6.1 upgrade, everything worked fine. In my XF86Config-4, dri and glcore are commented out and glx is active. I am using the NVIDIA agp instead of agpgart.

When I installed 4496 and applied all the necessary patches, I get no problems in X or with glx--glxgears runs at about 850 fps, which seems about right. But, I keep getting crashes and error messages like:
libGL.so.1: cannot handle TLS data
This doesn't happen to all 3d apps, but it does with quite a lot of them, all of which worked before.

When I installed 5328, i don't see that error pop up, BUT glx doesn't work at all--XFree86 doesn't load up glx properly, and I get an error message to that effect in the XFree86 log.

Has anyone had total success installing the nvidia drivers under 2.6.1? Success doing the same under RH 9? I feel like I'm taking crazy pills, and I'm thinking of ditching 2.6 for a while, but I'd like to see if I can sort this out, because I don't think I'd be the only one with these problems.

sorry for the double post, but I forgot to mention that I am using the nvidia driver patches from minion.de. I've also used a couple of the installers linked from there. No total success with any of them yet.

mikejedw, this is a link to a site that has recompiled Nvidia drivers, they work flawless.

http://www.sh.nu/download/nvidia/linux-2.6/

Yup, I've used those installers in addition to those I've managed to compile on my own, but I still have the same problems.

Do a "locate libGL" for me on the console. I have had a simillar problem one. It tured out the wrong versions of the gl library were being loaded. See if there is an dirctory called "/usr/lib/tls" on your box. If there is post the content of that dir.
I'm running slackware 9, with the 2.6.1 kernel and I was able to compile and load the nvidia drivers without any problems. But I had a simillar problem with another distribution. I resolved them by deleting some symbolic links and making some new ones.
You could try do move the gl libs in the /usr/lib directory to somewere like /usr/lib/libGL.old/* and making sym. links in the /usr/lib directory to the gl libs in the /usr/lib/tls directory, if it exists at all on your box.

Yeah, that's what I had thought. Here are my GL libs:

/usr/lib/libGL.so.1.0.4496
/usr/lib/tls/libGLcore.so.1.0.4496
/usr/lib/tls/libGL.so.1.0.4496
/usr/lib/tls/libGL.so.1
/usr/lib/tls/libGL.so
/usr/lib/tls/libGLcore.so.1
/usr/lib/libGLU.so.1
/usr/lib/libGL.so.1
/usr/lib/libGLcore.so.1.0.4496
/usr/lib/libGL.so
/usr/lib/libGLcore.so.1
/usr/lib/libGLU.so

So I move the libs at /usr/lib away and replace them with the ones from /usr/lib/tls, but I'm still getting:
libGL.so.1: cannot handle TLS data
which seems really odd since I specifically dropped in the tls libs, but whatever. I get the problem even when I reboot the machine and restart the X server.

This stuff is drivin' me frickin' crazy.

Okey, this is why I told you to move the Gl libs in the /usr/lib directory, instead of deleting them. If I would be mistaken there wouldne't be any seriouse damage. I was mistaken so here is what you do:
After some googling I found out that the libs in the /usr/lib/tls dir were the ones that are being using while they are not supposed to. Move the libs that were in the /usr/lib directory back to /usr/lib, and then move the libs in the /usr/lib/tls directory somewere else. Now, in the the tls directory, make symbolic links to the libs in the /usr/lib/ directory.
Sorry for the misguiding earlier.

AHA!!! Brilliant!

I think it's working now (I'm logging in to my machine at home via ssh, but I'm not getting the libGL error anymore, just the usual complaint about not having a connection to X). Whew!

No worries about the copying of the libGL.so files. I've borked my machine so many times, I've grown very accustomed to making back-ups and back-ups of back-ups whenever I shuffle libraries around. The fix you suggested was easy to do.

I'll check it all out when I get home to make sure everything is as it should be, but I'm very optimistic. Now I'm fully upgraded to the 2.6.1 kernel. Woohoo!

Do post back to report if every thing is working now.

I'm having a very similar problem, this time on a Debian system.
I don't know what tls is, and I don't have a /usr/lib/tls directory.

First: What's the difference between glx and GLcore? does one depend on the other? Because on startx I'm getting:

...

(--) PCI:*(1:0:0) NVidia unknown chipset (0x0253) rev 163, Mem @ 0xfd000000/24, 0xe8000000/27, 0xf4480000/19
(WW) Warning, couldn't open module GLcore
(EE) Failed to load module "GLcore" (module does not exist, 0)

...

(II) Module glx: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.4496
...

(WW) NVIDIA(0): Option "UseFBDev" is not used
(II) [GLX]: Initializing GLX extension

Fatal server error:
Caught signal 11. Server aborting


This morning, I finally got X working, but without 3d accel - I've since messed with the symlinks described above so that everything the nv_check troubleshooting script checks for:
/usr/X11R6/lib/modules/extensions/libglx.so
/usr/lib/libGL.so
/usr/lib/libGLcore.so.1

exist and are symlinked to the right .so.1.0.4496 files, which is the version I'm using.
The script gives me one line I don't understand:

Checking /usr/lib/libGL.so...
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40073000)
Checking /usr/lib/libGLcore.so.1...

which leads me to believe this may be the problem with GLcore not loading, but I don't know how to troubleshoot it.

X ran just fine when it couldn't load glx, so I'm assuming if I comment out the load "glx" in my X config, it'll work again - but I want 3d accel, dammit! :P

Any ideas? Please ask if I've left out any relevant information - I'll provide it happily.

--Rounan

Did you do everything mentioned here:
http://home.comcast.net/~andrex/nvid...ian/index.html
?

Let us know, and we'll work from there. I vaguely remember seeing some stuff about debian and glx in my search for an answer. Might have been on minion.de.

Yes, that guide is how I built and installed the drivers.

I found a section in the fine print at the end of the guide that noted glx may not work properly if the nvidia-glx package was installed under a 2.4 kernel and run under a 2.6 kernel - my case.
The solution is to:
dpkg-reconfigure nvidia-glx

Under the new kernel.
I did.
I get the same error, this time with:

XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.

after the "please submit bugs to ..."

At the bottom. I can't remember if that was there the first time.

I also found a line in the nvidia-kernel README that says glx is known not to play well with the Riva framebuffer device - I had this in my kernel as a module because I didn't understand what it was when I made the .config file.
It was a module, and wasn't loaded, so I don't think that's the issue... but I'm currently recompiling the kernel, just in case. I'll let you know if that fixes the problem.

Also, I removed the "GLcore" line from my xconfig, as recommended by a readme - I'm still interested in knowing what the difference between glcore and glx is, though.

--Rounan

EDIT: Recompiled kernel without Riva framebuffer. no change, same errors. On a side note, I can't startx unless I'm root. I know this is just a chmod fix, but what am I chmod 'ing, and where?

The fix schatoor recommended worked perfectly on my RH 9.0 system. Awesome!

As for Rounan's problem, I'm pretty much stumped. I don't think I've seen those kinds of errors before in any of the pages I sifted through to fix my issue.

After some further poking around, I added a testing apt source, and did
#apt-get update && apt-get upgrade
to get some newer versions of stuff.
I even went out on a limb and updated nvidia-glx to the unstable version, to see if that helped - and it gave me the tls libraries you folks mentioned earlier, so that's good. I symlinked the tls libGL*.so.1 files in tls to libgl*.so.1.0.4496 in /usr/lib, and then to /usr/lib/tls, both with the same result:

Now, instead of crapping out with an error, it hangs like so:

----------------------------------------------
XFree86 Version 4.2.1.1 (Debian 4.2.1-12.1 20031003005825 james@nocrew.org) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 October 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.21-rc1-ac1-cryptoloop i686 [ELF]
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Thu Jan 15 12:00:15 2004
(==) Using config file: "/etc/X11/XF86Config-4"

Skipping "/usr/X11R6/lib/modules/fonts/libspeedo.a:spencode.o": No symbols found
(II) [GLX]: Initializing GLX extension

---------------------------------------------------

Now, I'm logging in remotely by ssh, so I can't tell for sure if I magically have an X console at home... but since that message is considerably shorter than standard, and doesn't do things like initialize a monitor or video card, I'm assuming not.

Any ideas? I'm uneasy about upgrading to unstable versions of X, or anything really, in case it borks things irreperably.

I'm using version 4496 of the nvidia drivers, as I've heard 4640 gives lower performance and 5398 is pretty much crap. Should I try 4640? Should I give up and install Mandrake again?

Any help would be MUCH appreciated.

--Rounan

Well the thing I dislike about debian is that they pretty much use old software. Why the hell is xfree version 4.2.1.1 being used when you have 4.3 that is alraigdy been out for monthes? Not that you can do any thing about that of couse. here is a dude with pretty much the same issue. Though the problem wasn't resolved in that thread.
Go home nd post the entire error message. We will take it from there.