Problems with fglrx

This page discusses issues with the ATI proprietary fglrx display driver.

Known Troubles and Solutions

X-specific issues

upgrading xserver-xorg

ATI proprietary drivers version 8.21.7 and later work with x.org 6.9.

If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.

After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.

new Xorg ID Scheme

ATI proprietary drivers <=8.36.5 with xorg >=7.1.0-18 (==1.3.0.0) in Debian Sid and Fedora (Debian and Fedora Forum Entries)

Ubuntu feisty made their own xorg with the standard id of 7.2, to work around this issue.

Xorg has changed its ID Scheme in newer Versions, and fglrx cannot cope with that (Error message saying "[...] X version mismatch - detected X.org 1.3.-1.905, required X.org 7.1.0.0 [...]").

A binary hack solves the Problem (rage3d.com Forum Entry). This is a very dirty solution, and is probably violating the ATI driver license.

Simply using the open source ati driver (or holding back the xorg upgrades) until a new driver is released, is suggested.

Kernel-specific troubles

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a patch. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this patch instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try $ fglrxinfo - if your shell hangs at the end of this command, you may have an issue and should try the patch or upgrade.

Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. These issues have been fixed with later ATI drivers (> 8.21.7) so you can simply upgrade if you are running a more modern kernel.

No hardware acceleration

Acceleration lost after driver update

If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.

Check out /var/log/Xorg.0.log for a message like:

(WW) fglrx(0): Kernel Module version does *not* match driver.

(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:

(II) fglrx(0): Kernel Module Version Information:

(II) fglrx(0): Name: fglrx

(II) fglrx(0): Version: 8.10.19

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path.
Go to /lib/modules/<your linux kernel version>/ and type # grep fglrx modules.dep.
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run # depmod and you are done.

Hint:

Newer versions (8.21.7) of the fglrx module seem to be installed in the extra/ subdirectory.

Older versions (8.19.10) used to be located in the kernel/drivers/char/drm/ subdirectory.

GCC 3.4

If the ATI driver works only without the hardware acceleration, take into consideration that fglrx_dri.so was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy libstdc++.so.5* to /usr/lib and update the dynamic linker cache via # ldconfig.

Or install a compat package for your favorite distro. FC4 users can do:

# yum install libstdc++.so.5

radeonfb framebuffer

Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform # modprobe fglrx after boot but to have the module loaded via /etc/modules.autoload/kernel2.x at boottime instead.

Perpetual Mesa GLX Indirect on Debian

If you've done everything right and you're still seeing:

$ fglrxinfo

display: :0.0 screen: 0

OpenGL vendor string: Mesa project: www.mesa3d.org

OpenGL renderer string: Mesa GLX Indirect

OpenGL version string: 1.2 (1.5 Mesa 6.4.1)

try this:

# mkdir -p /usr/X11R6/lib/modules/dri

# ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri

Thanks to Maciej Matysiak for the clear debug here and solution here.

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:

$ LIBGL_DEBUG=verbose fglrxinfo

libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)

libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so

libGL error: dlopen /usr/X11R6/lib/modules/dri/fglrx_dri.so failed (/usr/X11R6/lib/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory)

libGL error: unable to find driver: fglrx_dri.so

display: :0.0 screen: 0

OpenGL vendor string: Mesa project: www.mesa3d.org

OpenGL renderer string: Mesa GLX Indirect

OpenGL version string: 1.2 (1.5 Mesa 6.4.2)

instead of that:

$ LIBGL_DEBUG=verbose fglrxinfo

libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)

libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so

libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)

drmOpenByBusid: busid is PCI:1:0:0

drmOpenDevice: minor is 0

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 4, (OK)

drmOpenByBusid: drmOpenMinor returns 4

drmOpenByBusid: drmGetBusid reports PCI:1:0:0

Can't open configuration file /home/merlin/.drirc: No such file or directory.

fglrx: DPD supported.

display: :0.0 screen: 0

OpenGL vendor string: ATI Technologies Inc.

OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)

OpenGL version string: 2.0.5879 (8.26.18)

I have contacted ATI to add that info by default, the mesa guys to do that in glxinfo too, as well as the debian packager to fix the debian packaging bug (2006/07/22), so hopefully the situation will improve soon

You may have to run fglrxinfo as root to get this detail rather than a useless message.

Where to look for fglrx_dri.so (gentoo and general)

After installing a new kernel (linux-2.6.20-gentoo-r7) with gentoo I again was not able to get the ATI driver working correctly. But now I found out what the problem was:

I tried

$ LIBGL_DEBUG=verbose fglrxinfo

libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)

libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so

libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)

libGL error: unable to find driver: fglrx_dri.so

The error itself makes sense, because I am running a 64-Bit linux on AMD. The question was, why libGL tries to look in /usr/lib32 only...

After some digging around I found out, that apparently 8.35.5 version of the driver uses the environment variable LIBGL_DRIVERS_PATH to find out where it should look for the "fglrx_dri.so" driver.

Now in my case this environment variable pointed to "/usr/lib32/dri" and that was what caused the problem. So doing

$ export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'

solved the problem in my case.

As mentioned I use gentoo. After some more digging around I found out, that it is apparently necessary to call

$ env-update

after a re-install of the ATI driver. To be more specific, it seems that "eselect opengl set ati" sometimes does something wrong. "env-update" seems to repair the problem so that afterwards the LIBGL_DRIVERS_PATH environment variable is set correctly when you log in.

If you want to check, look in /etc/profile.env and /etc/profile.csh. This is the place where the LIBGL_DRIVERS_PATH environment variable gets set.

Softlink hell

The fglrx installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the fglrx page for pointers.

Discussion

If using $ fglrxinfo after installing fglrx indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to

# cd /usr/X11R6/lib

and list your GL libraries and links

# ls -la *GL*

You should see something like the following two lines amoung others:

libGL.so -> libGL.so.1.2

libGL.so.1 -> libGL.so.1.2

If you see a link to a mesa library (something like ... -> libGL.mesa.1.2), then that's your problem! Restore the softlink like this (use your actual library version, though):

# ln -s libGL.so.1.2 libGL.so.1

For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like mesa.bkup, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.

Gentoo

Gentoo has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:

# opengl-update ati or

# eselect opengl set ati

Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. opengl-update is the old tried-and-true method for managing the symlinks. If opengl-update doesn't fix it for you, you should probably tell Gentoo Bugzilla (assuming they don't know yet).

If # ldd /usr/X11R6/bin/glxinfo shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:

libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)

you will also need to relink libGl.so.1.2:

# cd /usr/lib/opengl/xorg-x11/lib/

# mv libGL.so.1.2 libGL.so.1.2_backup

# ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2

After another restart of X $ fglrxinfo should show that it's using the right libs now.

Debian

# rm /usr/lib/libGL.so*

# rm /usr/X11R6/lib/libGL.so*

# cd /usr/X11R6/lib

# cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .

# ln -s libGL.so.1.2 libGL.so.1

# ldconfig

Troubles using software suspend

When the computer resumes from suspend, X only displays a garbled image and the computer is frozen. The problem is acknowledged in ATI's release notes and in knowledge base entry 737-218 737-218. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using vbetool to save/restore the video card state before/after suspend worked for some people. If you use Software Suspend 2 (suspend2) scripts, you can simply uncomment EnableVbetool yes in /etc/hibernate/hibernate.conf. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

tested with the following configurations

model	distro	kernel	fglrx	PM	success	comments
T42	SUSE 9.3	2.6.11	8.14.13	swsusp	yes
T41p	???	2.6.14	8.19.10	suspend2 2.2-rc9	yes	needs a small patch
T42p	Debian	2.6.10	Debian packaged	suspend2	yes
T43	Debian sid	2.6.14.2	8.19.10	swsusp	yes	works perfectly with 8.19.10 (but not earlier versions!)
T43	Debian etch	2.6.14.2	8.19.10	swsusp	yes	works perfectly with 8.19.10 and without vbetool
T43	Ubuntu Breezy	2.6.12-10	8.19.10	swsusp	yes	Perfect. (Finally.)
T43	FC4	2.6.14.1	8.19.10	suspend2 2.2-rc9	yes	needs a small patch, requires DRI disabled in xorg.conf (hence no 3D acceleration)
T43	FC4	2.6.14.2	8.19.10	suspend2 2.2-rc11	yes	requires DRI disabled in xorg.conf (hence no 3D acceleration)
T43	FC4	2.6.14.3	8.19.10	suspend2 2.2-rc13	no	DRI enabled
T43	FC4	2.6.14.3	8.20.8	suspend2 2.2-rc13	no	DRI enabled
T43p	FC6	2.6.20-1.2933	8.34.8	swsusp, STR	yes	DRI enabled, occasionally fails, reason unknown.
R50p	???	???	8.19.10	swsusp	yes
T43p	Debian sid	2.6.14	8.19.10	Suspend to RAM	yes	without vbetool or UseDummyXServer, those two break the resume process here, with DRI enabled
T43p	Debian sid	2.6.14.3	8.20.8	Suspend to RAM	yes	without vbetool or UseDummyXServer, with DRI enabled
R52	Debian sid	2.6.15-rc5	8.20.8	swsup	yes	both vbetool and UseDummyXServer disabled, DRI enabled, needs patch
T43p	Gentoo	2.6.15	8.22.5	Suspend to RAM	yes	without vbetool or UseDummyXServer, with DRI enabled - console is garbled until switching back from X
T43p	Gentoo	2.6.15	8.22.5	suspend2 2.2	yes	without vbetool or UseDummyXServer, with DRI enabled
T43	SUSE 10.1	2.6.16	8.25.18	swsusp	yes	without vbetool or UseDummyXServer, with DRI enabled
T43	SUSE 10.1	2.6.16	8.25.18	Suspend to RAM	yes	without vbetool or UseDummyXServer, with DRI enabled
T60	Gentoo 2006.1	2.6.19-suspend2	8.31.5	Suspend2	yes	Everything works: 3D, suspend-to-disk, suspend-to-ram, suspend in X.org, switching to VT's at any moment. Never needed to unload any modules manually, worked immediately. Fglrx driver 8.32.5 totally broke suspend for me, so i'm sticking with 8.31.5. T60 2008-B62 model.
T60p	Kubuntu 6.06	2.6.15	8.25.18	swsusp	no	Switching to VT to suspend: no resume, X restarts; Not switching: suspend works, garbled X display on resume, later X restarts
T60p	Kubuntu 6.06 Text Mode	2.6.15	---	swsusp	yes	suspend works in textmode after rmmod fglrx.
T60p	Debian/unstable/experimental	2.6.18	8.31.5-1 (from debian experimental)	susptoram hibernate debian packages	yes	suspend and resume works with X, 3D acc., Xv overlay...
Z61m	Debian Sid	2.6.20.7	8.35.5-1	Suspend to RAM	yes	works without any problems, justs needs the usual acpi_sleep hacks
Z61m	Debian Sid	2.6.20.7	8.35.5-1	Suspend to Disk (Software Suspend)	yes	works without any problems
Z61m	Debian Sid	2.6.21	8.35.5-1	Suspend to RAM	yes	fglrx module must not be loaded into the kernel, or it won't resume
Z61m	openSUSE 10.2	2.6.21.5	8.37.6	suspend2 2.2.10	yes	/sys/power/suspend2/extra_pages_allowance must be set to 20000
Z61p	ARCH Linux	2.6.20	8.35.5-1	Suspend to RAM	yes	works with KDE suspend

Troubles with large RAM

Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the fglrx kernel module is loaded, but independently of whether (CONFIG_HIGHMEM) is enabled. A workaround is to limit RAM by adding the mem=864m kernel parameter.

Version 8.16.20 fixes the problem.

Display switching

The switching between internal and external display doesn't work with fglrx versions <= 8.24.8, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the vesa server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20). Or boot notebook with CRT connected, it will automatically detect it and display on both.

Composite Support

ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.25.18).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (http://rage3d.com/board) Linux area.

Composite support is now supported with recent Mesa and Xorg > 7 with the open source 3d radeon drivers (if you run debian unstable, you should be all set.) It works with the R300 / FireGL T2 series as found on the T43p, but noticably slows down the system. This has made rapid progress in speed with the latest few releases and with kernel 2.6.21, it is finally usable with an R300 based card. Expect drivers to improve in the future, but it seems that composite does require a very fast video card and system.

Hardlock on X logout

Up from driver version 8.19.10 you will experience a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: /usr/kde/<VERSION>/share/config/kdm/kdmrc) you have to add following to the section [X-:*-Core]:

TerminateServer=true

In the gdm config (/etc/gdm/gdm.conf) file add the following to the daemon-section:

AlwaysRestartServer=true

Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239

Another reason of hardlock my be using the wrong AGP driver. Make sure that you have proper drivers for your motherboard loaded before fglrx: (gentoo: /etc/modules.autoload.d/kernel-2.6):

intel-agp
fglrx

A common problem seems to be mistakenly using ATI Chipset drivers instead of Intel.

Information from gentoo bugtracker: 113685. Fixed in 8.25.18

Cannot switch to VT

With usplash boot enabled, it may not be possible to switch to a VT from X (Using Alt+Fn). Tested on T60p (Mobility Fire GLV5200) on Ubuntu 6.06 / 6.10 and fglrx 8.25.18 / 8.28.8. Display may become garbled and system might freeze. Solution (testet on Ubuntu 6.10) is to either remove the "splash" kernel boot parameter or add "vga=791" parameter ("vga=794" can be used on 1400x1050 panel).

http://ati.cchtml.com/show_bug.cgi?id=37
https://launchpad.net/distros/ubuntu/+source/usplash/+bug/63558

Flickering Display

Some people have reported problems with their display flickering when using ati-drivers newer than 8.14.13. The problem is unclear (possibly associated with an incorrect modeline setting) and no known solution exists except to use the open source radeon drivers. You can follow this problem here: http://ati.cchtml.com/show_bug.cgi?id=248

Error messages in system log

If you find something like the following in /var/log/messages:

kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary

kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)

kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0

try to execute the following line and reload the fglrx module:

# echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr

More detailed instructions can be found here.

Hang when logging out

A common problem is that when logging out from X, instead of gettign the KDM or GDM prompt, the system hangs.

This is discussed, including workarounds here: http://ati.cchtml.com/show_bug.cgi?id=239

No power saving when CRT in use

When both CRT and LCD are in use, power saving cannot be enabled.

This is reported here: http://ati.cchtml.com/show_bug.cgi?id=304

WineX / Cedega Installs Software But Errors on Loading Games

Some users may experience problems with certain FIREGL cards (in my case an ibm t43p laptop with a v3200 ati firegl) whereby projects such as cedega and wine refuse to work with 3d graphics, but native binaries (e.g. quake 4) work fine. A possible workaround is to add the following line in the drivers section of your /etc/X11/xorg.conf

Option "UseFastTLS" "2"

This option used to be configured with the older ati drivers when you ran "fglrxconfig". I have not yet found a way to get it to appear with "aticonfig", hence the manual insertion. This option is good for several linux distros I have tried, fedora core 5, ubuntu dapper and suse 10.1. It does not appear to effect performance on natively run programs.

NOTE!

This may cause problems on machines with a Linux kernel version of 2.6.20 or higher (observed choppy video and video color inversion on T60p with both 2.6.20 and 2.6.21).

Line Appears Below Mouse Cursor

Some users have reported seeing a line approximately 1 mouse height below the bottom edge of the cursor, which follows the mouse and appears to change color based on the image below the cursor. This has been seen to happen using fglrx without the kernel module installed (in 2D mode) and additionally on external displays or multiple X servers. To work around the problem, try disabling the DGA extension by making the following changes to your XFree86.conf or xorg.conf file. Replace (or comment-out)

Load "extmod"

with

SubSection  "extmod"
 Option  "omit xfree86-dga"
EndSubSection

Freeze while using OpenGL Apps

Some OpenGL applications such as screensavers or games (SecondLife) cause freezes. The cursor still moves, but otherwise the machine is unresponsive. This is the case with Xorg 7.1 and fglrx 8.29.6 using an x1400 and other cards. The solution is to add the following options to the video Device section in xorg.conf:

Option "Capabilities" "0x00000800"
Option "KernelModuleParm" "locked-userpages=0"

Patches

The following patches might be needed for certain versions of fglrx. Before you apply any of these, make sure that you really need them, as some distributions include all the necessary patches with the appropriate package (e.g. ati-drivers in gentoo).

fglrx 8.35.5

• For kernel 2.6.20, part of the Fedora packaging scripts in the ATI installer

fglrx 8.34.8

• For kernel 2.6.20

fglrx 8.32.5

• For kernel 2.6.19

fglrx 8.23.7

• For kernel 2.6.16: intermodule patch and noiommu patch

fglrx 8.21.7

• for kernels >= 2.6.15

fglrx 8.20.8

• for kernel 2.6.15

or

• for kernels >= 2.6.15

fglrx (problem met at least with version 8.18.8)

• for kernel >= 2.6.13 Missing verify_area bug

fglrx 8.8.25

• for kernels >= 2.6.10
• For kernels >= 2.6.11-rc1

Links

• Gentoo HOWTO ATI