1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
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** [[!toc ]]
## 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:
[[!format txt """
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
"""]]
Linux:
[[!format txt """
[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> (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/|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 -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`
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:
[[!format txt """
(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|http://www.xfree86.org/~alanh/]] also has kernel modules.
Linux:
* If you get this error message: [[!format txt """
[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 <card>.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: [[!format txt """
[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: [[!format txt """
[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:
[[!format txt """
(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:
[[!format txt """
DefaultDepth 16
"""]]
or
[[!format txt """
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:
[[!format txt """
(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:
[[!format txt """
(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:.
[[!format txt """
VideoRam 32768
"""]]
If you see messages about:
[[!format txt """
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:
[[!format txt """
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:
[[!format txt """
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:
[[!format txt """
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:
[[!format txt """
Section "DRI"
Mode 0666
EndSection
"""]]
If you get (the driver name may vary):
[[!format txt """
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):
[[!format txt """
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:\ \
[[!format txt """
#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|http://dri.sourceforge.net/doc/dri_driver_features.phtml]] 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.
If you get message like this ([[original solution|http://wiki.archlinux.org/index.php/ATI_Radeon_&_Kernel_2.6]]):
[[!format txt """
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:
[[!format txt """
$ sudo updatedb
$ locate libGL.so
"""]]
This should return the following output:
[[!format txt """
$ 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 `eselect-opengl` package:
[[!format txt """
emerge --oneshot eselect-opengl
"""]]
---
* [[CategoryTroubleshooting|CategoryTroubleshooting]]
|