Go Back   nV News Forums > Linux Support Forums > NVIDIA FreeBSD

Newegg Daily Deals

Reply
 
Thread Tools
Old 01-26-04, 03:22 AM   #1
MrPolitics
Registered User
 
Join Date: Jan 2004
Location: Erie, PA
Posts: 2
Unhappy 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...
__________________
FreeBSD: The power to serve.
MrPolitics is offline   Reply With Quote
Old 02-18-04, 11:28 AM   #2
ScoobyDoo
Registered User
 
ScoobyDoo's Avatar
 
Join Date: Nov 2002
Posts: 11
Default

Agghhh.

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.
ScoobyDoo is offline   Reply With Quote
Old 02-18-04, 04:56 PM   #3
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

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.
zander is offline   Reply With Quote
Old 02-18-04, 10:44 PM   #4
ScoobyDoo
Registered User
 
ScoobyDoo's Avatar
 
Join Date: Nov 2002
Posts: 11
Default

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).
ScoobyDoo is offline   Reply With Quote
Old 02-19-04, 03:53 AM   #5
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

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).
zander is offline   Reply With Quote
Old 02-20-04, 02:29 AM   #6
ScoobyDoo
Registered User
 
ScoobyDoo's Avatar
 
Join Date: Nov 2002
Posts: 11
Default

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

ScoobyDoo is offline   Reply With Quote
Old 07-28-04, 09:03 PM   #7
shira
Registered User
 
Join Date: Jul 2004
Posts: 2
Default 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

Last edited by shira; 07-28-04 at 11:02 PM.
shira is offline   Reply With Quote
Old 07-30-04, 05:43 PM   #8
shira
Registered User
 
Join Date: Jul 2004
Posts: 2
Default 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?
shira is offline   Reply With Quote

Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
NVIDIA Drivers Receive Windows 8 Certification News Archived News Items 0 06-01-12 06:30 AM
Radeon 9700 not all that? sancheuz Other Desktop Graphics Cards 200 10-12-02 10:31 PM
Nvidia Stereo Drivers Soudontsay NVIDIA Windows Graphics Drivers 2 08-26-02 11:48 AM
nvidia drivers in a motherboard with AGP 1.0 (motherboard MVP3+) knocker NVIDIA Linux 1 08-19-02 02:57 AM
NVIDIA 2960 Drivers & RH 7.3 W/2.4.18-5 XASCompuGuy NVIDIA Linux 6 08-02-02 12:53 PM

All times are GMT -5. The time now is 04:35 PM.


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