Hey All linuxers,
I'm getting a lot of segfaults in gem from the latest nvidia drivers, (with gemCVS) is anyone else having these issues? What versions are known to work well with Gem?
Here is the gdb trace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14242)] 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1 (gdb) where #0 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1
Thanks Ben
Hey All linuxers,
I'm getting a lot of segfaults in gem from the latest nvidia drivers, (with gemCVS) is anyone else having these issues? What versions are known to work well with Gem?
hi ben,
maybe your problems are because there is a problem with glibc, TLS and the nvidia glx drivers, it all depends on what u are running on. i recently downgraded my testing to stable again because of this issue (poor linux mans solution :-). if u google for "nvidia TLS bug" u might get a picture. i m using latest drivers with debian stable without complains. you still might try to compile the nvidia drivers with --force-tls=no or classic ? i cant recall (look it up with ./sh NVIDIA-whatever -A) one reason i also downgraded again was that all the sudden my feedback patches got really slow (but was just visible by snapping 1024*1024) , why and how and what i had no time to investigate. best
erich
Here is the gdb trace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14242)] 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1 (gdb) where #0 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1
Thanks Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Oh damn.
suse9 is using glibc 2.3.2-88 so indeed it sounds like the culprit. All the references I found for the "TLS" bug were for older driver versions (1.0-4xxx) And I'm currently looking around for more info or nvidia's stance on the subject. One fix I saw was to install the libs by hand (I don't know where to put them!) or set this env variable:
LD_PRELOAD="/lib/tls/libpthread.so.0 /lib/tls/libc.so.6"
of course my libpthread is in /usr/lib and libc is in /lib/, I dunno whats about seperate versions of these for tls...
What version of glibc did you downgrade to? Anyone using 2.3.2-xx with nvidia drivers above 4xxx?
This from nvidia:
Q: Some OpenGL applications (like Quake3 Arena) crash when I start them on Red Hat Linux 9.0.
A: Some versions of the glibc package shipped by Red Hat that support TLS do not properly handle using dlopen() to access shared libraries which utilize some TLS models. This problem is exhibited, for example, when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain at least glibc-2.3.2-11.9 which is available as an update from Red Hat.
I assume 2.3.2-11.9 is older than 2.3.2-88?
blech.
B.
Hey All linuxers,
I'm getting a lot of segfaults in gem from the latest nvidia drivers, (with gemCVS) is anyone else having these issues? What versions are known to work well with Gem?
hi ben,
maybe your problems are because there is a problem with glibc, TLS and the nvidia glx drivers, it all depends on what u are running on. i recently downgraded my testing to stable again because of this issue (poor linux mans solution :-). if u google for "nvidia TLS bug" u might get a picture. i m using latest drivers with debian stable without complains. you still might try to compile the nvidia drivers with --force-tls=no or classic ? i cant recall (look it up with ./sh NVIDIA-whatever -A) one reason i also downgraded again was that all the sudden my feedback patches got really slow (but was just visible by snapping 1024*1024) , why and how and what i had no time to investigate. best
erich
Here is the gdb trace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14242)] 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1 (gdb) where #0 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1
Thanks Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
did the problem disappear after compiling them with --force-tls=classic ?
e ---------------------------------- http://randomseed.org
On Tue, 13 Jan 2004 ben@ekran.org wrote:
Oh damn.
suse9 is using glibc 2.3.2-88 so indeed it sounds like the culprit. All the references I found for the "TLS" bug were for older driver versions (1.0-4xxx) And I'm currently looking around for more info or nvidia's stance on the subject. One fix I saw was to install the libs by hand (I don't know where to put them!) or set this env variable:
LD_PRELOAD="/lib/tls/libpthread.so.0 /lib/tls/libc.so.6"
of course my libpthread is in /usr/lib and libc is in /lib/, I dunno whats about seperate versions of these for tls...
What version of glibc did you downgrade to? Anyone using 2.3.2-xx with nvidia drivers above 4xxx?
This from nvidia:
Q: Some OpenGL applications (like Quake3 Arena) crash when I start them on Red Hat Linux 9.0.
A: Some versions of the glibc package shipped by Red Hat that support TLS do not properly handle using dlopen() to access shared libraries which utilize some TLS models. This problem is exhibited, for example, when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain at least glibc-2.3.2-11.9 which is available as an update from Red Hat.
I assume 2.3.2-11.9 is older than 2.3.2-88?
blech.
B.
Hey All linuxers,
I'm getting a lot of segfaults in gem from the latest nvidia drivers, (with gemCVS) is anyone else having these issues? What versions are known to work well with Gem?
hi ben,
maybe your problems are because there is a problem with glibc, TLS and the nvidia glx drivers, it all depends on what u are running on. i recently downgraded my testing to stable again because of this issue (poor linux mans solution :-). if u google for "nvidia TLS bug" u might get a picture. i m using latest drivers with debian stable without complains. you still might try to compile the nvidia drivers with --force-tls=no or classic ? i cant recall (look it up with ./sh NVIDIA-whatever -A) one reason i also downgraded again was that all the sudden my feedback patches got really slow (but was just visible by snapping 1024*1024) , why and how and what i had no time to investigate. best
erich
Here is the gdb trace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14242)] 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1 (gdb) where #0 0x40f7ac77 in _nv000332gl () from /usr/lib/tls/libGLcore.so.1
Thanks Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
ben@ekran.org wrote:
Oh damn.
What version of glibc did you downgrade to? Anyone using 2.3.2-xx with nvidia drivers above 4xxx?
i am using debian with nvidia 1.0.4496 (so this is not "above" but "greater of equal" 4xxx) and libc6-2.3.2.ds1 (that's how it is called on debian) which provides glibc-2.3.2.ds1 when installing on a kernel-2.6-based system i am asked whether i want to use TLS and i do want to do that. afterwards it plays fine. (the debian.changelog of nvidia-glx says something about enabled runtime detection of TLS/2.6)
mfg.as.dr IOhannes