The following problems still exist in this release and are in the process of being resolved.
Known Issues
There are some issues with older versions of the glibc dynamic loader (e.g., the version that shipped with Red Hat Linux 7.2) and applications such as Quake3 and Radiant, that use dlopen(). Please see Chapter 4, Frequently Asked Questions for more details.
In some cases, the secondary card is not initialized correctly by the NVIDIA kernel module. You can work around this by enabling the XFree86 Int10 module to soft-boot all secondary cards. See Appendix D, X Config Options for details.
Single-threaded applications that use dlopen() to load NVIDIA's libGL library, and then use dlopen() to load any other library that is linked against libpthread will crash in libGL. This does not happen in NVIDIA's new ELF TLS OpenGL libraries (please see Appendix C, Installed Components for a description of the ELF TLS OpenGL libraries). Possible workarounds for this problem are:
Load the library that is linked with libpthread before loading libGL.
Link the application with libpthread.
Many 2.4 and 2.6 x86_64 kernels have an accounting problem in their implementation of the change_page_attr kernel interface. Early 2.6 kernels include a check that triggers a BUG() when this situation is encountered (triggering a BUG() results in the current application being killed by the kernel; this application would be your OpenGL application or potentially the X server). The accounting issue has been resolved in the 2.6.11 kernel.
We have added checks to recognize that the NVIDIA kernel module is being compiled for the x86-64 platform on a kernel between 2.6.0 and 2.6.11. In this case, we will disable usage of the change_page_attr kernel interface. This will avoid the accounting issue but leaves the system in danger of cache aliasing (see entry below on Cache Aliasing for more information about cache aliasing). Note that this change_page_attr accounting issue and BUG() can be triggered by other kernel subsystems that rely on this interface.
If you are using a 2.6 x86_64 kernel, it is recommended that you upgrade to a 2.6.11 or later kernel.
Also take note of common dma issues on 64-bit platforms in Appendix AA, Allocating DMA Buffers on 64-bit Platforms.
Cache aliasing occurs when multiple mappings to a physical page of memory have conflicting caching states, such as cached and uncached. Due to these conflicting states, data in that physical page may become corrupted when the processor's cache is flushed. If that page is being used for DMA by a driver such as NVIDIA's graphics driver, this can lead to hardware stability problems and system lockups.
NVIDIA has encountered bugs with some Linux kernel versions that lead to cache aliasing. Although some systems will run perfectly fine when cache aliasing occurs, other systems will experience severe stability problems, including random lockups. Users experiencing stability problems due to cache aliasing will benefit from updating to a kernel that does not cause cache aliasing to occur.
NVIDIA has added driver logic to detect cache aliasing and to print a warning with a message similar to the following:
NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73
If you see this message in your log files and are experiencing stability problems, you should update your kernel to the latest version.
If the message persists after updating your kernel, please send a bug report to NVIDIA.
Starting with native PCI Express GPUs, NVIDIA's GPUs will advertise a 64-bit BAR capability (a Base Address Register stores the location of a PCI I/O region, such as registers or a frame buffer). This means that the GPU's PCI I/O regions (registers and frame buffer) can be placed above the 32-bit address space (the first 4 gigabytes of memory).
The decision of where the BAR is placed is made by the system BIOS at boot time. If the BIOS supports 64-bit BARs, then the NVIDIA PCI I/O regions may be placed above the 32-bit address space. If the BIOS does not support this feature, then our PCI I/O regions will be placed within the 32-bit address space as they have always been.
Unfortunately, current Linux kernels (as of 2.6.11.x) do not understand or support 64-bit BARs. If the BIOS does place any NVIDIA PCI I/O regions above the 32-bit address space, the kernel will reject the BAR and the NVIDIA driver will not work.
There is no known workaround at this point.
On X86 systems and AMD64/EM64T systems using X86 kernels, only 4GB of virtual address space are available, which the Linux kernel typically partitions such that user processes are allocated 3GB, the kernel itself 1GB. Part of the kernel's share is used to create a direct mapping of system memory (RAM). Depending on how much system memory is installed, the kernel virtual address space remaining for other uses varies in size and may be as small as 128MB, if 1GB of system memory (or more) are installed. By default, the kernel reserves a minimum of 128MB.
The kernel virtual address space still available after the creation of the direct system memory mapping is used by both the kernel and by drivers to map I/O resources, and for some memory allocations. Depending on the number of consumers and their respective requirements, the Linux kernel's virtual address space may be exhausted. Newer Linux kernels print an error message of the form below when this happens:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
The NVIDIA kernel module requires portions of the kernel's virtual address space for each GPU and for certain memory allocations. If no more than 128MB are available to the kernel and device drivers at boot time, the NVIDIA kernel module may be unable to initialize all GPUs, or fail memory allocations. This is not usually a problem with only 1 or 2 GPUs, however depending on the number of other drivers and their usage patterns, it can be; it is likely to be a problem with 3 or more GPUs.
Possible solutions for this problem include:
If available, the 'vmalloc' kernel parameter can be used to increase the size of the kernel virtual address space reserved by the Linux kernel (the default is 128MB). It is recommended to raise this value in increments to find the best balance between the size of the kernel virtual address space made available and the size of the direct system memory mapping. You can achieve this by passing 'vmalloc=192M', 'vmalloc=256MB', ..., to the kernel and checking if the above error message continues to be printed.
Note that some versions of the GRUB boot loader have problems calculating the memory layout and loading the initrd if the 'vmalloc' kernel parameter is used. The 'uppermem' GRUB command can be used to force GRUB to load the initrd into a lower region of system memory to work around this problem. This will not adversely affect system performance once the kernel has been loaded. The suggested syntax is:
title Kernel Title uppermem 524288 kernel (hdX,Y)/boot/vmlinuz...
Please also note that the 'vmalloc' kernel parameter only exists on Linux 2.6.9 and later kernels. On older kernels, the amount of system memory used by the kernel can be reduced with the 'mem' kernel parameter, which also reduces the size of the direct mapping and thus increases the size of the kernel virtual address space available. For example, 'mem=512M' instructs the kernel to ignore all but the first 512MB of system memory. Although it is undesirable to reduce the amount of usable system memory, this approach can be used to check if initialization problems are caused by kernel virtual address space exhaustion.
In some cases, disabling frame buffer drivers such as vesafb can help, as such drivers may attempt to map all or a large part of the installed graphics cards' video memory into the kernel's virtual address space, which rapidly consumes this resource. You can disable the vesafb frame buffer driver by passing these parameters to the kernel: 'video=vesa:off vga=normal'.
Some Linux kernels can be configured with alternate address space layouts (e.g. 2.8GB:1.2GB, 2GB:2GB, etc.). This option can be used to avoid exhaustion of the kernel virtual address space without reducing the size of the direct system memory mapping. Some Linux distributors also provide kernels that use seperate 4GB address spaces for user processes and the kernel. Such Linux kernels provide sufficient kernel virtual address space on typical systems.
If your system is equipped with an X86-64 (AMD64/EM64T) processor, it is recommended that you switch to a 64-bit Linux kernel/distribution. Due to the significantly larger address space provided by the X86-64 processors' addressing capabilities, X86-64 kernels will not run out of kernel virtual address space in the foreseeable future.
The NVIDIA OpenGL implementation makes use of self modifying code. To force Valgrind to retranslate this code after a modification you must run using the Valgrind command line option:
--smc-check=all
Without this option Valgrind may execute incorrect code causing incorrect behavior and reports of the form:
==30313== Invalid write of size 4
2.6 kernels have added support for Memory-Mapped PCI Configuration Space accesses. Unfortunately, there are many problems with this mechanism, and the latest kernel updates are more careful about enabling this support.
The NVIDIA driver may be unable to reliably read/write the PCI Configuration Space of NVIDIA devices when the kernel is using the MMCONFIG method to access PCI Configuration Space, specifically when using multiple GPUs and multiple CPUs on 32-bit kernels.
This access method can be identified by the presence of the string "PCI: Using MMCONFIG" in the 'dmesg' output on your system. This access method can be disabled via the "pci=nommconf" kernel parameter.
If you are using a laptop please see the "Known Laptop Issues" in Appendix I, Configuring a Laptop.
When FSAA is enabled (the __GL_FSAA_MODE environment variable is set to a value that enables FSAA and a multisample visual is chosen), the rendering may be corrupted when resizing the window.
When a multithreaded OpenGL application exits, it is possible for libGL's DSO finalizer (also known as the destructor, or "_fini") to be called while other threads are executing OpenGL code. The finalizer needs to free resources allocated by libGL. This can cause problems for threads that are still using these resources. Setting the environment variable "__GL_NO_DSO_FINALIZER" to "1" will work around this problem by forcing libGL's finalizer to leave its resources in place. These resources will still be reclaimed by the operating system when the process exits. Note that the finalizer is also executed as part of dlclose(3), so if you have an application that dlopens(3) and dlcloses(3) libGL repeatedly, "__GL_NO_DSO_FINALIZER" will cause libGL to leak resources until the process exits. Using this option can improve stability in some multithreaded applications, including Java3D applications.
XVideo will not work correctly when Composite is enabled unless using X.Org 7.1 or later. See Appendix S, The X Composite Extension.
This section describes problems that will not be fixed. Usually, the source of the problem is beyond the control of NVIDIA. Following is the list of problems:
Problems that Will Not Be Fixed
This motherboard uses a LinFinity regulator on the 3.3 V rail that is only rated to 5 A -- less than the AGP specification, which requires 6 A. When diagnostics or applications are running, the temperature of the regulator rises, causing the voltage to the NVIDIA chip to drop as low as 2.2 V. Under these circumstances, the regulator cannot supply the current on the 3.3 V rail that the NVIDIA chip requires.
This problem does not occur when the graphics board has a switching regulator or when an external power supply is connected to the 3.3 V rail.
On Athlon motherboards with the VIA KX133 or 694X chip set, such as the ASUS K7V motherboard, NVIDIA drivers default to AGP 2x mode to work around insufficient drive strength on one of the signals.
AGP 1x transfers are used on Athlon motherboards with the Irongate chipset to work around a problem with signal integrity.
On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work around timing issues and signal integrity issues. See Chapter 5, Common Problems for more information on ALi chipsets.
Version 1.8 of the NV-CONTROL X Extension introduced target types for setting and querying attributes as well as receiving event notification on targets. Targets are objects like X Screens, GPUs and G-Sync devices. Previously, all attributes were described relative to an X Screen. These new bits of information (target type and target id) were packed in a non-compatible way in the protocol stream such that addressing X Screen 1 or higher would generate an X protocol error when mixing NV-CONTROL client and server versions.
This packing problem has been fixed in the NV-CONTROL 1.10 protocol, making it possible for the older (1.7 and prior) clients to communicate with NV-CONTROL 1.10 servers. Furthermore, the NV-CONTROL 1.10 client library has been updated to accommodate the target protocol packing bug when communicating with a 1.8 or 1.9 NV-CONTROL server. This means that the NV-CONTROL 1.10 client library should be able to communicate with any version of the NV-CONTROL server.
It is recommended that NV-CONTROL client applications relink with version 1.10 or later of the NV-CONTROL client library (libXNVCtrl.a, in the nvidia-settings-1.0.tar.gz tarball). The version of the client library can be determined by checking the NV_CONTROL_MAJOR and NV_CONTROL_MINOR definitions in the accompanying nv_control.h.
The only web released NVIDIA Linux driver that is affected by this problem (i.e., the only driver to use either version 1.8 or 1.9 of the NV-CONTROL X extension) is 1.0-8756.
If you are experiencing stability problems with a Linux SMP machine and seeing I/O APIC warning messages from the Linux kernel, system reliability may be greatly improved by setting the "noapic" kernel parameter.
On some systems, setting the "Local APIC Support on Uniprocessors" kernel configuration option can have adverse effects on system stability and performance. If you are experiencing lockups with a Linux UP machine and have this option set, try disabling local APIC support.
Some of the earlier versions of agpgart to support the nForce2 chipset are known to contain bugs that result in system hangs. The suggested workaround is to use NVAGP or update to a newer kernel. Known problematic versions include all known Red Hat Enterprise Linux 3 kernels (through Update 7).
If a broken agpgart is used on an nForce2 chipset, the NVIDIA driver will attempt to work around these agpgart bugs as best it can, by recovering from AGP errors and eventually disabling AGP.
To configure NVAGP, please see Appendix F, Configuring AGP.