Difference between revisions of "Problems with fglrx"
(→fglrx 8.21.7) |
m (→fglrx 8.21.7) |
||
Line 163: | Line 163: | ||
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15] | * [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15] | ||
− | |||
===fglrx 8.20.8=== | ===fglrx 8.20.8=== |
Revision as of 01:46, 5 February 2006
This page discusses issues with the ATI proprietary fglrx display driver.
Contents
- 1 Known Troubles and Solutions
- 2 Patches
Known Troubles and Solutions
X-specific issues
The current ATI proprietary driver (8.21.7) works 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.
Kernel-specific troubles
Using the current ATI driver (8.21.7) with 2.6.15 or later 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.
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. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.
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.
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
.
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.
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.
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. 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.
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 |
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 |
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, 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).
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.19.10).
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' (rage3d.com/board) Linux area.
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.
Hardlock on X logout
Up from driver version 8.19.10 you will expierence 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 file add:
AlwaysRestartServer=true
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239
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.
Patches
The following patches might be needed for certain versions of fglrx.
fglrx 8.21.7
fglrx 8.20.8
or
fglrx (problem met at least with version 8.18.8)
- for kernel >= 2.6.13 Missing verify_area bug