nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA FreeBSD (http://www.nvnews.net/vbulletin/forumdisplay.php?f=47)
-   -   NVIDIA drivers / static LDT allocation? (http://www.nvnews.net/vbulletin/showthread.php?t=24054)

MrPolitics 01-26-04 02:22 AM

NVIDIA drivers / static LDT allocation?
Quite some time ago, the FreeBSD developers added checks in their code for process(es) that use static ldt allocation. The purpose of this was to determine which process(es) used this method, so that they could be updated to use dynamic ldt allocation (which is the only _safe_ way for proceses to get along with the new threading libraries, now default with FreeBSD 5.2-RELEASE). In other words, for those of us who use libthread or libkse rather than the depracated libc_r, the current NVIDIA drivers are potentially unstable.
My question is directed toward the NVIDIA developers: are there any plans in the works to modify / re-release new FreeBSD drivers that conform to the new dynamic LDT allocation mechanisms? I am a long-time NVIDIA customer, and part of the reason for this loyalty has to do with the top-notch support that NVIDIA has always shown toward the Open Source community. I understand the reasons behind binary-only drivers (protecting proprietary technology, etc.), but please, please, PLEASE stay current with the developments taking place within FreeBSD.

Thanks in advance for all your help,
Mike Schreckengost

------ CUT HERE -------
Warning: pid 736 used static ldt allocation.
See the i386_set_ldt man page for more info.

/-\ /-\
| |
| |

Please fix this problem... :)

ScoobyDoo 02-18-04 10:28 AM


I just spent hours and hours setting up FreeBSD 5.2, compiling gnome (12 hours of joy right there), setting up my workstation etc. only to find out that my application will not run because of the nvidia drivers.

I was looking forward to being able to develop my application, which makes extensive use of threads and cannot run on the old libc_r.so library (thread blocking issues), on FreeBSD. But it *needs* either libkse, or libthr to work.

Come on nVidia!

Just release some new drivers. Or a patch, or something. Even letting a patch find its way into the wild would be great.

zander 02-18-04 03:56 PM

It is my understanding that FreeBSD 5.3 is to comply with the static TLS mechanism specified by the ELF ABI employed on Linux/Solaris. Until this or a comparable static TLS mechanism is made available, the only options yielding adequate performance (i.e. single instruction access to TLS data) are the TLS mechanism currently employed by the NVIDIA driver (in combination with linuxthreads, not libc_r) or no TLS at all (i.e. a thread-unsafe driver). If your application requires a thread-safe OpenGL implementation, the latter obviously is no option at all.

There was a lengthy discussion leading up to the current developments on the FreeBSD threads mailing list, in case you're interested in details.

ScoobyDoo 02-18-04 09:44 PM

Yes, I had read about the situation, and while I will be happy when FreeBSD 5.3 arrives, with the changes, I do think it is nVidia's job to support FreeBSD releases, not FreeBSD's job to support nVidia releases.

In my view nVidia are not doing that great a job of supporting FreeBSD releases right now. They are way behind on driver versions.

On the other hand I am *really* glad to see they added what I hope is real vblank / vsync support on the latest Linux drivers. I hope this too makes its way to the new FreeBSD drivers when they arrive. I am presuming this fixes the problem whereby a call to glxSwapBuffers() would cause the calling process/thread to sit in a busy-loop using 100% of the CPU until the next v-blank / v-sync (That is fine for games programming where you dont usually care about multitasking with other applications, but for workstation OpenGL in desktop applications you cannot have a single application hog 100% CPU like that).

So I am happy in some ways, I just think they need to support FreeBSD a bit better (and not expect FreeBSD to support them).

zander 02-19-04 02:53 AM

I agree that the current situation is unsatisfying and doesn't show solid commitment; I expect there are good reasons why NVIDIA gives Linux precedence, however, and while I also agree that FreeBSD developments such as KSE should not be sacrificed in favor of third party software support, it would have been great if more thought had been given to static TLS (judging from various comments, the KSE developers see FreeBSD/NVIDIA users as a minority, with no good indication that there are native, multi-threaded OpenGL applications requiring a thread-safe libGL to begin with; I assume that the latter at least is a valid observation).

ScoobyDoo 02-20-04 01:29 AM

Well, I am feeling a bit better about the situation now than I was the other day :)

I took your advice and configured my application to use linuxthreads, and whilst that means I cannot use gdb on FreeBSD, it at least allows me to have it running and doing its thing.

It's funny... whenever I bring portable code to FreeBSD that (seemingly) works without fault on Linux, FreeBSD brings all the bugs to the surface. I just spent a day debugging various seg faults and all of them were potentially serious bugs that never seemed to trigger anything harmful in Linux (but would have at some point). I like FreeBSD for that, it isn't as forgiving as Linux with my code :)


shira 07-28-04 08:03 PM

Re: NVIDIA drivers / static LDT allocation?
I too am having problems with 5.2-CURRENT and the drivers. They work just fine to get the card up to resolution and displaying my desktop but anything related to openGL fails with that static ldt error.

I'm loyal to nvidia because the provide great linux drivers and decent BSD ones(versus ATi's cruddy linux ones an nonexistent freebsd ones). I'd really appreciate it if they could fix this soon. :)


shira 07-30-04 04:43 PM

Re: NVIDIA drivers / static LDT allocation?
Has anyone heard if nVidia is planning to fix this problem in the near future or is it back-burner?

All times are GMT -5. The time now is 03:49 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.