The logo above lies about this page: I am trying to make it cover all of the DRI-supported OSes, so ignore any paragraph prefixed with another OS name. This is a process for troubleshooting the DRI. It is only useful if you do it in order.

Check that the DRM (Direct Rendering Module, the kernel module) is loaded and found your card. Do dmesg | grep drm. You should have several lines of info, with samples below:

FreeBSD:

drm0:  port 0x9000-0x90ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 11 at device 0.0 on pci1
info: [drm] AGP at 0xe8000000 64MB
info: [drm] Initialized radeon 1.1.1 20010405 on minor 0

Linux:

[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0

Note that that 64MB is not the size of the card's memory, it's the size of the AGP aperture (how much system ram can be accessed by the card if X chooses to use that much).

FreeBSD: If you are using drm-kmod, did you enable the startup script? You needed to move /usr/local/etc/rc.d/drm.sh.sample to /usr/local/etc/rc.d/drm.sh and do /usr/local/etc/rc.d/drm.sh start.

FreeBSD: If kldload <card> (card being one of radeon, tdfx, mga, r128) says Exec format error, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at he agp instructions below

• Rage Pro (being developed in mach64-0-0-6-branch)
• Rage Mobility (Not referring to the Mobility M4 and higher or the Radeon Mobility chips, this one is a Rage Pro variant).
• Radeon 9200/9500/9700
• Radeon 8500-9100, except in XFree86 4.3.0 with updated DRM.
• PCI Radeon cards, except in XFree86 4.3.0 with updated DRM with Options "ForcePCIMode" "YES" in the device section.
• FreeBSD: PCI Rage 128 cards, except with updated kernel modules in -current or from files
• PCI Matrox cards

In the above, "updated DRM" means the modules from 4.3.0, or later for some cards. For FreeBSD this means the modules from -current or -stable. For linux, updated DRM is available in the 2.5.x kernel series or from Alan Hourihane's site.

FreeBSD/NetBSD: If you have a card that you think should be supported by the existing drivers but isn't probing, you can do a scanpci -vv and send me the output along with your dmesg, and I'll take a look if it should be supported.

If dmesg | grep drm complains about AGP, you need to check on your AGP. Do dmesg | grep agp to see what the agp module says.

FreeBSD: If your AGP is probing fine, then you probably have have device agp in the kernel or loaded from loader.conf. This doesn't work, so remove it from loader.conf.

FreeBSD: If dmesg | grep agp doesn'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.

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.

If the DRM is probing correctly, take a look at your XFree86 log. It's located at /var/log/XFree86.0.log. First, make sure the dri module is getting loaded. Running grep dri /var/log/XFree86.0.log | grep LoadModule will show it being loaded. If not, add Load "dri" to the Modules section of XF86Config. Load "glx" is also necessary. If you are having troubles with your changes to XF86Config not having any effect, make sure the XF86Config you are editing matches the one being used according to grep config\ file /var/log/XFree86.0.log

Next, make sure that X is working with the DRM correctly. Look at the bottom of the XFree86 log where it has lines with [dri], [drm], [agp], etc. If there are any (EE) errors in there, those are what to look at.

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, updated DRM is available in the 2.5.x kernel series or from Alan Hourihane's site.

Linux: If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate <card>.o, make sure your kernel doesn't have the DRM compiled in. If you dmesg | grep drm it will show multiple versions having been loaded. Recompile your kernel without the DRM and install the updated module again.

Linux: If it says [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied, people have said that it's due to the modules being built with a different gcc than the kernel. Make sure they are in sync.

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 16

	DefaultDepth 24
	DefaultFbBpp 32

If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high of a resolution. grep static\ buffer /var/log/XFree86.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 kb of video ram necessary for a given resolution/depth is width*height*depth/8*3. (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)

	VideoRam 32768

If you see messages about:

Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!
Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!

Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e. setenv LIBGL_DEBUG verbose or export LIBGL_DEBUG=verbose depending on your shell. Run glxinfo, which should be included with XFree86. At the top it should show libGL trying to load the driver-specific hw rendering library, like libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so. If it isn't doing that, you have replaced your XFree86-provided libGL with some other libGL or it's finding an old libGL from somewhere.
Linux: Run ldd /usr/X11R6/bin/glxgears (or glxinfo) and see what libGL it's finding, and make sure it's the /usr/X11R6/lib/libGL one from XFree86. You shouldn't have any libMesaGL* on your system.

If you get:

libGL error: failed to open DRM: Operation not permitted
libGL error: reverting to (slow) indirect rendering

Section "DRI"
    Mode 0666
EndSection

If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install correct glide for your card as provided by your distribution. Instructions for FreeBSD are on the Install page.

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 it is printing the OpenDriver lines but has some other error, what you do depends on the error. FreeBSD/NetBSD users may be able to get help from me by emailing me at eta@lclark.edu with whatever system info might possibly be relevant (OS/release, card, X version, DRI version if any, drm-kmod version if any, application error logs, XF86Config, /var/log/XFree86.0.log, etc.). Otherwise, ask on the dri-users mailing list, information for which is at the DRI website

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.

FreeBSD: Linux compatibility has its own set of issues. To debug linux DRI compatibility (i.e. quake3/UT), use /compat/linux/usr/X11R6/bin/glxinfo with LIBGL_DEBUG=verbose set. You should be using -current as of April 25, 2003 or -stable as of May 2nd, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your XFree86 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.