DRI Troubleshooting

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.

Contents

1. Kernel Setup
1. AGP
2. DRM
2. X server setup
3. Userspace setup

Kernel Setup

AGP

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.

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 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.

DRM

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:

FreeBSD:

drm0:  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

Linux:

[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).

FreeBSD:

• 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 scanpci

X server setup

At this point DRM should be set up correctly. Start the X server and grep "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

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

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.

Linux:

• 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 .o, make sure your kernel doesn't have the DRM compiled in. If you 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.

• 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 via-agp, etc.

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

or

   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:.

   VideoRam 32768

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.

Userspace setup

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.

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 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.