GLX problem

simcox1 · 09-30-2005, 06:08 AM

On another thread I've posted that I've had problems with the X11 patches recently released. X wouldn't start at all and someone else also has this problem. They said it was due to the nvidia drivers. I've reinstalled and haven't installed the patches yet. I did email Pat and he replied that I should file a bug report if necessary but should first check any video card issues. It seems in my case (with a fx 5200 nvidia card) I need to make some changes to xorg.conf after installing these patches. Somethings messing X up anyway.

m0rg · 09-30-2005, 08:05 AM

Quote:

Originally posted by win32sux
yeah, seems like the kosher way of doing it is to pass this option to the nvidia installer when you execute it (i tried it and it works):

Code:

--force-tls=classic

Thanks it worked.

Any explanation about this?

PS:it seems that my cedega problem has been fixed too with this trick

win32sux · 09-30-2005, 12:44 PM

Quote:

Originally posted by m0rg
Thanks it worked.

Any explanation about this?

PS:it seems that my cedega problem has been fixed too with this trick

well, i know very little about this subject matter, but AFAICT it seems the issue is based on the change that was done to glibc on Fri May 13 12:51:03 PDT 2005... NPTL support was added to glibc, and even though kernel 2.6 will take advantage of that out of the box, kernel 2.4 will not - unless of course you use a patched 2.4 kernel, but slackware has ever used patched kernels...

one of patrick volkerding's goals for the glibc change was to do it in such a way that users would be able to switch between 2.4 and 2.6 (linux threads vs. native posix threads) kernels without hassle... anyways, the thing is that it seems like the nvidia installer was picking-up on the NPTL thing so it would compile the module with "--force-tls=new", instead of the "--force-tls=classic" which us 2.4 users needed... this is why it would work for people using 2.6, such as MagicMan... this is also why it worked for me when i replaced my glibc with the old (non-NPTL) one from slackware 10.1...

i started a thread about slackware's NPTL a few months ago over here in case you wanna chime-in:

http://www.linuxquestions.org/questi...hreadid=323277

here's what the nvidia installer says about the "--force-tls" option:

Quote:

--force-tls=[TLS TYPE]
NVIDIA's OpenGL libraries are compiled with one of two different thread local
storage (TLS) mechanisms: 'classic tls' which is used on systems with glibc
2.2 or older, and 'new tls' which is used on systems with tls-enabled glibc
2.3 or newer. The nvidia-installer will select the OpenGL libraries
appropriate for your system; however, you may use this option to force the
installer to install one library type or another. Valid values for [TLS
TYPE] are 'new' and 'classic'.

and here's the related part from the slackware changelog i am talking about:

Quote:

Fri May 13 12:51:03 PDT 2005
Here's the (I'm sure) long awaited upgrade to Slackware's glibc to
include support for NPTL (the Native POSIX Thread Library). NPTL
works with newer kernels (meaning 2.6.x, or a 2.4 kernel that is
patched to support NPTL, but not an unmodified "vanilla" 2.4 kernel
such as Slackware uses) to provide improved performance for threads.
This difference can be quite dramatic in some situations. For example,
a benchmark test mentioned on Wikipedia started 100,000 threads
simultaneously in about 2 seconds on a system using NPTL. The same
test using the old Linuxthreads glibc thread support took around 15
minutes to run! For most applications that do not start large numbers
of threads the difference will not be so large, but for high traffic
servers, databases, or anything that runs large numbers of threads,
NPTL should bring big improvements in scalability and performance.
For compatibility, the regular (linuxthreads) libraries are installed
in /lib, and the new NPTL versions are installed in /lib/tls. Which
versions are used depends on the kernel you're using. If it's newer
than 2.6.4, then the NPTL libraries in /lib/tls will be used. TLS
stands for "thread-local storage", and the directory name /lib/tls is
a little bit misleading since now both the linuxthreads and NPTL
versions of glibc are compiled with TLS support included (this is
needed to produce versions of tools such as ldconfig that can run under
either kind of system).

Getting all the kinks out of the build script to be able to get this to
work with either 2.4 or 2.6 kernels and be able to switch back and forth
without issues was quite a challenge, to say the least, and would have
been much harder without all the good advice and help folks sent in to
help me along and give me important hints. A special thanks goes to
Chad Corkrum for sending in some ./configure options that really helped
get the ball rolling here.

Here's some information about compiling things using these libraries --
by default, if you compile something the headers and shared libraries
used to compile and link the binary will be the linuxthreads versions,
but when you go to run the binary it will link to the NPTL library
versions (and you'll get the NPTL speed improvements) if you are running
an NPTL capable kernel. In rare cases you may find that an old binary
doesn't work right when run against the NPTL libs, and in this case you
can force it to run against the linuxthreads versions by setting the
LD_ASSUME_KERNEL variable to assume the use of a 2.4.x (non-NPTL) kernel
so that NPTL will not be used. An easy way to see the effect of this is
to try something like the following while using an NPTL enabled kernel:

volkerdi@tree:~$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7eaf000)
/lib/ld-linux.so.2 (0xb7feb000)

Note that in the example above, the binary is running against the NPTL
libraries in /lib/tls. Now, let's try setting LD_ASSUME_KERNEL:

volkerdi@tree:~$ LD_ASSUME_KERNEL=2.4.30 ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/libc.so.6 (0xb7eb2000)
/lib/ld-linux.so.2 (0xb7feb000)

As you can see, now the binary is running against the linuxthreads
version of glibc in /lib. If you find old things that won't work with
NPTL (which should be rare), this is the method you'll want to use to
work around it.

Now for a little note about compiling things. In most cases it will be
just fine to compile against linuxthreads and run against NPTL, and this
approach will produce the most flexible binaries (ones that will run
against either linuxthreads or NPTL.) However, in some cases you might
want to use some of the new functions that are only available in NPTL,
and to do that you'll need to use the NPTL versions of pthread.h and
other headers that are different and link against the NPTL versions of
the glibc libraries. To do this you'll need to add these compile flags
to your build in an appropriate spot:

-I/usr/include/nptl -L/usr/lib/nptl
(and link with -lpthread, of course)

Have fun, and report any problems to volkerdi 47 slackware d07 c0m.

a/glibc-solibs-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5 shared libs.
a/glibc-zoneinfo-2.3.5-noarch-1.tgz: Upgraded to time zone files from
glibc-2.3.5.
l/glibc-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5.
l/glibc-i18n-2.3.5-noarch-1.tgz: Upgraded to glibc-2.3.5 i18n files.
l/glibc-profile-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5 profile libs.

jape42 · 10-01-2005, 02:54 PM

hi Folks,

I had the same problem with glx + nvidia + slack 10.2 as described in
this thread. The --force-tls=classic worked for me as well glx can be loaded,
but now I'm having some problems with xvmc used by mythtv.

I get this from X when trying to watch TV:
2005-10-01 15:42:53.018 Connecting to backend server: 127.0.0.1:6543 (try 1 of 5)
2005-10-01 15:42:53.023 Using protocol version 15
2005-10-01 15:42:53.083 Using protocol version 15
2005-10-01 15:42:55.629 Opening audio device '/dev/dsp'.
2005-10-01 15:42:55.629 Opening OSS audio device '/dev/dsp'.
Using XvMC version: 1.0
XvMC found and using IDCT surface
2005-10-01 15:42:55.656 Using XV port 241
Error: API mismatch: the NVIDIA kernel module is version 1.0.7676, but
this library is version 1.0.7667. Please be sure that your kernel
module and all NVIDIA driver files have the same driver version.
Unable to create XvMC Context return status:11 BadAlloc
2005-10-01 15:42:56.883 Changing from None to WatchingLiveTV
2005-10-01 15:42:56.883 Decoder not alive, and trying to play..
2005-10-01 15:42:57.113 Changing from None to None

Any further thoughts? I guess I can go back to the non-glx configuration, but
would prefer not.

regards

jp

win32sux · 10-01-2005, 06:00 PM

Quote:

Originally posted by jape42
Error: API mismatch: the NVIDIA kernel module is version 1.0.7676, but
this library is version 1.0.7667. Please be sure that your kernel
module and all NVIDIA driver files have the same driver version.

so are you sure all your nvidia files have the same version?? did you do a complete uninstall of your previous driver before installing 7676 or did you use the upgrade feature of "nvidia-installer"?? if you used the upgrade feature, try doing a an uninstall instead... like, before installing 7676 do a:

Code:

nvidia-installer --uninstall

jape42 · 10-02-2005, 08:16 AM

Thanks for the suggestion. I had tried uninstalling with
./NVIDIA-Linux-x86-1.0-7667-pkg1.run --uninstall
but had no luck. In the end I just decided to revert back to 7667 and use the --force-tls=classic
suggested in this thread. It seems to be working. I can load glx and no errors when using xvmc.

Thanks

jp

batev · 10-04-2005, 06:27 AM

Is there anybody who was able to use the "RenderAccel" option without problems? My KDE always hangs.

win32sux · 10-04-2005, 12:31 PM

Quote:

Originally posted by batev
Is there anybody who was able to use the "RenderAccel" option without problems? My KDE always hangs.

in the kde bug tracker they seem to have determined it's an nvidia bug:

http://bugs.kde.org/show_bug.cgi?id=103389

auditek747 · 10-06-2005, 01:49 AM

Thanks to all who participated in this thread.

Code:

sh NVIDIA-Linux-x86-1.0-7676-pkg1.run --force-tls=classic

worked for me:

Slack 10.2
2.4.x kernel
MX4000 card

fixxxer0101 · 10-29-2005, 12:25 AM

I'm having the EXACT same problem tryint to use the Nvidia drivers with slackware 10.2. I used to be running 10.0 and the Nvidia drivers worked perfectly fine. I never ran into a problem. I've got a Geforce 4MX integrated on an Nforce2. When I was running 10.0 I could play Quake III, I could run directx games through wine and even play Doom 3. Now I can't startx when I have the Nvidia drivers installed and xorg.conf set to use them. I can us the "nv" driver just fine. I've been trying to google this subject and haven't found anything that actually helps. I have found references to rivafb being the problem but nothing explainging how to fix it. My problem seems to be with GLX as well.

Any ideas for me on this one?

win32sux · 10-29-2005, 01:09 AM

the --force-tls=classic didn't work for you??

fixxxer0101 · 10-30-2005, 01:21 PM

Sorry, I actually posted this on the wrong thread. There was another thread on this subject where there was no solution. I tried "sh NVIDIA-Linux-x86-1.0-7676-pkg1.run --force-tls=classic" after actually reading this thread and it worked. Thank you!!! Sorry that I didn't realize I was on the wrong thread, but I'm glad I found it as my problem is now resolved!

Thanks guys

ilredil · 11-08-2005, 09:29 PM

I'm having problems with getting the nvidia driver working with 2.6.13.4... but it worked fine with my 2.4 kernel. First it wouldn't compile, then I pulled the -k $(uname -r) trick. After that it compiled, but now it won't load. I tried uninstalling and re-compiling with --force-tls=classic. Then I decided to RTFM and found out what the --force-tls does. Output from `NVIDIA-Linux-x86-1.0-7676-pkg1.run -A`:

Quote:

--force-tls=[TLS TYPE]
NVIDIA's OpenGL libraries are compiled with one of two
different thread local storage (TLS) mechanisms: 'classic tls'
which is used on systems with glibc 2.2 or older, and 'new tls'
which is used on systems with tls-enabled glibc 2.3 or newer.
The nvidia-installer will select the OpenGL libraries
appropriate for your system; however, you may use this option
to force the installer to install one library type or another.
Valid values for [TLS TYPE] are 'new' and 'classic'.

Since I have glibc 2.3.4 I decided that I should uninstall and try again with --force-tls=new. It didn't help. I get the same message I got before...

Quote:

FATAL: Error inserting nvidia (/lib/modules/2.6.13.4/kernel/drivers/video/nvidia.ko): No such device

I compiled the kernel myself, but I loaded the same config file as the 2.4x kernel was using, so I don't think there's a problem there, but I'm not sure. If anyone has any suggestions let me know.

Thanks,
Adam

Samoth · 11-15-2005, 07:44 PM

i dont beleive you can use a 2.4 config file with a 2.6x kernel

ilredil · 11-15-2005, 11:46 PM

It looks like you can, but not just straight out of the box so to speak. According to this link https://www.redhat.com/archives/redh.../msg01115.html you can just copy the old config file to ./.config but then the command would be `make oldconfig`

Had I taken the time to RTFM, I might have figured this out earlier. I usually configure my kernel from the default values, but I decided that it'd make more sense to start with (basically) what I have now, and then go from there. Maybe this won't help at all, but it's worth a shot. I'm busy looking up info on some other stuff right now, but I'll give it a shot soon.