This is a process for troubleshooting the DRI. It only works if you do it in order. OS names prefix OS-specific parts.
This process assumes you have XFree86 4.3.0 or newer installed. If not, update to any version of X.Org, or XFree86 4.3.0 or newer, before starting.
If you have a PCI card you may skip this section (DRM will load the AGP driver to resolve symbols, but otherwise doesn't need it). If you have a non-Intel PCIE chipset you may also skip this step.
Check that AGP has been set up properly. If you have a PCI or PCIE card you may skip this step. Otherwise, if
dmesg | grep agp returns nothing, you need to fix it.
dmesg | grep agpdoesn't show anything about agp, make sure you have device agp in your kernel (it's default in -stable and -current). AGP does not work when loaded as a module after boot until FreeBSD 7.0-current.
- If your AGP module is loaded according to kldload but it didn't show up, probes fine, then you may have device agp in the kernel and loaded from loader.conf. This doesn't work, so remove it from loader.conf.
- If you aren't using RELENG_6 (note: not RELENG_6_0), you may need to update to get support for your AGP chipset.
If you have device agp in the kernel but not in loader.conf, and are using RELENG_6 or newer, and it still doesn't probe, please file a PR containing the output of scanpci and your dmesg. Linux:
If there are no agpgart: lines, compile agpgart into your kernel or load it as a module.
- If it complains about an unsupported chipset/bridge, make sure you included your chipset-specific AGP support when you configured the kernel. This chipset support is for your motherboard, not for your video card, so if you have a Radeon on an Intel motherboard, you need intel-agp.ko, not ati-agp.ko.
Check that the DRM (Direct Rendering Module, the kernel module) is loaded and has found your card. Do
dmesg | grep drm. You should have several lines of info, with samples below:
drm0: <ATI Radeon QL R200 8500 LE> port 0x9000-0x90ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xe8000000 64MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 info: [drm] Loading R200 Microcode
[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 0
Note that 64MB is not the size of the card's memory; it's the size of the AGP aperture (how much system memory can be accessed by the card if X chooses to use that much).
- If kldload
(card being one of mga, r128, radeon, sis, tdfx) says
Exec format error, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at the AGP instructions above.
If kldstat shows your card module is loaded but nothing shows up in
dmesg | grep drm, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver. Linux:
If you get DRM version output but not your card-specific DRM version output, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver. If your card isn't getting probed, please make sure you are using current DRM CVS sources before submitting a report of missing support. Instructions for building the DRM are at: Building.
If you are using current DRM sources and your card should be supported by an existing driver but isn't, please submit a report to http://bugs.freedesktop.org/ with the output of
At this point DRM should be set up correctly. Start the X server and
grep -i "Direct rendering" /var/log/Xorg.0.log. If that grep returns "Direct rendering enabled", skip ahead to the next section.
If that grep returns nothing, make sure you have lines for
Load "dri" and
Load "glx" in the Modules section of xorg.conf. If your changes to xorg.conf have no effect, make sure the xorg.conf you are editing matches the one being used according to
grep config\ file /var/log/Xorg.0.log
If you get a message like this:
(EE) [dri] RADEONDRIScreenInit failed because of a version mismatch (EE) [dri] libdri version is 4.2.0 but version 5.0.0 is needed. (EE) [dri] Disabling DRI.
then your libdri module is too old. If you installed from a snapshot, be sure to update the common module. If the version numbers are the other way around (version is 5.0 but version 4.2 is needed) then you updated your server without updating your 2D driver as well.
If it complains about the kernel module version, you have to update your kernel modules. For FreeBSD, this means either modules from -current or from -stable as described in the install section. For Linux, the kernel DRM is updated semi-regularly, and Alan Hourihane's website also has kernel modules.
If you get this error message:
[agp] AGP not available
despite the fact that the agpgart module loaded and initialized without problems, ensure that agpgart loads before the driver module for your chipset (like the radeon module). If agpgart loads later, the driver module will not see the AGP bus. As well, make sure the kernel module for your AGP bridge loads before the driver module for your chipset. For example, if your AGP bridge is an AMD Irongate (this can be determined via
lspci -v and looking for the line containing AGP), make sure that amd_k7_agp is loaded before the driver module (say radeon).
If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate
dmesg | grep drm, it will show that multiple versions were loaded. Recompile your kernel without the DRM, and install the updated module again.
If it says:
[drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied
people have said that it's because the modules were built with a different gcc version than the kernel. Make sure they are in sync. Also,
dmesg output should show something about version magic mismatches if this is the case. Another possibility (for the i915/i810 chipsets) is that you have an old buggy version of the i810 driver. Be sure to upgrade to the latest and "greatest". NOTE: There is at least one known case with the radeon driver where the gcc-version cause theory is not true.
If at this point, dmesg says:
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
then you missed the part above about having the correct AGP modules loaded. 2.6 users need to make sure both the
agpgart core module and the appropriate chipset-specific module are loaded. Run
lspci | grep "AGP bridge" to find out what sort of AGP chipset you have. Intel needs
intel-agp, VIA needs
If you find a line saying:
(EE) RADEON(0): [dri] RADEONInitVisualConfigs failed (depth 8 not supported). Disabling DRI.
or something along those lines, this is because none of the DRI drivers support rendering in 8-bit mode. If you have a Voodoo3, it only works in 16-bit mode and will say something similar if you try 32-bit. Change your depth appropriately by adding:
DefaultDepth 24 DefaultFbBpp 32
as appropriate to your xorg.conf's Screen section.
If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high a resolution.
grep Static\ buffer /var/log/Xorg.0.log will find a line like:
(WW) ATI(0): DRI static buffer allocation failed -- need at least 4608 kB video memory
If so, reduce your resolution or color depth. The video ram necessary for a given resolution/depth is width*height*(depth/8)*3 kilobytes. (The 3 is for front, back, and depth buffers).
If you are using Intel i8xx hardware and it says:
(WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed (Cannot allocate memory)
You need to have X.Org allocate more system memory to the integrated graphics. In the Device section of xorg.conf, set VideoRam to something higher, for example:
If you see messages about:
Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!
make sure you have Load "glx" in your xorg.conf's modules section. If you do have Load "glx", make sure you don't have any parts of the nvidia binary driver installed, particularly libglx.so*. Remove those, and reinstall X.Org if you continue to have problems.
Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e.
setenv LIBGL_DEBUG verbose for csh-based shells or
export LIBGL_DEBUG=verbose for bash-based shells. Run glxinfo, which should be included with X.Org. At the top it should show libGL trying to load the driver-specific hardware rendering library, like:
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so.
If it isn't doing that, you have replaced your X.Org-provided libGL with some other libGL, or it's finding an old libGL from somewhere. Run
ldd /usr/X11R6/bin/glxinfo and see which libGL it's finding. Make sure it's the one in
/usr/X11R6/lib/libGL, or a link in
/usr/lib to the one in
/usr/X11R6/lib. You shouldn't have any libMesaGL* on your system.
If the driver complains about unresolved symbols:
libGL error: dlopen /usr/X11R6/lib/modules/dri/radeon_dri.so failed (/usr/X11R6/lib/modules/dri/radeon_dri.so: undefined symbol: _glapi_noop_enable_warnings)
then your libGL is out of sync with your DRI drivers. Because APIs change, you typically need a libGL from the latest X.Org release to run DRI drivers, and sometimes you need a libGL from X.Org CVS for the latest drivers. Reinstall both your drivers and your libGL from sources from the same date.
If you get:
libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering
then you are trying to run as a user that doesn't have permission to use the DRI (root is the default allowed user). To let all users access the DRI, add the following section to your xorg.conf:
Section "DRI" Mode 0666 EndSection
If you get (the driver name may vary):
libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (libexpat.so.1 : cannot open shared object file: No such file or directory) libGL error: unable to find driver: r200_dri.so
then make sure that you have libexpat.so.1 installed. Binary snapshots now come with a statically linked libexpat, so this should no longer be a problem.
If you get (the driver name may vary):
libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (r200_dri.so : cannot open shared object file: No such file or directory)
then make sure you have compiled the appropriate dri module for your card. It it could be either in a separate file (r200_dri.so in this case), or bundled in libGL.so. Edit
xc/config/cf/host.def and make sure you list at least your driver (if not all available) in a line:
#define BuildXF86DRI YES /* 2D accel drivers are: ati mga glint s3virge sis savage nv tga rendition tdfx vga i810 sunffb sunleo suncg6 suncg3 suncg14 suntcx */ #define XF86CardDrivers ati /* the next line DriDrivers defines dri modules. Valid choices: gamma i810 i915 mach64 mga r128 radeon r200 tdfx savage sis ffb ati is not a valid DriDriver name. For new Radeon cards use r200 instead. */ #define DriDrivers radeon r200
If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install the correct glide for your card as provided by your distribution.
If you are using a radeon and it complains about the module versions and maybe fails on an assertion, you need to update your DRM as in the instructions above.
If you've made it this far, glxinfo should be printing
direct rendering: Yes and direct rendering for native GL programs should be working. Make sure that you are running at reasonable settings for your card, and maybe adjust your expectations of speed.
If you are experiencing trouble using GL with any program, maybe setting more environment variables may help you.
Linux compatibility has its own set of issues. To debug Linux DRI compatibility (i.e. quake3/UT), use
LIBGL_DEBUG=verbose set. You should be using -current as of April 25, 2003, or -stable as of May 2, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your X.Org segfaults, make sure you don't have the linux_glx port installed. If you get coredumps on your system with SSE support (Pentium 3 and up, Athlon XP and up), you may need to set the environment variable MESA_FORCE_SSE to 1 due to what appears to be a bug with our linux compat's signal handling.
If you get message like this (original solution):
fglrx: libGL version undetermined - OpenGL module is using glapi fallback
This could be caused by having multiple versions of libGL.so on your system. Run:
$ sudo updatedb $ locate libGL.so
This should return the following output:
$ locate libGL.so /usr/lib/libGL.so /usr/lib/libGL.so.1 /usr/lib/libGL.so.1.2 $
These are the only three libGL.so files you should have on your system. If you have any more (eg. /usr/X11R6/lib/libGL.so.1.2), then remove them. This should fix your problem. Then using Gentoo linux, you should update and remerge
emerge --oneshot eselect-opengl