PDA

View Full Version : Official FreeBSD drivers


Pages : 1 [2] 3 4 5 6 7 8

BrianzaMan
11-24-02, 03:20 PM
Hi all, I'm new, I have some questions about these new Nvidia FREEBSD drivers.

I have recompiled my Kernel succesfully, and installed the drivers too.But I have two problems :

The X loading time is incredibly long!!About 3-4 minutes(that can seem a short time when u read it, but when u are at your desktop waiting X load is stressing) , tuxracer (one of my prefered games!!!:D:D) doesn't load, the screen turns black and than I'm returned to desktop at a resolution of 640x480 (I 'think) , so I have to restart X (another time 3-4 minutes) .UT2003 anytimes restart my PC when I start it (It happen any time after a crash of X when I try to restart it) and always in UT the audio is unsync with the video.

Is normal, anyone know how to solve these problems?

Thanks

Config :

PIII 1000
ASUS CUV4X-EA
Creative/MSI Geforce 3 Ti200
CMI8738 Audio chip

Bye

BrianzaMan
11-24-02, 03:23 PM
Originally posted by volt
Yes folks it's here:

http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203



STEP 4: Check dependencies
The dependencies are listed in the README. Please note that the NVIDIA driver set requires XFree version 4.2 or greater. If this is not available on your linux distribution, please go to the XFree86 web site (www.xfree86.org). FreeBSD -STABLE, version 4.7 or later is also required.
].


FreeBSD is a Linux distribution?:D

Byez

AlphaChild
12-03-02, 03:08 AM
Originally posted by shooter
Wow, removing DRI allows my system to run glx twice without crashing and rebooting. Thanks AlphaChild!

- J no problem. glad that i could be of help

as for my problem, i changed my configuration to an Athlon 1.67GHz with a GF2MX, and all my problems are solved. it must be a configuration issue with the P2's and the TNT's. i guess that we will just have to wait and see until the next FreeBSD drivers are released

PS. FreeBSD is NOT a Linux. the only thing they really share in common is that they are both excellent free unix-like operating systems. Linux is better when it comes to support from commercial apps. FreeBSD is a more mature system tho. i think i'll finish there before i start raving

simple3
12-08-02, 09:42 AM
I can't wait to try these drivers, I just finished upgrading to the latest -STABLE, and can't wait for this XFree upgrade to finish. This is a huge step forward towards making FreeBSD a viable desktop machine for many more people. For anyone having trouble I found a site (http://www.thirteenandtwo.org/nvidia/faq.html) with some information on specific problems with games and how to work around them.

I believe he was just trying to point out a typo in the README. it refers to "your linux distribution" then goes on to mention FreeBSD 4.7-STABLE is required, seemingly implying FreeBSD is a linux distribution which it is clearly not.

halber_mensch
12-08-02, 08:20 PM
I thought this seemed to be tied to the nvidia kernel module - specifically the internal AGP driver, as both myself and my friend (both running AMD systems) have had the same problems on FreeBSD (myself) and Linux (friend).

I recompiled the the kernel module, commenting out the line in nv-freebsd.h that reads:

#undef USE_OS_AGP_GART

So far I've been able use multiple GL contexts with fewer problems. I've gotten a few seg faults and hangs though. What is very wierd about this is that the kernel isn't even given a chance to panic, the system just fizzles.

And for those of you including DRI in your X configs, shame shame shame!

a123eng
12-10-02, 05:49 AM
Well, to be quite frank, I'm a kernel virgin. I've never recompiled my kernel before, and I'd like some instruction if possible. :) I don't want to get all the way through there and then end up putting the wrong thing in the wrong place and screwing it all up. I attempted it earlier this evening, but I didn't get anywhere. If someone could point me in the right direction or lend a hand I'd be grateful. Thanks.

AlphaChild
12-10-02, 06:39 PM
recompiling your kernel is one of the most sacred rites of passage in any *NiX environment. read chapter nine of the handbook (or i think it is nine). if you want to find out the guts of a kernel config file, check out /usr/src/sys/i386/conf/LINT. just catalog it through less, and edit your one in another terminal

anyway, one of the biggest problems that i have noted on my new system (my amd rig) is graphical corruption!!! being the puritian monk that i am (as i was labelled yesterday for using FreeBSD), i use Blackbox as my windowing manager. this, in turn, uses qt for the rendering of the 'windows' and system menus. when i try to load up the default system menu (right mouse button click), i scroll down, and the mouseovers are not working properly. i think 'what the!...'. i then move my mouse a little further down... and system crash. i cant even kill the X server. so whenever i see that problem, i just exit out of the X server and restart X. i have never had this problem under Linux, and even under FreeBSD, the P2 systems have no issues. in my opinion, it has to be an AMD problem. GLX still works perfectly, but these occasional crashes are not particularly welcome... but knowing the perfectionists that are on the nvidia driver teams, i am sure that they will fix it either next release, or over the next few releases

*patiently waits for Detonator 4 to be released on Linux and BSD*

halber_mensch
12-11-02, 01:02 AM
Recompiling your kernel is a rite of passage, as well as a doorway to much goodness. and on top of that, the guys at Berkeley made a pretty easy system of it too.

I'd say you should go ahead and get up to the stable release while you're doing all this, but you could just use sysinstall to get your distribution source. But that won't help you with the nvidia drivers. So I'll tell you what you need to know to get updated to 4.7-stable.

With FreeBSD, you'll need to grab a source tree. You can get the 4.7-STABLE source most easily by using cvsup. There are example supfiles for use with cvsup under /usr/share/examples/cvsup/ . Just look at the stable-supfile, and of course read the handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html will tell you all about synchronizing your source.

The most hair-raising part of the upgrade process is running mergemaster. YOU MUST PAY ATTENTION TO WHAT IS HAPPENING. You've also got to know what files are special for you in /etc. For instance - letting mergemaster overwrite your current /etc/master.passwd will kill your added user accounts and reset your root password. That sucks. But if you're upgrading from 4.4-RELEASE, the /etc/master.passwd file does need to be updated with certain daemon user entries. You'll have to merge these sorts of files interactively to include all the right lines. It's a little wierd at first, but becomes natural after a while.

And if you backup your etc directory, you're in good shape if you screw up. Also, if your custom kernel doesn't work, don't freak out! You can stop the FreeBSD bootstrapper and tell it to load an old kernel. In / you'll see a few different kernels, most likely, like kernel, kernel.old, kernel.GENERIC, and possibly more. If your kernel freaks out, just type load kernel.old at the boot loader, and voila, you're using the last kernel that was installed. If you always keep a generic kernel in the root directory, you'll have a good kernel you can always fall back on.

a123eng
12-11-02, 06:16 PM
Excellent. Thanks much for the help.

AlphaChild
12-14-02, 10:55 AM
shutdown now ;
make -j4 buildworld && ;
make kernconf="NAME-OF-KERNEL" buildkernel && ;
make kernconf="NAME-OF-KERNEL" installkernel && ;
make installworld ;

after the beauty known as cvsup and a custom kernel config written up, those five lines will pretty much get your custom kernel going (i wrote it as an executable script about 9 months ago and not seen it since, so i may have gotten its order wrong - it is also late at night in australia, and like every computer nerd, i am very sleep deprived)

with the detonator 4 drivers for the IA32 (build 4191), IA64 (build 4050) and AMD64 (build 4180) linux platforms already released, i am waiting for the FreeBSD revision to come out as well (at least build 4191 - maybe higher). i cant wait to get my Linux XSI license working under BSD

incandenza
12-14-02, 05:35 PM
First off, props to NVidia for the FreeBSD support. Everything's working great, with one exception: it's taking forever for my X server to start up. Looking at the logfile, it appears that X is trying a ton of different video modes on startup (even though I only specify one in my XF86Config), most of which are out of my monitor's hsync range. Is this what's taking so long, and if so, how do I tell X to knock it off?

Thanks!

a3c
12-16-02, 03:32 AM
hi! i've ecounter small problem. when my X starts everything is ok (from log -logverebose 5) but screen just flash three or four times and after that it stay in text mode and is filled with random characters (moustly with smielies:-) Last line in log is Setting resolution to 800x600 (or like).
i have GEFORCE 2 MX400 (agp) and kinetiz zb7 (VIA chipset).
i think i've met all critherias: SYSVSHM and USER_LDT option enabled in my kernel, correct versions of X, server, client and libs. i also have Linux ABI compatiability module loaded.
installation (make setup) is w/o errors. after reboot module is loaded and there is line starting nvidia... in dmesg. i've use XF86Config.sample (i changed only Monitor section and BoardName;-).
but startx + few moments and screen unreadeabe (it seems to shift all characters). only way out is ctrl+alt+delete... thank you

amistry
12-17-02, 03:37 AM
I'm having trouble getting my tv-out to display. If I remove the ConnectedMonitor "crt,tv" line I can start the X-Server, but there is no tv-out.
The /var/log/XFree86.0.log says that it can only detect one display with the ConnectedMonitor line removed, eventhough both the s-video cable and crt are plugged in.
/var/log/XFree86.0.log (with ConnectedMonitor line removed):
....
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="The XFree86 Project"
compiled for 4.2.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.5
(**) NVIDIA(0): Depth 16, (--) framebuffer bpp 16
(==) NVIDIA(0): RGB weight 565
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Option "NvAGP" "1"
(**) NVIDIA(0): Option "IgnoreEDID" "1"
(**) NVIDIA(0): Option "TVStandard" "NTSC-M"
(**) NVIDIA(0): Option "TVOutFormat" "SVIDEO"
(**) NVIDIA(0): Option "TwinView"
(**) NVIDIA(0): Option "TwinViewOrientation" "RightOf"
(**) NVIDIA(0): Option "SecondMonitorHorizSync" "60"
(**) NVIDIA(0): Option "SecondMonitorVertRefresh" "60"
(**) NVIDIA(0): Option "MetaModes" "640x480,640x480;"
(**) NVIDIA(0): Forcing SVIDEO output
(**) NVIDIA(0): Use of NVIDIA internal AGP requested
(**) NVIDIA(0): Ignoring EDIDs
(**) NVIDIA(0): TV Standard string: "NTSC-M"
(**) NVIDIA(0): TwinView enabled
(--) NVIDIA(0): Linear framebuffer at 0xD0000000
(--) NVIDIA(0): MMIO registers at 0xDC000000
(==) NVIDIA(0): Write-combining range (0xdc601000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xa0000,0x10000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc680000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc601000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc681000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc0c0000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc682000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc603000,0x1000) was already clear
(==) NVIDIA(0): Write-combining range (0xdc683000,0x1000) was already clear
(--) NVIDIA(0): VideoRAM: 65536 kBytes
(--) NVIDIA(0): Display 0: maximum pixel clock at 8 bpp: 350 MHz
(--) NVIDIA(0): Display 0: maximum pixel clock at 16 bpp: 350 MHz
(--) NVIDIA(0): Display 0: maximum pixel clock at 32 bpp: 300 MHz
(II) NVIDIA(0): Not probing EDIDs.
(WW) NVIDIA(0): Only one display device connected; disabling TwinView.
(II) NVIDIA(0): Monitor0: Using hsync range of 30.00-70.00 kHz
(II) NVIDIA(0): Monitor0: Using vrefresh range of 50.00-90.00 Hz
....

XF86Config:
Section "ServerLayout"
Identifier "TwinViewTV"
# Screen "TVScreen"
Screen "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
ModulePath "/usr/X11R6/lib/modules"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
FontPath "/usr/X11R6/share/AbiSuite/fonts"
EndSection

Section "Module"
Load "extmod"
Load "xie"
Load "pex5"
Load "glx"
Load "dbe"
Load "record"
Load "xtrap"
Load "speedo"
Load "type1"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "Auto"
Option "Device" "/dev/sysmouse"
Option "ZAxisMapping" "4 5"
Option "Buttons" "5"
EndSection

Section "Monitor"
Identifier "TV"
HorizSync 30-50
VertRefresh 60
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
Option "DPMS"
HorizSync 30-70
VertRefresh 50-90
EndSection

Section "Device"
Identifier "Card0"
Driver "nvidia"
VendorName "NVidia"
BoardName "GeForce2 MX/MX 400"
Option "TwinView"
Option "IgnoreEDID" "1"
Option "SecondMonitorHorizSync" "60"
Option "SecondMonitorVertRefresh" "60"
Option "TVOutFormat" "SVIDEO"
Option "MetaModes" "640x480,640x480;"
Option "TwinViewOrientation" "RightOf"
Option "TVStandard" "NTSC-M"
Option "NvAGP" "1"
Option "ConnectedMonitors" "crt,tv"
BusID "PCI:1:0:0"
EndSection

Section "Screen"
Identifier "TVScreen"
Device "Card0"
Monitor "TV"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "800x600" "640x480"
EndSubSection
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 16
SubSection "Display"
Depth 1
EndSubSection
SubSection "Display"
Depth 4
EndSubSection
SubSection "Display"
Depth 8
EndSubSection
SubSection "Display"
Depth 15
EndSubSection
SubSection "Display"
Depth 16
# Modes "1152x864" "1024x768" "800x600" "640x480"
Modes "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 24
EndSubSection
EndSection

Snow
12-17-02, 06:35 PM
I've got, per dmesg, a "NVidia Riva Ultra Vanta TNT2 graphics accelerator." I was able to get it up and running just fine under Nvidia's driver, but I can't seem to get to 1600x1200@24bpp anymore. It seems to default to 800x600, and with some serious fiddling I can get to 1600x1200@8bpp. Using the "IgnoreEDID" option got me some rather Christmasy colors, but an otherwise non-functional display, so that didn't seem to be the way to go.

The curious thing is that, under XFree86-4's "nv" driver, I could run 1600x1200@24 no problem. In fact, that's what I'm running as I write this.

I can post any additional details needed, but I guess for starters, is anyone successfully running this driver at 1600x1200@24?

Thanks in advance.

jamie
12-18-02, 09:05 PM
I'm running 1600 x 1200 x 24 on my old Diamond Viper V550 (tnt 2)

There are problems:

1) It takes about 2 minutes for x-windows to start (with nv it was instant!)
2) Some of the opengl stuff is iffy with KDE, which I solved by reinstalling the original drivers (therefore sacrificing openGL support for now)

However, apart from that, it's stable at 1600 x 1200 x 24

You are welcome to see my config files, but I didn't do anything out of the ordinary..

/etc/X11/XF86Config: (non relevent bits snipped)


Section "Module"
Load "bitmap"
Load "xie"
Load "pex5"
Load "glx"
Load "dri"
Load "dbe"
Load "record"
Load "extmod"
Load "type1"
Load "freetype"
EndSection

Section "ServerFlags"
Option "AllowDeactivateGrabs" "on"
Option "AllowClosedownGrabs" "on"
EndSection

Section "Monitor"
Identifier "Monitor0"
HorizSync 30.0 - 110.0
VertRefresh 50.0 - 160.0
EndSection

Section "Device"
Identifier "Card0"
Driver "nvidia"
VendorName "NVIDIA"
BoardName "RIVA TNT"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" "640x400" "512x384" "400x300" "320x240" "320x200" "256x224"
EndSubSection
EndSection

dmesg:

nvidia0: <RIVA TNT> mem 0xe6000000-0xe6ffffff,0xe4000000-0xe4ffffff irq 11 at device 0.0 on pci1

pciconf:

nvidia0@pci1:0:0: class=0x030000 card=0x48201092 chip=0x002010de rev=0x04 hdr=0x00
vendor = 'Nvidia Corporation'
device = 'Riva TNT GUI+3D Accelerator [NV4]'
class = display
subclass = VGA

Hope this helps,
Jamie

Snow
12-19-02, 11:24 AM
Actually, after fiddling with it for a while, it seems that I was overdriving the video card with the nv driver and never realized it.

The nvidia driver reports that the card has a maximum clock of 215MHz or so. In configuring my display, I hadn't used a range, but rather had used the specific frequencies listed in a table that came with the monitor to get 1600x1200 at 85Hz, 106.3h & 85v. The table also specifies that this requires a clock of 229.5MHz. So that's why it wasn't working under the nvidia driver. Oops.

I fell back to specifying a range (30-121h & 48-160v) and the nvidia driver came up just fine at 1600x1200, albeit only at 75Hz. And my Xvideo drivers were now working. Unfortunately, video playback was mangled by some really nasty artifacts. Which is fine, I guess, since I wasn't wild about running at 75Hz anyway.

Oh well. I'll be replacing this 21" tube with a 19" LCD that runs 1280x1024 soon enough anyway. I'll try it all again then.

AlphaChild
12-20-02, 09:06 AM
side topic: when are the detonator 4 drivers coming out on FreeBSD? no rush, but detonator 3 are not quite as ... you know ;)

midekra
01-11-03, 05:40 PM
Is there a reason for not including these headers in the FreeBSD package or do t
hey just forgot to? Can I just copy the headers for Linux and expect them to wor
k?

AlphaChild
01-16-03, 02:20 PM
jaime, i had a quick look at your xf86config file, and from that quick look, i see you are loading the dri module. that is a big no-no. you get rid of the dri, and that should hopefully solve your problems. the reason is because the nvidia drivers use their own separate rendering system, and loading the dri module causes a conflict. i hope that helps

icon001
01-23-03, 02:39 PM
running the following:

FreeBSD 4.7
XFree86-4.2.0_1,1
XFree86-libraries-4.2.1_1
XFree86-Server-4.2.1_3
XFree86-clients-4.2.1_1
NVIDIA FreeBSD Driver 1.0-3203

with

Section "Module"
Load "bitmap"
Load "extmod"
Load "dbe"
Load "type1"
Load "glx"
Load "freetype"
EndSection

Section "Device"
Identifier "Device"
Driver "nvidia"
VendorName "NVIDIA"
BoardName "GeForce3"
EndSection

and a Geforce3 card w/ 128m

Made all the changes and everything works, boots and runs fine - but for some reason beyond my limited knowledge I cannot run in 32bit mode. 8,16,24 are no issue
But trying 32bit mode the system returns an error saying the "nvidia" drivers don''t support this mode.
I even tried running the XF86Config scripts both text and graphical and neither one offers me the option of using 32bit modes...?

Any ideas?

midekra
01-26-03, 01:05 PM
Originally posted by icon001
Made all the changes and everything works, boots and runs fine - but for some reason beyond my limited knowledge I cannot run in 32bit mode. 8,16,24 are no issue
But trying 32bit mode the system returns an error saying the "nvidia" drivers don''t support this mode.
I even tried running the XF86Config scripts both text and graphical and neither one offers me the option of using 32bit modes...?


That's because depth 32 visuals do not exist. Older XFree86 (up to 3.X) had a depth 32 visual which was actually a depth 24 visual with a different bits per pixel.

XFree86 4 supports the same modes as 3.X did, only it does so in a more sensible way. "depth" refers to the number of bits of active color information. This value is one of 1/2/4/8/15/16/24 There is no such thing as 32 bit color . The bit width of a pixel on the other hand, is now refered to as "fbbpp", and is 8/16/24/32 depending on the mode and visual.

Just remove the 32 depth subsection and it will work fine, and it will work just as you want it to.

icon001
01-26-03, 10:53 PM
Originally posted by midekra
That's because depth 32 visuals do not exist. Older XFree86 (up to 3.X) had a depth 32 visual which was actually a depth 24 visual with a different bits per pixel.

XFree86 4 supports the same modes as 3.X did, only it does so in a more sensible way. "depth" refers to the number of bits of active color information. This value is one of 1/2/4/8/15/16/24 There is no such thing as 32 bit color . The bit width of a pixel on the other hand, is now refered to as "fbbpp", and is 8/16/24/32 depending on the mode and visual.

Just remove the 32 depth subsection and it will work fine, and it will work just as you want it to.

Ok then, that explains it, I appreciate the reply at least I know what's happening now. :type:

ArturBac
01-31-03, 01:34 PM
TO BE ABLE TO COMPILE FOR
FreeBSD 5.0-CURRENT with srccvs AFTER #1: Fri Jan 30 CET 2003
DO THAT

FIX THIS FOR GCC3.2.1

ADD TO ./src/nv-freebsd.h
AFTER #include <sys/sysctl.h>
AT LINE 38
/*FREEBSD5.0 ONLY FIX*/
#include <sys/proc.h>
#include <sys/filedesc.h>
#include <sys/conf.h>

DaLinuxNut
02-06-03, 11:25 PM
Has anyone sucessfully used the fix on 5.0-RELEASE? I'm itching to put FBSD on my system :D

DaLinuxNut
02-10-03, 08:42 AM
All you have to do is change this in src/nv-freebsd.h:

#if __FreeBSD_version >= 500000
#error This driver does not support FreeBSD 5.0/-CURRENT!
#elif __FreeBSD_version < 470000
#error This driver requires FreeBSD 4.7 or later!
#endif

To this:
/*
#if __FreeBSD_version >= 500000
#error This driver does not support FreeBSD 5.0/-CURRENT!
#elif __FreeBSD_version < 470000
#error This driver requires FreeBSD 4.7 or later!
#endif
*/

Those who are C programmers will notice that it's merely commenting it out. Follow the regular instructions in doc/README, and happy fragging with the daemon unleased. :D