Linux高手请进来!~!有急事求救!!!!!!!在线等待..........

Linux Drivers for NVIDIA TNT/TNT2/GeForce/Quadro Chips
Version 0.9-5
README and FAQ
Last updated: 30-Aug-2000

--------------------------------------------------------------------------------

Contents

1.0 Preface

2.0 Introduction
2.1 Requirements
2.2 Components
2.3 Package files

3.0 XFree86 4.0.1
3.1 Acquire the source/binaries
3.2 Installation
3.3 Setup (30-Aug-2000)

4.0 NVIDIA kernel driver
4.1 Description
4.2 Installation
4.2.1 Default RPM
4.2.2 Build from SRPM
4.2.3 Build from tar file

5.0 NVIDIA X/OpenGL (GLX) drivers
5.1 Description
5.2 Installation (02-May-2000)
5.3 Setup

6.0 Troubleshooting
6.1 XFree86 4.0.1(30-Aug-2000)
6.2 Kernel driver
6.3 X
6.4 OpenGL (27-Apr-2000)
6.5 Known Bugs (30-Aug-2000)
6.6 Troubleshooting some common applications (30-Aug-2000)

7.0 Operating Options(7-Jul-2000)
7.1 X driver
7.2 OpenGL

8.0 FAQ (27-Apr-2000)
8.1 Kernel problems (27-Apr-2000)
8.1.1 I can't build the kernel module! There's tons of compile errors! (27-Apr-2000)
8.1.2 I can't build your kernel module with the Linux 2.3.xx kernel (27-Apr-2000)
8.1.3 I get unresolved refs when I attempt to insmod the kernel module (27-Apr-2000)
8.2 Starting X
8.2.1 X fails to load, and claims there's 0kb of total video memory (27-Apr-2000)
8.3 OpenGL (27-Apr-2000)
8.3.1 OpenGL crashes when I start Quake or other apps (27-Apr-2000)
8.3.2 OpenGL is slow when I run XXX app (27-Apr-2000)

9.0 ChangeLog (07-Jun-2000)

--------------------------------------------------------------------------------

1.0 Preface
This driver set is the work of three partners: NVIDIA, SGI, and VA Linux Systems.
Contents

--------------------------------------------------------------------------------

2.0 Introduction
This driver set adds improved 2D functionality to the XFree86 4.0.1 X server as well as high performance OpenGL acceleration, AGP support, support for most flat panels, and 2D multiple monitor support.
2.1 Requirements
Hardware: NVIDIA TNT, TNT2, GeForce, or Quadro based graphics accelerator.  The NVIDIA NV1 and RIVA 128/128ZX chips are supported in the base XFree86 4.0.x install and are not supported by this driver set.
Software: Linux kernel >;= 2.2.12  XFree86 >;= 4.0.1
2.2 Components
This driver set is comprised of two major components: a kernel module, and XFree86 4.0.1 modules for 2D and 3D acceleration.  The 3D OpenGL acceleration supports both indirect and direct rendering for complete compatibility and performance. The current version of the drivers is 0.9-5.
2.3 Package files
There are two types of packages supported.  The simplest and best supported is the use of RPM packages.  For those of you who don't use/like RPMS, gzipped tar files are available as well.  If you run the shipping version of RedHat, currently 6.1, you can simply download the two RPMS that match your hardware configuration.  If you have another distribution, you can download the RPMS for the X/OpenGL modules and build your own RPM from an SRPM file. The required downloads will be one of the following:
NVIDIA_GLX-0.9-5.i386.rpm and NVIDIA_kernel-0.9-5.i386.rpm for RedHat uni-processor Linux
NVIDIA_GLX-0.9-5.i386.rpm and NVIDIA_kernel-smp-0.9-5.i386.rpm for RedHat multi-processor Linux
NVIDIA_GLX-0.9-5.src.rpm and NVIDIA_kernel-0.9-5.src.rpm for any 2.2.x Linux
NVIDIA_GLX-0.9-5.tar.gz and NVIDIA_kernel-0.9-5.tar.gz for any 2.2.x Linux

Contents

--------------------------------------------------------------------------------

3.0 XFree86 4.0.1
The X server required for this driver set is XFree86 version 4.0.1. This is still a relatively new release, and may be difficult to obtain easily.  We have found RPMS of XFree86-4.0.1 at: ftp://rawhide.redhat.com/rawhide/i386/RedHat/RPMS or you can download the tarballs of source and/or binaries for XFree86 from http://www.xfree86.org#currentrel.
3.1 Acquiring Source/Binaries
First, check with your distributions FTP site for easily installed binaries.  If you use RPMS, that would be your best bet for an easy installation.  As of this writing, RedHat 6.2 and Suse 6.4 should have RPMS for XFree86 4.0.x.  If RPMS are not available, you can check the XFree86 web site for pre-built binaries: www.xfree86.org.  If you still can't find binaries, then you will have to build your own from the sources.  Make sure you have a lot of disk space (and time).  The instructions for building the X server is beyond this document, but the included information with the X source should explain everything.
3.2 Installation
Installation with RPMS is fairly straightforward.  Use GnoRPM, Kpackage, or command line rpm to install the RPMS.  If using the downloaded binaries from XFree86, use their install script.  If you built your own binaries, install with 'make install'.  Under all circumstances, you will need to install the files as 'root'.
Most distributions now provide packages to allow you to update your machine to use XFree86 4.0.x instead of XFree86 3.3.x. If, however, you are running an older installation for which there is not a package, you can check with xfree86.org for information on updating XFree86.
3.3 Setup
Setup of XFree86 is a bit more difficult because all the nice graphical setups only work for version 3.x of XFree86 (this may change soon).  Until the setup programs are updated for XFree86 4.0.x, we would recommend using xf86config.  Although it is limited in functionality, it provides a working, basic XF86Config file.  Initially, set up the X server to load the NVIDIA Open-Source modules shipped with XFree86 4.0.x.  The module name is "nv". Getting the X server to load properly may take some tweaking of the XF86Config file.  Below is a device section generated by xf86config for an NVIDIA based card.
Note: currently released versions of XFree86 4.0.x DO NOT support the newer GeForce2 family of NVIDIA cards. This includes cards such as the GeForce2 GTS, the GeForce2 MX, and the GeForce2 Ultra. This has been fixed in XFree86's CVS repository, but will take a new release before binary distributions pick the support up. If you have one of these cards, you will need to skip attempting to run the "nv" driver at this point.

# Device configured by xf86config:
Section "Device"
Identifier  "MyCard"
Driver    "nv"
# VideoRam 32768
# Insert Clocks lines here if appropriate
EndSection
Video RAM and clocks are autodetected by the driver, so there is no need to set them in the XF86Config file.
At this point, you should have a running X, using the OSS nvidia drivers. Configuring X to use NVIDIA's officially supported drivers is covered below, in section 5.0.
Contents

--------------------------------------------------------------------------------

4.0 NVIDIA kernel driver
The kernel driver is the NVdriver file.  It is tightly coupled to the version and type (smp vs. non-smp, 2gig vs non, etc.) of Linux kernel installed on your computer.  We hope eventually to provide RPMS for all major Linux distributions.  If they are not yet available, it is an easy task to create your own.

Note: this is not the same kernel driver available elsewhere on this website.
4.1 Description
The kernel driver is responsible for managing the resources of the NVIDIA graphics accelerator chip.  It is a component utilized by all NVIDIA drivers, under different operating systems, that provides a consistent mechanism for hardware initialization, mode set, offscreen memory management, and exception handling. The kernel driver assists the display and OpenGL drivers in setup and then steps aside while they render directly to hardware.
4.2 Installation
Installation always requires that you be logged in as 'root'.
4.2.1 Default RPM
The default RPMS are built on RedHat 6.1 (or the most currently available version) for both smp and uniprocessor kernels.  Install the correct RPM for your kernel:
rpm -Uvh NVIDIA_kernel-0.9-5.i386.rpm
or
rpm -Uvh NVIDIA_kernel_smp-0.9-5.i386.rpm
4.2.2 Build from SRPM
Building your own custom RPM is quite easy.  All that's required is that you have the common build tools installed as well as the correct kernel header files for the kernel on your machine.  This is typically the case.  To install the buildable files use:
rpm -i NVIDIA_kernel-0.9-5.src.rpm
This will put the buildable files into the default RPM build directory. Something like /usr/src/redhat for RedHat distributions or /usr/src/packages for many others. As 'root', enter this directory and type:
rpm -ba SPECS/NVIDIA_kernel.spec
This will build an RPM for your machine and place the result in RPMS/i386/NVIDIA_kernel-0.9-5.i386.rpm. To install type:
rpm -Uvh RPMS/i386/NVIDIA_kernel-0.9-5.i386.rpm
IMPORTANT note for SMP machines: There is a report that linux kernel spinlocks (which are used by the kernel driver) are not compiled and linked correctly using versions of binutils prior to 2.9.5. Check your binutils version by 'size --version'. Make sure it is at least 2.9.5.
4.2.3 Build from tar file
If you think RPMS are for wimps, then installation from the tar file is straightforward as well. Untar the NVIDIA_kernel-0.9-5.tar.gz file and move into the build directory. Simply type 'make' to build the NVdriver kernel module. As 'root', run install.sh to install all the files and modifications. This is automatically done if you install the RPM.
IMPORTANT note for SMP machines: There is a report that linux kernel spinlocks (which are used by the kernel driver) are not compiled and linked correctly using versions of binutils prior to 2.9.5. Check your binutils version by 'size --version'. Make sure it is at least 2.9.5.
Contents

--------------------------------------------------------------------------------

5.0 NVIDIA X/OpenGL (GLX) drivers
The XFree86 4.0.1 modules for 2D and 3D graphics and video acceleration are included in the NVIDIA_GLX package.
5.1 Description
The 2D module, nvidia_drv.o, is similar to the nv_drv.o module available with the XFree86 4.0.1 release but uses the kernel driver and has hooks for interaction with the 3D modules.  The 3D modules provide a conformant, direct rendering implementation of OpenGL.
Multiple monitors are supported for 2D rendering, for a multiple screen configuration, as well as for a Xinerama single screen that spans multiple monitors. This is a work in progress, however. Please see the Bugs section, below, for more details.

5.2 Installation
Installation always requires you to be logged in as 'root'.
IMPORTANT! This RPM may have some conflicts with some Mesa rpms. Because there are multiple Mesa rpm distributions and there is no standard in naming of the Mesa rpms, libraries, and their location, we are not listing Mesa rpms as incompatible with our rpm. It is your responsibility to remove previously installed Mesa RPMS, or rename Mesa files that conflict with ours. Our rpm, however, will try to notify you that these conflicts exist, on a file-by-file basis.

Specifically, the following files may cause problems:

/usr/X11R6/lib/modules/extensions/libGLcore.a
/usr/X11R6/lib/modules/extensions/libglx.a
/usr/lib/libGL.so
/usr/X11R6/lib/libGL.so*
/usr/X11R6/lib/libGLcore.so*

The installation of the RPM is going to fail if it finds any of the above files, and ask you to rename or remove them. After you've taken care of them, you would have to use the --force option while installing the RPM, because rpm thinks the package is already installed even if the installation failed.

Long-term, this renaming of Mesa files will not be necessary, but for this release, this was the cleanest solution possible. You can verify that the correct XFree86 server modules load by looking at your XFree86.0.log file (typically located in /var/log), and ensuring that the copyright for the glx module is "NVIDIA Corporation".

5.2.1 Default RPM
Using RPMS, install is easy:

rpm -i NVIDIA_GLX_0.9-5.i386.rpm

If you are upgrading from a previous version of the driver, do NOT use the -U option to rpm, since there is a bug in the uninstall section of the previous rpms and will remove files that are needed in the current install. Remove the previous rpm using the -e option, and install as above. In detail:

rpm -e NVIDIA_GLX
rpm -i NVIDIA_GLX_0.9-5.i386.rpm

Note, if you couldn't find XFRee86 4.0 RPMS and installed binaries or built it from source, then the dependency in the NVIDIA_GLX module will fail.  To override this dependency, use the --nodeps option of rpm:

rpm -Uvh --nodeps NVIDIA_GLX-0.9-5.i386.rpm

Similarly, for removing the previous rpms using -e option.

5.2.2 Build from tar file
Using the tar file simply requires untarring the file, and typing 'make' in the resulting directory. The Makefile will install the libraries into the correct location for you, as well as run "ldconfig".

The correct location for each file is:

/usr/X11R6/lib/modules/drivers/nvidia_drv.o
/usr/X11R6/lib/modules/extensions/libglx.so.1.revision
/usr/lib/libGL.so.1.revision
/usr/lib/libGLcore.so.revision

where revision is the revision number of the libraries that exist in the particular distribution.
5.3 Setup
To use the new 2D module, simply modify the Device section of the XF86Config file and replace:
Driver    "nv"

with
Driver    "nvidia"

Note: if you have previously installed the GLX module from the 3.3.x version of XFree86, make sure to remove it.  Look for glx.so in the /usr/X11R6/lib/modules directory.  It will cause conflicts with the new GLX code.

Contents

--------------------------------------------------------------------------------

6.0 Troubleshooting
Hopefully your install went without a hitch.  There are always going to be instances where things just don't work right. If you encounter a problem not listed below, then send us an email at linux-bugs@nvidia.com and we'll see if we can help.
6.1 XFree86 4.0.1
Lots of places can cause problems when updating to XFree86 4.0.1.  Many of the libraries and modules are updated and changed from XFree86 3.3.x that most distributions are shipping.  Make sure you have run xf86config to generate a valid XF86Config file. Unless you are using a GeForce2 card, verify that the X server works properly with the included nv_drv.o module.  When performing this verification, make sure the Device section is referencing nv instead of vga or some other driver.
6.1.1 Modelines and monitors
Our earlier releases sometimes had problems detecting the monitor type, and were therefore unable to set certain resolutions. We have overhauled this code so that you should now be able to manually override the detected modelist with Modeline lines that you add to the "Monitor" section of your XF86Config file. Note that specifying modelines explicitly can damage your monitor if the monitor was not designed to handle those resolutions. Be careful.

6.2 Kernel driver
If you installed the prebuilt RPM, ensure you installed the proper type for your kernel, smp or uniprocessor.  To check that the kernel module is available, type this as 'root':
/sbin/insmod NVdriver

The module should load without any problems.  If the driver was already loaded, you would get an error message to that effect.  Check the driver is loaded by typing:

/sbin/lsmod

One of the drivers listed will be NVdriver if everything is OK. If you got unresolved symbols when loading, you probably have the wrong module type.  Try the other type. If you still see unresolved references, it is possible that the kernel you are running does not match the current kernel config as described in /usr/include/linux/autoconfig.h. This would only be true for those of you who are building your own kernel, or for people with multiple kernels installed on their machine.

If the above worked OK, but the X server bails out when starting, make sure the line:

alias char-major-195 NVdriver

exists in /etc/conf.modules or /etc/modules.conf. If the line doesn't exist, you should add it by hand.

6.3 X
First,  review Section 5.3 concerning the XF86Config file setup.  If the X server works fine with the included nv_drv.o module, but exits out during intialization with the nvidia_drv.o module, review Section 6.2 concerning the kernel driver.
6.4 OpenGL
If OpenGL apps fail to run because they cannot find libGL.so, run
/sbin/ldconfig

as 'root'.

If OpenGL apps fail to run because they claim the GLX extension isn't supported, make sure the XF86Config file has a glx listed in the modules section:


Section "Module"

...

# This loads the GLX module
Load    "glx"

EndSection

If OpenGL apps run, but are extremely slow, check for other libGL.so's lurking about the system.  Many distributions include a free clone of OpenGL called Mesa.  Most apps are built using the Mesa libs and search for libMesaGL.so or libMesa.so.  If you want to accelerate these apps, you will need to make a symlink from the Mesa libs to /usr/lib/libGL.so.*.  Look for libMesaGL.so.* or libMesa.so.* in /usr/lib or /usr/X11R6/lib. You must then delete or rename libMesaGL.so.3.0 (or whatever version is installed). To make a symbolic link to the accelerated libGL, type:

ln -s /usr/lib/libGL.so.1 libMesa.so.3.0

Use whichever version of the Mesa library you just renamed or deleted as the above target (libMesaGL.so.3.0 in this case).

In addition, the XFree86 4.0 tree includes a libGL.so.1.2 in /usr/X11R6/lib, which is also part of Mesa. You can clean that out with the commands:

mv /usr/X11R6/lib/libGL.so.1.2 /usr/X11R6/lib/libGL.so.1.2.mesa
ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so.1.2

6.5 Known Bugs
6.5.1 OpenGL + Indirect Rendering
At present, indirect OpenGL rendering (i.e. app is run from a different X server than where it renders to) does not fully support all the extensions and features of direct rendering. We plan to fix this in the very near term.

6.5.2 OpenGL + multiple monitors
Currently, OpenGL does not work in a multiple monitor configuration. In the mean-time, if you are running an X server configured for multiple monitors, we recommend that you disable OpenGL support by commenting out the
Load "glx"
line from your XF86Config. We plan to fix this in the very near term.

6.5.3 OpenGL + MesaGL
This installation conflicts with some files provided as part of the base XFree86 4.0 package that deal with MesaGL. In particular, the client libraries libGL.so and libGLcore.so, and XFree86 loadable modules libglx.so all cause potential conflicts with Mesa's libraries. We are working with other OpenGL and OpenGL-compatible library providers to establish a common mechanism by which hardware-specific modules such as those we provide can happily co-exist. Our driver is placing files in the agreed-upon place, but there are still conflicts because XFree 4.0 shipped before this standard was finalized. Please see sections 5.2 and 6.4 for information on resolving these conflicts.

6.5.4 AGP support
This software release does contain support for AGP on many common AGP chipsets. However, not all chipsets are currently supported. If your chipset is not yet supported, let us know what kind of chipset you are using and we will try to add support for it in a future driver release.

Currently internally supported chipsets include: Intel 440LX, 440BX, 440GX, 815, 820, and 840. AMD Irongate, VIA Apollo Pro133, KX133 and KT133. More chipsets may be supported through the use of AGPGART.

There are known problems with some Irongate chipsets and Dual CPU BX systems that require disabling of AGP (see next section). If you experience problems with any other AGP chipsets that go away when disabling AGP, please let us know.

6.5.5 X locks up when starting
The most common cause of X locking up on start-up at this point appears to be AGP. Although we have worked hard to provide quality AGP support, problems might still exist due to the amount of variance in motherboards and AGP chipsets. For this reason, we've included an override in the XFree86 Configuration file. The following addition to your XF86Config file will disable AGP:

# your pre-existing screen section
Section "Screen"
...
# adding this option disables AGP.
# a "1" will enable AGP (the default)
Option "NvAgp" "0"
...
EndSection

TNT Cards
We have gotten some reports that the X Server locks up when starting with some TNT cards. This appears to be due to a wrong bios loaded on the card by the manufacturer. We are working on a more transparent fix for the problem, but in the meantime have provided a user workaround. Please read the file TNT_USERS_README for more information, included in the NVIDIA_GLX package (the NVIDIA_GLX RPM will install the file in /usr/doc/NVIDIA_GLX/).
TNT2 M64 Cards
We have also received reports from some users that the X server locks up when starting up, on some TNT2 M64 cards. We are working on a more transparent fix for this problem, but have provided a user workaround for the meantime. Please read the file M64_USERS_README for more information, included in the NVIDIA_GLX package (the NVIDIA_GLX RPM will install the file in /usr/doc/NVIDIA_GLX/).
Low Memory
In addition, on systems with 32MB of RAM, it is possible to fail initialization due to some RAM requirements of our kernel-loadable module. If X fails to start up, sometimes it is sufficient to just try running it again. We recommend installing more RAM in your system for better performance, especially when running 3D (OpenGL).
6.5.6 Corruption at very high resolutions
Late in the process of testing our driver, we found that it is possible to see some image corruption if your physical screen size is set to 1600x1200. We will fix this in the very near term.

6.5.7 OpenGL + SMP
Some of our internal testing has revealed random lockups on SMP systems when running OpenGL. We are unsure of the exact cause of this, but we will find it and fix it for our next driver release.

6.5.8 OpenGL and dlopen()
The current thought is that there are some bugs in the glibc dynamic library loading and libdl.so that cause problems with apps that use dlopen() to load the OpenGL library. Apps that use dlopen() include Quake3 and the Quake3 level editor Radiant.

A workaround has been implemented for Quake3.

6.5.9 Buffers not getting freed
There are video memory leaks when a window gets destroyed, but the process is not terminated. If you have lots of OpenGL windows created and destoyed, this may cause your process to die. The amount of memory leaked is proportional to the size of the window at the time it got destroyed.

6.6 Troubleshooting some common applications
While this section should not be referred to in place of the documentation already provided with your applications, it can help you out with getting these apps going with our new drivers. For any further setup or runtime issues, you should contact the application publisher for technical support.

6.6.1 Quake3
Quake3 should work well out of the box. A fix has been made to our driver which was causing the crashes when vid_restart was called (i.e. changing any graphics settings).

6.6.2 Quake2
Quake2 requires some minor setup to get it going. First, in the Quake2 directory, the install creates a sym link called libGL.so that points at libMesaGL.so. This symlink should be removed or renamed. Then, to run Quake2 in OpenGL mode, you would type:
quake2 +set vid_ref glx +set gl_driver libGL.so
Quake2 does not seem to support any kind of full-screen mode, but you can run your X server at whatever resolution Quake2 runs at to emulate full-screen mode.

6.6.3 Heretic II
Heretic II also installs, by default, a symlink called libGL.so in the application directory. You can remove or rename this sym link, since the system will then find the default libGL.so (which our drivers install in /usr/lib). From within Heretic II you can then set your render mode to OpenGL in the video menu.

There is also a patch available to Heretic II from lokigames at:

http://www.lokigames.com/products/heretic2/updates.php3
6.6.4 Blender
We have heard several reports of Blender not working properly when you render the scene. We are currently looking into this and hope to have a fix shortly.

6.6.5 XMMS
XMMS OpenGL plugins had problems related with multi-threading operation with previous releases of our drivers (0.9-1 and 0.9-2). The current release (0.9-3) no longer has those issues with the latest version of those plugins, but it has a memory leak described in 6.5.10.

6.6.6 Heavy Gear 2
Heavy Gear 2 currently crashes when it changes screen resolutions. This, unfortunately, makes the game unplayable, because the crashes occur when switching between a level and save-game mode, or one level and the next. We are working on this problem and hope to have it fixed soon.

6.6.7 Misc
There are several 3D applications available for Linux today, which have statically linked in the MesaGL 3D library. As such, these applications can not run with accelerated 3D until the authors of the apps update their source to use a dynamic link to libGL.so.

NVIDIA has contacted the authors of these applications and asked them to make this change.

Contents

--------------------------------------------------------------------------------

7.0 Operating Options
This section describes options that affect the operation of the drivers.
7.1 X driver
The parameters for the X drivers are described in the Screen section of the XF86Config file. They contain settings that affect operating parameters of the NVIDIA X driver.

NvAGP Use this to enable/disable AGP support. Argument is a Boolean.
IgnoreEDID Use this to ignore monitor EDID values. EDID is the interface that monitors use to communicate their capabilities. Some monitors are known to lie about their own capabilities. Ignoring the values that the monitor gives back to the video card may improve your changes. On the other hand, this may prove dangerous to your monitor.

7.1 OpenGL
OpenGL options are set in the form of environment variables before you start your program.
The following ones are recognized:

__GL_SYNC_TO_VBLANK Setting this to a non-zero value will force glXSwapBuffers to sync to your monitor's vertical refresh rate (perform the swap only during the vertical blanking period).
__GL_ENABLE_FSAA Setting this to a non-zero value will enable full scene antialising. Note that since this is an environment variable, it can be set on a per-process basis.
__GL_FSAA_QUALITY This can be either 0, 1 or 2. 0 means 1.5x1.5 oversampling. 1 means 2x2 oversampling with a texture lod bias. 2 means 2x2 oversampling with no texture lod bias. Note that this variable only makes sense when __GL_ENABLE_FSAA is set.

--------------------------------------------------------------------------------

8.0 Frequently asked questions (the FAQ)
8.1 Kernel problems
8.1.1 I can't build the kernel module! There's tons of compile errors!
So far, this seems to be caused by one of two issues:

You need to change our kernel Makefile DEFINE= line to include the symbol -D_LOOSE_KERNEL_NAMES
Have you patched your kernel? If so, the patch may be incomplete. It's really important that the headers be consistent when doing a build, otherwise these kinds of problems can happen.
8.1.2 I can't build your kernel module with the Linux 2.3.xx kernel
We will release a fix for this within the next couple of days. The fix was figured out by Jim Duchek, who has a temporary link at http://www.darkrock.co.uk/nv in the interim until we get our new release out. Thanks Jim!

8.1.3 I get unresolved references when I attempt to insmod the kernel module
This problem comes from having a mis-configured system. The problem is most likely that the currently-running kernel does not match the headers describing it in /usr/include/linux/config.h (which runs through a symlink)

8.2 Starting X
8.2.1 X fails to load, and claims there's 0kb of total video memory
There's several things that can be causing this. First, did you install our kernel module properly? Instructions on installing the kernel module are above, and must be followed closely. To diagnose the problem somewhat, you should see output similar to this:

root@system:# lsmod | grep NV
NVdriver    0  (autoclean)

root@system:# cat /proc/devices | grep nvidia
195 nvidia

root@system:# ls -l /dev/nvidia*
crw-rw-rw- 1 root    root    195, 0 Apr 24 18:46 /dev/nvidia0
crw-rw-rw- 1 root    root    195, 1 Apr 24 18:46 /dev/nvidia1
crw-rw-rw- 1 root    root    195, 2 Apr 24 18:46 /dev/nvidia2
crw-rw-rw- 1 root    root    195, 3 Apr 24 18:46 /dev/nvidia3
crw-rw-rw- 1 root    root    195, 255 Apr 24 18:46 /dev/nvidiactl

root@system:# cat /proc/pci
Note that in this section, many of the numbers will be different than
this example, but the important thing is that there's an IRQ assigned to
the device.  Ideally, nothing else is sharing this IRQ.
...
Bus  1, device 0, function  0:
VGA compatible controller: NVidia Unknown device (rev 16).
   Vendor id=10de. Device id=101.
   Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master Capable.  Latency=248.  Min Gnt=5.Max Lat=1.
   Non-prefetchable 32 bit memory at 0xe9000000 [0xe9000000].
   Prefetchable 32 bit memory at 0xf0000000 [0xf0000008].
...

If any of these commands return no output, or an error, then you should re-run our kernel module's install.sh and watch closely for errors.

If all of this seems correct, then it's possible you're hitting a problem that we've been getting reports of from users. If you would like, you can send us email with details of your system (RAM, CPU, motherboard, graphics card (maker + model), kernel, etc.) and details of the problem you see at linux-bugs@nvidia.com and we will try to help. This is a TOP priority for us right now, we hope to have it resolved soon.

8.2.2 The X server cannot set the right resolutions for my monitor
We have made large changes to our monitor detection code, and we now believe that you should be able to explicitly set resolutions if your monitor cannot be detected correctly. See section 6.1.1 on modelines for more details.

If our new code still does not work, one trick that has worked for some people with the previous drivers is to disconnect the monitor when X starts up, so that the monitor detection code cannot even attempt to read the monitor info back. If you experience modeset problems, and this workaround works for you, please send email to linux-bugs@nvidia.com and let us know what monitor type you've got... we'll try to debug the problem here as well.

8.3 OpenGL
8.3.1 OpenGL crashes when I start Quake or other apps
The most common cause of this is that some remnants of MesaGL are still left on your system. You should refer to section 6.5.3 in Known Bugs, above, for details on how to resolve this conflict.

8.3.2 OpenGL is slow when I run XXX app
This also seems to be caused by having conflicts between MesaGL components, and our OpenGL components. You can refer to section 6.5.3 in Known Bugs, above, for details on how to resolve this conflict.

Contents