ThinkWiki - User contributions [en]

Problems with fglrx

2007-10-24T05:08:15Z

Gsmenden: /* Composite Support */

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 ([http://www.sidux.com/PNphpBB2-viewtopic-t-3162-postdays-0-postorder-asc.html Debian] and [http://www.phoronix.net/forums/showthread.php?t=2382 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 [http://rage3d.com/board/showthread.php?s=4638d94143536f6acacbccd8f0443472&t=33889029 (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.

As of version 8.37.6, this issue is solved. No more binary hacking needed.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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.

==== 2.6.23 ====
In 2.6.23 release cycle, config option CONFIG_SUSPEND_SMP got renamed to CONFIG_PM_SLEEP_SMP. fglrx uses this variable for disabling power management on older kernels. As a result, SMP users running 2.6.23 weren't able to resume properly (almost instant lockup in that rare case fglrx managed to show a few usable pixels. A [http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-10/msg03437.html quick patch] is available.

=== 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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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:

:{{cmduser|fglrxinfo}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.1)}}

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri}}

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

instead of that:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|drmOpenByBusid: busid is PCI:1:0:0}}
:{{cmdresult|drmOpenDevice: minor is 0}}
:{{cmdresult|drmOpenDevice: node name is /dev/dri/card0}}
:{{cmdresult|drmOpenDevice: open result is 4, (OK)}}
:{{cmdresult|drmOpenByBusid: drmOpenMinor returns 4}}
:{{cmdresult|drmOpenByBusid: drmGetBusid reports PCI:1:0:0}}
:{{cmdresult|Can't open configuration file /home/merlin/.drirc: No such file or directory.}}
:{{cmdresult|fglrx: DPD supported.}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: ATI Technologies Inc.}}
:{{cmdresult|OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)}}
:{{cmdresult|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
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so}}
:{{cmdresult|libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)}}
:{{cmdresult|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
:{{cmduser|<nowiki>export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'</nowiki>}}
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
:{{cmduser|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 <code>/etc/profile.env</code> and <code>/etc/profile.csh</code>. 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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.
:{{cmdroot|eselect opengl set ati}}
If <tt>eselect opengl ati</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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...
|-
|{{T60p}}||Fedora Core 6 x86_64||2.6.20-1.2962_1.fc6.cubbi_suspend2|| 8.38.6||suspend2 hibernate||yes||suspend2 hibernate and resume working with libata driver (ahci not tested). Xv still broken since 8.35.5. Have not needed to set extra_pages_allowance thus far.
|-
|{{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
|-
|{{T60p}}||Gentoo||2.6.22-r8 gentoo-sources||8.39.4||Suspend to RAM,swsusp||yes||swsusp works without hibernate-script installed (installing breaks it), s-to-RAM works only with CONFIG_FB ''disabled'' in kernel. No acpi_sleep=... parameter, no special script, no vbetool.
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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, as of fglrx 8.42.3 added composite windowing (alpha channel), enabling hardware accelerated translucent windows (primarily for 'eye candy.') This has not been tested yet, and reports will be added here as users evaluate this versus the R300 open source drivers.

For reference, some discussion of current status of drivers can be found in the Rage3d forums' (http://rage3d.com/board) Linux area.

Composite support is also supported with recent Mesa and Xorg > 7 with the open source 3d radeon / R300 drivers found in the linux kernel or debian's driver repository. It works with the [[R300]] / FireGL T2 series as found on the T43p extremely well. This has made rapid progress in speed with the latest few releases, and as of kernel 2.6.23 runs perfectly well with an R300 based card.

===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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
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: {{path|/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: <s>[http://bugs.gentoo.org/show_bug.cgi?id=113685 113685]</s>. 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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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"

===Xv doesn't work correctly with drivers >= 8.36 and Xyyyy-cards===

See [http://ati.cchtml.com/show_bug.cgi?id=677] for further information. It seems as if only Xyyyy-cards are affected. Problem: graphical glitches with mplayer, programs like xine and totem might not start up at all. 8.35 doesn't seem to be affected

===Floating Point Exception with various X apps===

When the X server is left to autodetect the DPI, the fglrx driver may fail to supply the monitor dimensions. Video output switching may contribute to this bug.

Problems were experienced on T42p with Ubuntu 7.04, xorg-driver-fglrx 7.1.0-8.34.8+2.6.20.5-16.29.

This can be observed with xdpyinfo

:{{cmduser|xdpyinfo | grep dimensions}}
:{{cmdresult|dimensions: 1280x1024 pixels (0x0 millimeters)}}

Many applications will use the screen size and attempt to calculate DPI, resulting in a divide by zero operation and a SIGFPE.

A work around is to supply the dimensions in /etc/X11/xorg.conf. Use the DisplaySize parameter within your monitor's configuration. For example:

Section "Monitor"
Identifier "Generic Monitor"
HorizSync 28.0 - 64.0
VertRefresh 43.0 - 60.0
Option "DPMS"
DisplaySize 433 351
EndSection

== 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.37.6===
* For kernel 2.6.22 you need this patch from a [http://www.phoronix.com/forums/showthread.php?t=2849 Phoronix thread].

===fglrx 8.35.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.35.5-for-2.6.20.patch For kernel 2.6.20], part of the Fedora packaging scripts in the ATI installer

===fglrx 8.34.8===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.34.8-for-2.6.20.patch For kernel 2.6.20]

===fglrx 8.32.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.19/fglrx-8.32.5-for-2.6.19.patch For kernel 2.6.19]

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Fglrx

2007-10-24T05:04:27Z

Gsmenden: /* 3D acceleration */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: http://ati.amd.com/support/drivers/linux/linux-radeon.html

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}}
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
** [http://wiki.cchtml.com/index.php/Debian_Installation_Guide Debian Howto]
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 7 packages: http://rpm.livna.org
** The newest version of the driver (8.39.4) is supposed to work with Fedora 7, and is available from Livna.
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide Edgy Eft Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide Feisty Fawn Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.42.3 (23rd September 2007).
Major changes:
* 8.42.3: Composite support added enabling AIGLX and Beryl/Compiz on the desktop.
* 8.41.7: increased OpenGL performance on some Radeon Cards, size/position TV-out adjustments work for Radeon X1900 or higher, X crash when connecting external DFP display fixed
* 8.40.4: some new TV out control options in CCC, another (non-exciting) maintenance release (see [http://www.phoronix.com/scan.php?page=article&item=804&num=1 Phoronix])
* 8.39.4: kernel 2.6.22 support, TexturedVideo fix, aticonfig segfault fix (see 8.38.7 hotfix), to get rid of the "AMD Testing use only" logo, use [http://www.phoronix.com/forums/showpost.php?p=10641&postcount=44 this] workaround.
* 8.38.7: hotfix release for "Using aticonfig --initial segfaults destroying xorg.conf file when run in X with Vesa driver.", search for "737-28261" on the ATI website.
* 8.38.6: RedHat Enterprise Linux 5 support, Xserver crashes on moving video window between two monitors fixed, corruption when playing multiple vodeps with textured video fixed
* 8.37.6: Xorg Server 1.3 support, CCC 1.0, crash when logging off from X fixed, Xv cropping bug fixed
* 8.36.5: Kernel 2.6.20 support, CCC Beta 0.9 with localization
* 8.35.5: Beta AMD Catalyst Control Center, X-Server termination from console does not result in a blank screen. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.35.5|fglrx patches section]]).
* 8.34.8: Radeon Xpress 1250 support, X-Video on x86_64 fix, hibernation mode fix. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.34.8|fglrx patches section]]).
* 8.33.6: X.Org 7.2 support, kernel 2.6.19 support, some fixes in the installer, 2 more bugfixes. Resume from suspend works if you make sure you have set "VbetoolPost no" and "EnableVbetool no" in your suspend to ram hibernate conf (/etc/hibernate/ram.conf on ubuntu/debian).
* 8.32.5: support for X1650, X.Org 7.2 RC2 support, bugfixes. Suspend-to-ram is broken with specific cards, *no* 2.6.19 support (see [[Problems_with_fglrx#fglrx_8.32.5|fglrx patches section]]).
* 8.31.5: no new features, only bugfixes. Of note, for some users, this version breaks suspend-to-ram and suspend-to-disk.
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!

However the situation seems to be changing significantly as time goes on. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps and stable. As of October 2007 there is dramatic improvement in the open source 3d drivers in speed and stability.

=== 3D acceleration ===

According to [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] you need these options:

Section "Module"
...
Load "GLcore"
Load "glx"
Load "dri"
...
EndSection

# Of course you need to activate the driver
Section "Device"
...
Driver "fglrx"
EndSection

Don't forget to load the module <tt>fglrx</tt> (<tt>modprobe fglrx</tt>). Under Debian the module can be placed in <tt>/etc/modules</tt>.

With fglrx drivers prior to 8.42.3 will need to disable composite to enable 3D DRI acceleration. To do this, add an extra Extensions section (if necessary) containing:

Section "Extensions"
Option "Composite" "Disable" #make DRI work with fglrx.
EndSection

If you are unsure whether you have DRI running, issue <tt>glxinfo | grep -i direct</tt> after disabling composite. Note, this

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.

You may be able to preserve VideoOverlay acceleration if you explicitly remove the OpenGLOverlay using:

Option "VideoOverlay" "True" and Option "OpenGLOverlay" "False". See [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] for detail.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

=== Suspending with fglrx ===

On a ThinkPad T42 with Kernel 2.6.19 with Software Suspend 2 and R60 with Kernel 2.6.18-suspend2-r1 (Gentoo) , the following addition to <tt>/etc/hibernate/suspend2.conf</tt> is required:

# For fglrx
ProcSetting extra_pages_allowance 20000

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

The '''Catalyst Control Center''', which comes with the driver (at least from Livna in Fedora Core 6) can be used to do this switching. It also does various other kinds of display managements. However, the version that comes with 8.39.4 doesn't seem to handle switching into Big Desktop mode, does anyone know how to get this to work? The control center also complains a lot about rebooting, but rebooting doesn't seem to be required. Does anyone have decent documentation for the control center?

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}, {{Z61p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Fglrx

2007-10-24T05:03:20Z

Gsmenden: /* Status */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: http://ati.amd.com/support/drivers/linux/linux-radeon.html

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}}
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
** [http://wiki.cchtml.com/index.php/Debian_Installation_Guide Debian Howto]
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 7 packages: http://rpm.livna.org
** The newest version of the driver (8.39.4) is supposed to work with Fedora 7, and is available from Livna.
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide Edgy Eft Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide Feisty Fawn Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.42.3 (23rd September 2007).
Major changes:
* 8.42.3: Composite support added enabling AIGLX and Beryl/Compiz on the desktop.
* 8.41.7: increased OpenGL performance on some Radeon Cards, size/position TV-out adjustments work for Radeon X1900 or higher, X crash when connecting external DFP display fixed
* 8.40.4: some new TV out control options in CCC, another (non-exciting) maintenance release (see [http://www.phoronix.com/scan.php?page=article&item=804&num=1 Phoronix])
* 8.39.4: kernel 2.6.22 support, TexturedVideo fix, aticonfig segfault fix (see 8.38.7 hotfix), to get rid of the "AMD Testing use only" logo, use [http://www.phoronix.com/forums/showpost.php?p=10641&postcount=44 this] workaround.
* 8.38.7: hotfix release for "Using aticonfig --initial segfaults destroying xorg.conf file when run in X with Vesa driver.", search for "737-28261" on the ATI website.
* 8.38.6: RedHat Enterprise Linux 5 support, Xserver crashes on moving video window between two monitors fixed, corruption when playing multiple vodeps with textured video fixed
* 8.37.6: Xorg Server 1.3 support, CCC 1.0, crash when logging off from X fixed, Xv cropping bug fixed
* 8.36.5: Kernel 2.6.20 support, CCC Beta 0.9 with localization
* 8.35.5: Beta AMD Catalyst Control Center, X-Server termination from console does not result in a blank screen. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.35.5|fglrx patches section]]).
* 8.34.8: Radeon Xpress 1250 support, X-Video on x86_64 fix, hibernation mode fix. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.34.8|fglrx patches section]]).
* 8.33.6: X.Org 7.2 support, kernel 2.6.19 support, some fixes in the installer, 2 more bugfixes. Resume from suspend works if you make sure you have set "VbetoolPost no" and "EnableVbetool no" in your suspend to ram hibernate conf (/etc/hibernate/ram.conf on ubuntu/debian).
* 8.32.5: support for X1650, X.Org 7.2 RC2 support, bugfixes. Suspend-to-ram is broken with specific cards, *no* 2.6.19 support (see [[Problems_with_fglrx#fglrx_8.32.5|fglrx patches section]]).
* 8.31.5: no new features, only bugfixes. Of note, for some users, this version breaks suspend-to-ram and suspend-to-disk.
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!

However the situation seems to be changing significantly as time goes on. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps and stable. As of October 2007 there is dramatic improvement in the open source 3d drivers in speed and stability.

=== 3D acceleration ===

According to [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] you need these options:

Section "Module"
...
Load "GLcore"
Load "glx"
Load "dri"
...
EndSection

# Of course you need to activate the driver
Section "Device"
...
Driver "fglrx"
EndSection

Don't forget to load the module <tt>fglrx</tt> (<tt>modprobe fglrx</tt>). Under Debian the module can be placed in <tt>/etc/modules</tt>.

With current fglrx drivers (as of 8.29.6) you must disable composite to get 3D DRI acceleration. To do this, add an extra Extensions section (if necessary) containing:

Section "Extensions"
Option "Composite" "Disable" #make DRI work with fglrx.
EndSection

If you are unsure whether you have DRI running, issue <tt>glxinfo | grep -i direct</tt> after disabling composite. Note, this

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.

You may be able to preserve VideoOverlay acceleration if you explicitly remove the OpenGLOverlay using:

Option "VideoOverlay" "True" and Option "OpenGLOverlay" "False". See [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] for detail.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

=== Suspending with fglrx ===

On a ThinkPad T42 with Kernel 2.6.19 with Software Suspend 2 and R60 with Kernel 2.6.18-suspend2-r1 (Gentoo) , the following addition to <tt>/etc/hibernate/suspend2.conf</tt> is required:

# For fglrx
ProcSetting extra_pages_allowance 20000

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

The '''Catalyst Control Center''', which comes with the driver (at least from Livna in Fedora Core 6) can be used to do this switching. It also does various other kinds of display managements. However, the version that comes with 8.39.4 doesn't seem to handle switching into Big Desktop mode, does anyone know how to get this to work? The control center also complains a lot about rebooting, but rebooting doesn't seem to be required. Does anyone have decent documentation for the control center?

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}, {{Z61p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

R300

2007-10-10T06:58:50Z

Gsmenden: /* Status */

== Status ==

The latest release version as found in kernel 2.6.23 provides good performance and is extremely stable. Of note, while the 3D performance is still not quite as good as the proprietary ATI kernel, this open-source version provides composite (alpha-channel) support allowing use of a modern 3D desktop with Beryl.

Of note, this R300 driver has made rapid improvement with ATI's continued release of driver specifications.

== R300 drivers with DRI support ==
In post-2.6.13 development kernels (and also 2.6.13-mm3), DRM support for the [http://r300.sourceforge.net/ R300] chips from ATI has been included. Together with a bleeding-edge version of [http://www.mesa3d.org/ Mesa] (at least 6.3.2), this will allow 3D acceleration support for systems having a chip like this without the need for the ATI binary only driver ([[Fglrx]]). The latest beta releases of [http://www.x.org/ X.Org] for 6.9/7.0 already have Mesa 6.3.2, but building the R300 DRI drivers is disabled by default.

== Kernel configuration ==
You need to build AGP support with
# CONFIG_AGP=y
# CONFIG_AGP_INTEL=y #for a ThinkPad T41p
and the Radeon DRM support with
# CONFIG_DRM=y
# CONFIG_DRM_RADEON=y
Alternatively, can also build modules instead of including the code into the kernel. The modules will then be automatically loaded when X starts up.

If everything works well, the device /dev/dri/card0 should show up.

== Mesa ==
If your distribution does not offer binary packages of the current Mesa development packages, you need to build them yourself. It might also be possible that the DRI driver is included in your X.Org packages, just look out for a file like {{path|/usr/X11R6/lib/modules/dri/r300_dri.so}}.

== X configuration ==
You will need to load the dri and GLcore extensions with
# Section "Module"
# ...
# module "dri"
# module "GLcore"
# ...
# EndSection
Note: In Xorg 7.0 you don't need to load GLCore manually anmore

My radeon configuration looks like this
# Section "Device"
# Identifier "firegl"
# Driver "radeon"
# BusID "PCI:1:0:0"
# ....
# Option "AGPFastWrite" "off" # "on" freezes my laptop
# Option "AGPMode" "4" # this value depends on your hardware, this one is for a T41p
# Option "DynamicClocks" "on"
# Option "ColorTiling" "on"
# EndSection

X will silently ignore if DRI cannot be activated for your card, so you should check yor X logfile. Just search for DRI and/or DRM. Afterwards, you might want to do the usual glxinfo/glxgears magic.

== Packages ==
*{{Debian}} Packages: http://packages.debian.org/libgl1-mesa-dri
*{{Gentoo}}:
:Emerge the latest Xorg (7.1). The opensource driver is in cvs since version 7.0
:Enable agp suuport in a kernel:
::Device Drivers --->
:::Character devices --->
::::<M> /dev/agpgart (AGP Support)
::::<M> Intel 440LX/BX/GX, I8xx and E7x05 chipset support
:Add the following two lines to {{path|/etc/modules.autoload.d/kernel-2.6}}:
agpgart
intel-agp
:or compile as a kernel.
:To enable 3D support, emerge latest x11-base/x11-drm
echo "x11-base/x11-drm" >> /etc/portage/package.keywords
emerge x11-base/x11-drm
*{{Fedora}} 5
The development repository has a stable implementation.
To install do
:yum --enablerepo=development update 'xorg*' 'libX*'

== Experimental stand-alone installation ==
If you want to test the latest r300 driver and X server without touching your main X tree, see [[How to compile an experimental X server]].

== Performance ==
With 2.6.14-rc1 + Mesa 6.3.2, glxgears (the dubious Linux 3D benchmark) gives ~2200 FPS on my ThinkPad T41p with a FireGL Mobility T2 and a 1.7GHz Pentium M, 1GB RAM.

There is to note that the Color-depth has great effect on this value.
on my R50p with 24Bit I get about 2k fps, with 16Bit i get about 1k-1.5k fps

With 2.6.15 + Mesa 6.3.2, glxgears gives ~1480 FPS on a ThinkPad T43 with a Radeon Mobility X300 and a 1.86GHz Pentium M, 512MB RAM, when AGPMode=8, EnablePageFlip=on, AGPFastWrite=on and RenderAccel=on. Adding AccelMethod=EXA reduces to 700 FPS but makes the Composite Extension be usable.

glxgear output:
9607 frames in 5.0 seconds = 1921.285 FPS
9574 frames in 5.0 seconds = 1914.716 FPS
9510 frames in 5.0 seconds = 1901.832 FPS
9643 frames in 5.0 seconds = 1928.568 FPS
9676 frames in 5.0 seconds = 1934.910 FPS
9553 frames in 5.0 seconds = 1910.021 FPS

== Troubleshooting ==
* Useful thread about two possible gotchas in Ubuntu Dapper: http://www.ubuntuforums.org/showthread.php?t=110008&page=5 (in short: mv /usr/X11R6/lib/modules/dri /usr/X11R6/lib/modules/dri.old;ln -s /usr/lib/dri /usr/X11R6/lib/modules/dri;apt-get remove --purge xorg-driver-fglrx)

== Useful links ==
* [http://dri.freedesktop.org/wiki/R300_20Portal R300 Portal on the DRI Wiki] - benchmarks, sample configs and other tips
* [http://r300.sourceforge.net The original R300 development page]
* [http://www.mesa3d.org Mesa 3D graphics library]
* [http://wiki.x.org/wiki/ChangesSince68 Rough changelog for X.Org 6.9]

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads (please add your own ones!):
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility FireGL M24 1T]]
** {{T43p}}

R300

2007-10-10T06:58:05Z

Gsmenden: /* Status */ - dramatic improvement with 2.6.23

== Status ==

The latest CVS version as found in kernel 2.6.23 provides good performance and is extremely stable. Of note, while the 3D performance is still not quite as good as the proprietary ATI kernel, this open-source version provides composite (alpha-channel) support allowing use of a modern 3D desktop with Beryl.

Of note, this R300 driver has made rapid improvement with ATI's continued release of driver specifications.

== R300 drivers with DRI support ==
In post-2.6.13 development kernels (and also 2.6.13-mm3), DRM support for the [http://r300.sourceforge.net/ R300] chips from ATI has been included. Together with a bleeding-edge version of [http://www.mesa3d.org/ Mesa] (at least 6.3.2), this will allow 3D acceleration support for systems having a chip like this without the need for the ATI binary only driver ([[Fglrx]]). The latest beta releases of [http://www.x.org/ X.Org] for 6.9/7.0 already have Mesa 6.3.2, but building the R300 DRI drivers is disabled by default.

== Kernel configuration ==
You need to build AGP support with
# CONFIG_AGP=y
# CONFIG_AGP_INTEL=y #for a ThinkPad T41p
and the Radeon DRM support with
# CONFIG_DRM=y
# CONFIG_DRM_RADEON=y
Alternatively, can also build modules instead of including the code into the kernel. The modules will then be automatically loaded when X starts up.

If everything works well, the device /dev/dri/card0 should show up.

== Mesa ==
If your distribution does not offer binary packages of the current Mesa development packages, you need to build them yourself. It might also be possible that the DRI driver is included in your X.Org packages, just look out for a file like {{path|/usr/X11R6/lib/modules/dri/r300_dri.so}}.

== X configuration ==
You will need to load the dri and GLcore extensions with
# Section "Module"
# ...
# module "dri"
# module "GLcore"
# ...
# EndSection
Note: In Xorg 7.0 you don't need to load GLCore manually anmore

My radeon configuration looks like this
# Section "Device"
# Identifier "firegl"
# Driver "radeon"
# BusID "PCI:1:0:0"
# ....
# Option "AGPFastWrite" "off" # "on" freezes my laptop
# Option "AGPMode" "4" # this value depends on your hardware, this one is for a T41p
# Option "DynamicClocks" "on"
# Option "ColorTiling" "on"
# EndSection

X will silently ignore if DRI cannot be activated for your card, so you should check yor X logfile. Just search for DRI and/or DRM. Afterwards, you might want to do the usual glxinfo/glxgears magic.

== Packages ==
*{{Debian}} Packages: http://packages.debian.org/libgl1-mesa-dri
*{{Gentoo}}:
:Emerge the latest Xorg (7.1). The opensource driver is in cvs since version 7.0
:Enable agp suuport in a kernel:
::Device Drivers --->
:::Character devices --->
::::<M> /dev/agpgart (AGP Support)
::::<M> Intel 440LX/BX/GX, I8xx and E7x05 chipset support
:Add the following two lines to {{path|/etc/modules.autoload.d/kernel-2.6}}:
agpgart
intel-agp
:or compile as a kernel.
:To enable 3D support, emerge latest x11-base/x11-drm
echo "x11-base/x11-drm" >> /etc/portage/package.keywords
emerge x11-base/x11-drm
*{{Fedora}} 5
The development repository has a stable implementation.
To install do
:yum --enablerepo=development update 'xorg*' 'libX*'

== Experimental stand-alone installation ==
If you want to test the latest r300 driver and X server without touching your main X tree, see [[How to compile an experimental X server]].

== Performance ==
With 2.6.14-rc1 + Mesa 6.3.2, glxgears (the dubious Linux 3D benchmark) gives ~2200 FPS on my ThinkPad T41p with a FireGL Mobility T2 and a 1.7GHz Pentium M, 1GB RAM.

There is to note that the Color-depth has great effect on this value.
on my R50p with 24Bit I get about 2k fps, with 16Bit i get about 1k-1.5k fps

With 2.6.15 + Mesa 6.3.2, glxgears gives ~1480 FPS on a ThinkPad T43 with a Radeon Mobility X300 and a 1.86GHz Pentium M, 512MB RAM, when AGPMode=8, EnablePageFlip=on, AGPFastWrite=on and RenderAccel=on. Adding AccelMethod=EXA reduces to 700 FPS but makes the Composite Extension be usable.

glxgear output:
9607 frames in 5.0 seconds = 1921.285 FPS
9574 frames in 5.0 seconds = 1914.716 FPS
9510 frames in 5.0 seconds = 1901.832 FPS
9643 frames in 5.0 seconds = 1928.568 FPS
9676 frames in 5.0 seconds = 1934.910 FPS
9553 frames in 5.0 seconds = 1910.021 FPS

== Troubleshooting ==
* Useful thread about two possible gotchas in Ubuntu Dapper: http://www.ubuntuforums.org/showthread.php?t=110008&page=5 (in short: mv /usr/X11R6/lib/modules/dri /usr/X11R6/lib/modules/dri.old;ln -s /usr/lib/dri /usr/X11R6/lib/modules/dri;apt-get remove --purge xorg-driver-fglrx)

== Useful links ==
* [http://dri.freedesktop.org/wiki/R300_20Portal R300 Portal on the DRI Wiki] - benchmarks, sample configs and other tips
* [http://r300.sourceforge.net The original R300 development page]
* [http://www.mesa3d.org Mesa 3D graphics library]
* [http://wiki.x.org/wiki/ChangesSince68 Rough changelog for X.Org 6.9]

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads (please add your own ones!):
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility FireGL M24 1T]]
** {{T43p}}

Problems with fglrx

2007-10-10T06:53:44Z

Gsmenden: /* Composite Support */

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 ([http://www.sidux.com/PNphpBB2-viewtopic-t-3162-postdays-0-postorder-asc.html Debian] and [http://www.phoronix.net/forums/showthread.php?t=2382 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 [http://rage3d.com/board/showthread.php?s=4638d94143536f6acacbccd8f0443472&t=33889029 (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.

As of version 8.37.6, this issue is solved. No more binary hacking needed.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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:

:{{cmduser|fglrxinfo}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.1)}}

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri}}

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

instead of that:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|drmOpenByBusid: busid is PCI:1:0:0}}
:{{cmdresult|drmOpenDevice: minor is 0}}
:{{cmdresult|drmOpenDevice: node name is /dev/dri/card0}}
:{{cmdresult|drmOpenDevice: open result is 4, (OK)}}
:{{cmdresult|drmOpenByBusid: drmOpenMinor returns 4}}
:{{cmdresult|drmOpenByBusid: drmGetBusid reports PCI:1:0:0}}
:{{cmdresult|Can't open configuration file /home/merlin/.drirc: No such file or directory.}}
:{{cmdresult|fglrx: DPD supported.}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: ATI Technologies Inc.}}
:{{cmdresult|OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)}}
:{{cmdresult|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
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so}}
:{{cmdresult|libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)}}
:{{cmdresult|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
:{{cmduser|<nowiki>export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'</nowiki>}}
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
:{{cmduser|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 <code>/etc/profile.env</code> and <code>/etc/profile.csh</code>. 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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.
:{{cmdroot|eselect opengl set ati}}
If <tt>eselect opengl ati</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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...
|-
|{{T60p}}||Fedora Core 6 x86_64||2.6.20-1.2962_1.fc6.cubbi_suspend2|| 8.38.6||suspend2 hibernate||yes||suspend2 hibernate and resume working with libata driver (ahci not tested). Xv still broken since 8.35.5. Have not needed to set extra_pages_allowance thus far.
|-
|{{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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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 accelerated 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, however, supported with recent Mesa and Xorg > 7 with the open source 3d radeon drivers as found in the linux kernel or debian's driver repository. It works with the [[R300]] / FireGL T2 series as found on the T43p extremely well. This has made rapid progress in speed with the latest few releases, and as of kernel 2.6.23 runs perfectly well with an R300 based card.

===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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
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: {{path|/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: <s>[http://bugs.gentoo.org/show_bug.cgi?id=113685 113685]</s>. 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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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"

===Xv doesn't work correctly with drivers >= 8.36 and Xyyyy-cards===

See [http://ati.cchtml.com/show_bug.cgi?id=677] for further information. It seems as if only Xyyyy-cards are affected. Problem: graphical glitches with mplayer, programs like xine and totem might not start up at all. 8.35 doesn't seem to be affected

===Floating Point Exception with various X apps===

When the X server is left to autodetect the DPI, the fglrx driver may fail to supply the monitor dimensions. Video output switching may contribute to this bug.

Problems were experienced on T42p with Ubuntu 7.04, xorg-driver-fglrx 7.1.0-8.34.8+2.6.20.5-16.29.

This can be observed with xdpyinfo

:{{cmduser|xdpyinfo | grep dimensions}}
:{{cmdresult|dimensions: 1280x1024 pixels (0x0 millimeters)}}

Many applications will use the screen size and attempt to calculate DPI, resulting in a divide by zero operation and a SIGFPE.

A work around is to supply the dimensions in /etc/X11/xorg.conf. Use the DisplaySize parameter within your monitor's configuration. For example:

Section "Monitor"
Identifier "Generic Monitor"
HorizSync 28.0 - 64.0
VertRefresh 43.0 - 60.0
Option "DPMS"
DisplaySize 433 351
EndSection

== 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.37.6===
* For kernel 2.6.22 you need this patch from a [http://www.phoronix.com/forums/showthread.php?t=2849 Phoronix thread].

===fglrx 8.35.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.35.5-for-2.6.20.patch For kernel 2.6.20], part of the Fedora packaging scripts in the ATI installer

===fglrx 8.34.8===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.34.8-for-2.6.20.patch For kernel 2.6.20]

===fglrx 8.32.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.19/fglrx-8.32.5-for-2.6.19.patch For kernel 2.6.19]

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Fglrx

2007-10-10T06:50:33Z

Gsmenden: /* Speed */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: http://ati.amd.com/support/drivers/linux/linux-radeon.html

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}}
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
** [http://wiki.cchtml.com/index.php/Debian_Installation_Guide Debian Howto]
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 7 packages: http://rpm.livna.org
** The newest version of the driver (8.39.4) is supposed to work with Fedora 7, and is available from Livna.
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide Edgy Eft Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide Feisty Fawn Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.41.7 ( 10th September 2007).
Major changes:
* 8.41.7: increased OpenGL performance on some Radeon Cards, size/position TV-out adjustments work for Radeon X1900 or higher, X crash when connecting external DFP display fixed
* 8.40.4: some new TV out control options in CCC, another (non-exciting) maintenance release (see [http://www.phoronix.com/scan.php?page=article&item=804&num=1 Phoronix])
* 8.39.4: kernel 2.6.22 support, TexturedVideo fix, aticonfig segfault fix (see 8.38.7 hotfix), to get rid of the "AMD Testing use only" logo, use [http://www.phoronix.com/forums/showpost.php?p=10641&postcount=44 this] workaround.
* 8.38.7: hotfix release for "Using aticonfig --initial segfaults destroying xorg.conf file when run in X with Vesa driver.", search for "737-28261" on the ATI website.
* 8.38.6: RedHat Enterprise Linux 5 support, Xserver crashes on moving video window between two monitors fixed, corruption when playing multiple vodeps with textured video fixed
* 8.37.6: Xorg Server 1.3 support, CCC 1.0, crash when logging off from X fixed, Xv cropping bug fixed
* 8.36.5: Kernel 2.6.20 support, CCC Beta 0.9 with localization
* 8.35.5: Beta AMD Catalyst Control Center, X-Server termination from console does not result in a blank screen. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.35.5|fglrx patches section]]).
* 8.34.8: Radeon Xpress 1250 support, X-Video on x86_64 fix, hibernation mode fix. Kernel 2.6.20 requires some patching (see [[Problems_with_fglrx#fglrx_8.34.8|fglrx patches section]]).
* 8.33.6: X.Org 7.2 support, kernel 2.6.19 support, some fixes in the installer, 2 more bugfixes. Resume from suspend works if you make sure you have set "VbetoolPost no" and "EnableVbetool no" in your suspend to ram hibernate conf (/etc/hibernate/ram.conf on ubuntu/debian).
* 8.32.5: support for X1650, X.Org 7.2 RC2 support, bugfixes. Suspend-to-ram is broken with specific cards, *no* 2.6.19 support (see [[Problems_with_fglrx#fglrx_8.32.5|fglrx patches section]]).
* 8.31.5: no new features, only bugfixes. Of note, for some users, this version breaks suspend-to-ram and suspend-to-disk.
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!

However the situation seems to be changing significantly as time goes on. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps and stable. As of October 2007 there is dramatic improvement in the open source 3d drivers in speed and stability.

=== 3D acceleration ===

According to [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] you need these options:

Section "Module"
...
Load "GLcore"
Load "glx"
Load "dri"
...
EndSection

# Of course you need to activate the driver
Section "Device"
...
Driver "fglrx"
EndSection

Don't forget to load the module <tt>fglrx</tt> (<tt>modprobe fglrx</tt>). Under Debian the module can be placed in <tt>/etc/modules</tt>.

With current fglrx drivers (as of 8.29.6) you must disable composite to get 3D DRI acceleration. To do this, add an extra Extensions section (if necessary) containing:

Section "Extensions"
Option "Composite" "Disable" #make DRI work with fglrx.
EndSection

If you are unsure whether you have DRI running, issue <tt>glxinfo | grep -i direct</tt> after disabling composite. Note, this

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.

You may be able to preserve VideoOverlay acceleration if you explicitly remove the OpenGLOverlay using:

Option "VideoOverlay" "True" and Option "OpenGLOverlay" "False". See [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] for detail.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

=== Suspending with fglrx ===

On a ThinkPad T42 with Kernel 2.6.19 with Software Suspend 2 and R60 with Kernel 2.6.18-suspend2-r1 (Gentoo) , the following addition to <tt>/etc/hibernate/suspend2.conf</tt> is required:

# For fglrx
ProcSetting extra_pages_allowance 20000

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

The '''Catalyst Control Center''', which comes with the driver (at least from Livna in Fedora Core 6) can be used to do this switching. It also does various other kinds of display managements. However, the version that comes with 8.39.4 doesn't seem to handle switching into Big Desktop mode, does anyone know how to get this to work? The control center also complains a lot about rebooting, but rebooting doesn't seem to be required. Does anyone have decent documentation for the control center?

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}, {{Z61p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Problem with broken sound on some ThinkPads

2007-09-13T18:31:47Z

Gsmenden: /* Affected Models */

Information about the phenomena of broken sound on some ThinkPad models.

==Problem description==
There are two sound chips in these machines, a PCI based [[CS4610|Crystal SoundFusion 4610]], and an ISA based [[CS4239|Crystal SoundFusion 4239]].

The Linux drivers for the CS4610 (both OSS and ALSA) expect to find it paired with an AC'97 codec chip, while instead the CS4610 is paired with the ISA CS4239. This was done, because at the time this allowed DOS games to output sound using SoundBlaster Pro emulation.

To get sound under Linux you will have to use the OSS cs4232 or ALSA snd-cs4236 driver for the ISA soundchip instead.

A good thread on the problem can be found in the [http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg01181.html alsa-devel mailing list]

There is also a separate issue with recent ALSA builds and the Intel AD1981-1984 chip. [[http://www.linuxquestions.org/questions/showthread.php?p=2879174]] This causes problems starting with alsa shipped with kernel 2.6.22. Workarounds include manually updating ALSA or using your distributions version rather than the kernel version. Also see [[AD1984]] for patches.

==Affected Models==
*ThinkPad {{600E}}
*ThinkPad {{770X}}, {{770Z}}
*Thinkpad {{T43p}}, {{T60}}, {{T61}}

==Solutions==
===Activating the devices===
First you must make sure that the sound devices are activated.

Disable "Quick Boot" in your ThinkPad BIOS, otherwise the sound devices will not be activated by the BIOS.
To enter the BIOS, power cycle your ThinkPad and press F1 when the ThinkPad screen shows.

You can also manually activate the sound card once booted:
* With apm and pnpbios, this is done with setpnp from the pcmcia package:
:{{cmdroot|setpnp 0x0e on}}
:{{cmdroot|setpnp 0x0f on}}

* With acpi and pnpacpi, use these commands:
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:06/resources}}

It seems that with very new kernels and ACPI enabled, you will need to manually enable the device even if you have correctly disabled "Quick Boot".

This only works with newer kernels that fully support pnpacpi, and provided that [http://bugzilla.kernel.org/show_bug.cgi?id=3912 this patch] has been applied (applied to Linus' tree in july 2005).

It seems that the default dma numbers change when pnpacpi is used (to dma1=1 dma2=3, for instance).

If you're using acpi and pnpacpi, you can see which resources the sound card is using like this:
:{{cmdroot|cat /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|cat /sys/devices/pnp0/00:06/resources}}

===Using ALSA===
Compile the sound driver as a module and load it after everything else.
You can add the following line to a boot script, ie. {{path|rc.local}} for that:
/sbin/modprobe snd-cs4236 index=0 port=0x530 cport=0x538 irq=5 dma1=1 dma2=0 isapnp=0

This is reported to work at least with kernel 2.6.9, 2.6.13 and 2.6.15.

On the 770x using kernel 2.6.16/2.6.17 you may try this:
/sbin/modprobe snd-cs4232 port=0x530 cport=0x120 irq=5 dma1=1 dma2=0 isapnp=0

There is a [[Script for configuring the CS4239 sound chip in PnP mode|nice script]] which can do all this for you, including activation of the device and detecting the correct resource settings to use.

===Using OSS===
Add the following lines to a boot script, ie. {{path|rc.local}}:
modprobe sound
insmod ad1848
insmod uart401
insmod cs4232 io=0x530 irq=5 dma=1 dma2=0

or try from commandline:

modprobe cs4232 io=0x530 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=7 synthio=0x330 synthirq=7 (parameter not necessarily)

In case an insmod or modprobe of cs4232 fails with the following error appearing at the console, via dmesg, or in {{path|/var/log/messages}}, double-check you have ''QUICKBOOT (in the BIOS) disabled''.
modprobe: FATAL: Error inserting cs4232: No such device

====Audio loops====
If your OSS module loads like it should, but audio loops or sounds choppy then reloading the module should help:
:{{cmdroot|rmmod cs4232 && modprobe cs4232}}

(For the modprobe command to work without IRQ/IO/DMA parameters, you'll probably want to add the correct parameters as an "options" clause in {{path|/etc/modprobe.conf}}).

Problem with broken sound on some ThinkPads

2007-09-13T18:30:43Z

Gsmenden: /* Problem description */

Information about the phenomena of broken sound on some ThinkPad models.

==Problem description==
There are two sound chips in these machines, a PCI based [[CS4610|Crystal SoundFusion 4610]], and an ISA based [[CS4239|Crystal SoundFusion 4239]].

The Linux drivers for the CS4610 (both OSS and ALSA) expect to find it paired with an AC'97 codec chip, while instead the CS4610 is paired with the ISA CS4239. This was done, because at the time this allowed DOS games to output sound using SoundBlaster Pro emulation.

To get sound under Linux you will have to use the OSS cs4232 or ALSA snd-cs4236 driver for the ISA soundchip instead.

A good thread on the problem can be found in the [http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg01181.html alsa-devel mailing list]

There is also a separate issue with recent ALSA builds and the Intel AD1981-1984 chip. [[http://www.linuxquestions.org/questions/showthread.php?p=2879174]] This causes problems starting with alsa shipped with kernel 2.6.22. Workarounds include manually updating ALSA or using your distributions version rather than the kernel version. Also see [[AD1984]] for patches.

==Affected Models==
*ThinkPad {{600E}}
*ThinkPad {{770X}}, {{770Z}}
*Thinkpad {{T43p}}

==Solutions==
===Activating the devices===
First you must make sure that the sound devices are activated.

Disable "Quick Boot" in your ThinkPad BIOS, otherwise the sound devices will not be activated by the BIOS.
To enter the BIOS, power cycle your ThinkPad and press F1 when the ThinkPad screen shows.

You can also manually activate the sound card once booted:
* With apm and pnpbios, this is done with setpnp from the pcmcia package:
:{{cmdroot|setpnp 0x0e on}}
:{{cmdroot|setpnp 0x0f on}}

* With acpi and pnpacpi, use these commands:
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:06/resources}}

It seems that with very new kernels and ACPI enabled, you will need to manually enable the device even if you have correctly disabled "Quick Boot".

This only works with newer kernels that fully support pnpacpi, and provided that [http://bugzilla.kernel.org/show_bug.cgi?id=3912 this patch] has been applied (applied to Linus' tree in july 2005).

It seems that the default dma numbers change when pnpacpi is used (to dma1=1 dma2=3, for instance).

If you're using acpi and pnpacpi, you can see which resources the sound card is using like this:
:{{cmdroot|cat /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|cat /sys/devices/pnp0/00:06/resources}}

===Using ALSA===
Compile the sound driver as a module and load it after everything else.
You can add the following line to a boot script, ie. {{path|rc.local}} for that:
/sbin/modprobe snd-cs4236 index=0 port=0x530 cport=0x538 irq=5 dma1=1 dma2=0 isapnp=0

This is reported to work at least with kernel 2.6.9, 2.6.13 and 2.6.15.

On the 770x using kernel 2.6.16/2.6.17 you may try this:
/sbin/modprobe snd-cs4232 port=0x530 cport=0x120 irq=5 dma1=1 dma2=0 isapnp=0

There is a [[Script for configuring the CS4239 sound chip in PnP mode|nice script]] which can do all this for you, including activation of the device and detecting the correct resource settings to use.

===Using OSS===
Add the following lines to a boot script, ie. {{path|rc.local}}:
modprobe sound
insmod ad1848
insmod uart401
insmod cs4232 io=0x530 irq=5 dma=1 dma2=0

or try from commandline:

modprobe cs4232 io=0x530 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=7 synthio=0x330 synthirq=7 (parameter not necessarily)

In case an insmod or modprobe of cs4232 fails with the following error appearing at the console, via dmesg, or in {{path|/var/log/messages}}, double-check you have ''QUICKBOOT (in the BIOS) disabled''.
modprobe: FATAL: Error inserting cs4232: No such device

====Audio loops====
If your OSS module loads like it should, but audio loops or sounds choppy then reloading the module should help:
:{{cmdroot|rmmod cs4232 && modprobe cs4232}}

(For the modprobe command to work without IRQ/IO/DMA parameters, you'll probably want to add the correct parameters as an "options" clause in {{path|/etc/modprobe.conf}}).

Problem with broken sound on some ThinkPads

2007-09-13T18:29:52Z

Gsmenden: /* Problem description */

Information about the phenomena of broken sound on some ThinkPad models.

==Problem description==
There are two sound chips in these machines, a PCI based [[CS4610|Crystal SoundFusion 4610]], and an ISA based [[CS4239|Crystal SoundFusion 4239]].

The Linux drivers for the CS4610 (both OSS and ALSA) expect to find it paired with an AC'97 codec chip, while instead the CS4610 is paired with the ISA CS4239. This was done, because at the time this allowed DOS games to output sound using SoundBlaster Pro emulation.

To get sound under Linux you will have to use the OSS cs4232 or ALSA snd-cs4236 driver for the ISA soundchip instead.

A good thread on the problem can be found in the [http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg01181.html alsa-devel mailing list]

There is also a separate issue with recent ALSA builds and the Intel AD1981-1984 chip. [[http://www.linuxquestions.org/questions/showthread.php?p=2879174]] This causes problems starting with alsa shipped with kernel 2.6.22. Workarounds include manually updating ALSA or using your distributions version rather than the kernel version. Also see {{AD1984}} for patches.

==Affected Models==
*ThinkPad {{600E}}
*ThinkPad {{770X}}, {{770Z}}
*Thinkpad {{T43p}}

==Solutions==
===Activating the devices===
First you must make sure that the sound devices are activated.

Disable "Quick Boot" in your ThinkPad BIOS, otherwise the sound devices will not be activated by the BIOS.
To enter the BIOS, power cycle your ThinkPad and press F1 when the ThinkPad screen shows.

You can also manually activate the sound card once booted:
* With apm and pnpbios, this is done with setpnp from the pcmcia package:
:{{cmdroot|setpnp 0x0e on}}
:{{cmdroot|setpnp 0x0f on}}

* With acpi and pnpacpi, use these commands:
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:06/resources}}

It seems that with very new kernels and ACPI enabled, you will need to manually enable the device even if you have correctly disabled "Quick Boot".

This only works with newer kernels that fully support pnpacpi, and provided that [http://bugzilla.kernel.org/show_bug.cgi?id=3912 this patch] has been applied (applied to Linus' tree in july 2005).

It seems that the default dma numbers change when pnpacpi is used (to dma1=1 dma2=3, for instance).

If you're using acpi and pnpacpi, you can see which resources the sound card is using like this:
:{{cmdroot|cat /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|cat /sys/devices/pnp0/00:06/resources}}

===Using ALSA===
Compile the sound driver as a module and load it after everything else.
You can add the following line to a boot script, ie. {{path|rc.local}} for that:
/sbin/modprobe snd-cs4236 index=0 port=0x530 cport=0x538 irq=5 dma1=1 dma2=0 isapnp=0

This is reported to work at least with kernel 2.6.9, 2.6.13 and 2.6.15.

On the 770x using kernel 2.6.16/2.6.17 you may try this:
/sbin/modprobe snd-cs4232 port=0x530 cport=0x120 irq=5 dma1=1 dma2=0 isapnp=0

There is a [[Script for configuring the CS4239 sound chip in PnP mode|nice script]] which can do all this for you, including activation of the device and detecting the correct resource settings to use.

===Using OSS===
Add the following lines to a boot script, ie. {{path|rc.local}}:
modprobe sound
insmod ad1848
insmod uart401
insmod cs4232 io=0x530 irq=5 dma=1 dma2=0

or try from commandline:

modprobe cs4232 io=0x530 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=7 synthio=0x330 synthirq=7 (parameter not necessarily)

In case an insmod or modprobe of cs4232 fails with the following error appearing at the console, via dmesg, or in {{path|/var/log/messages}}, double-check you have ''QUICKBOOT (in the BIOS) disabled''.
modprobe: FATAL: Error inserting cs4232: No such device

====Audio loops====
If your OSS module loads like it should, but audio loops or sounds choppy then reloading the module should help:
:{{cmdroot|rmmod cs4232 && modprobe cs4232}}

(For the modprobe command to work without IRQ/IO/DMA parameters, you'll probably want to add the correct parameters as an "options" clause in {{path|/etc/modprobe.conf}}).

Problem with broken sound on some ThinkPads

2007-09-13T18:26:53Z

Gsmenden: /* Affected Models */ - Additional problem

Information about the phenomena of broken sound on some ThinkPad models.

==Problem description==
There are two sound chips in these machines, a PCI based [[CS4610|Crystal SoundFusion 4610]], and an ISA based [[CS4239|Crystal SoundFusion 4239]].

The Linux drivers for the CS4610 (both OSS and ALSA) expect to find it paired with an AC'97 codec chip, while instead the CS4610 is paired with the ISA CS4239. This was done, because at the time this allowed DOS games to output sound using SoundBlaster Pro emulation.

To get sound under Linux you will have to use the OSS cs4232 or ALSA snd-cs4236 driver for the ISA soundchip instead.

A good thread on the problem can be found in the [http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg01181.html alsa-devel mailing list]

==Affected Models==
*ThinkPad {{600E}}
*ThinkPad {{770X}}, {{770Z}}
*Thinkpad {{T43p}}

==Solutions==
===Activating the devices===
First you must make sure that the sound devices are activated.

Disable "Quick Boot" in your ThinkPad BIOS, otherwise the sound devices will not be activated by the BIOS.
To enter the BIOS, power cycle your ThinkPad and press F1 when the ThinkPad screen shows.

You can also manually activate the sound card once booted:
* With apm and pnpbios, this is done with setpnp from the pcmcia package:
:{{cmdroot|setpnp 0x0e on}}
:{{cmdroot|setpnp 0x0f on}}

* With acpi and pnpacpi, use these commands:
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:06/resources}}

It seems that with very new kernels and ACPI enabled, you will need to manually enable the device even if you have correctly disabled "Quick Boot".

This only works with newer kernels that fully support pnpacpi, and provided that [http://bugzilla.kernel.org/show_bug.cgi?id=3912 this patch] has been applied (applied to Linus' tree in july 2005).

It seems that the default dma numbers change when pnpacpi is used (to dma1=1 dma2=3, for instance).

If you're using acpi and pnpacpi, you can see which resources the sound card is using like this:
:{{cmdroot|cat /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|cat /sys/devices/pnp0/00:06/resources}}

===Using ALSA===
Compile the sound driver as a module and load it after everything else.
You can add the following line to a boot script, ie. {{path|rc.local}} for that:
/sbin/modprobe snd-cs4236 index=0 port=0x530 cport=0x538 irq=5 dma1=1 dma2=0 isapnp=0

This is reported to work at least with kernel 2.6.9, 2.6.13 and 2.6.15.

On the 770x using kernel 2.6.16/2.6.17 you may try this:
/sbin/modprobe snd-cs4232 port=0x530 cport=0x120 irq=5 dma1=1 dma2=0 isapnp=0

There is a [[Script for configuring the CS4239 sound chip in PnP mode|nice script]] which can do all this for you, including activation of the device and detecting the correct resource settings to use.

===Using OSS===
Add the following lines to a boot script, ie. {{path|rc.local}}:
modprobe sound
insmod ad1848
insmod uart401
insmod cs4232 io=0x530 irq=5 dma=1 dma2=0

or try from commandline:

modprobe cs4232 io=0x530 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=7 synthio=0x330 synthirq=7 (parameter not necessarily)

In case an insmod or modprobe of cs4232 fails with the following error appearing at the console, via dmesg, or in {{path|/var/log/messages}}, double-check you have ''QUICKBOOT (in the BIOS) disabled''.
modprobe: FATAL: Error inserting cs4232: No such device

====Audio loops====
If your OSS module loads like it should, but audio loops or sounds choppy then reloading the module should help:
:{{cmdroot|rmmod cs4232 && modprobe cs4232}}

(For the modprobe command to work without IRQ/IO/DMA parameters, you'll probably want to add the correct parameters as an "options" clause in {{path|/etc/modprobe.conf}}).

Problem with broken sound on some ThinkPads

2007-09-13T18:25:56Z

Gsmenden: /* Affected Models */

Information about the phenomena of broken sound on some ThinkPad models.

==Problem description==
There are two sound chips in these machines, a PCI based [[CS4610|Crystal SoundFusion 4610]], and an ISA based [[CS4239|Crystal SoundFusion 4239]].

The Linux drivers for the CS4610 (both OSS and ALSA) expect to find it paired with an AC'97 codec chip, while instead the CS4610 is paired with the ISA CS4239. This was done, because at the time this allowed DOS games to output sound using SoundBlaster Pro emulation.

To get sound under Linux you will have to use the OSS cs4232 or ALSA snd-cs4236 driver for the ISA soundchip instead.

A good thread on the problem can be found in the [http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg01181.html alsa-devel mailing list]

==Affected Models==
*ThinkPad {{600E}}
*ThinkPad {{770X}}, {{770Z}}
*Thinkpad {{T43}}

==Solutions==
===Activating the devices===
First you must make sure that the sound devices are activated.

Disable "Quick Boot" in your ThinkPad BIOS, otherwise the sound devices will not be activated by the BIOS.
To enter the BIOS, power cycle your ThinkPad and press F1 when the ThinkPad screen shows.

You can also manually activate the sound card once booted:
* With apm and pnpbios, this is done with setpnp from the pcmcia package:
:{{cmdroot|setpnp 0x0e on}}
:{{cmdroot|setpnp 0x0f on}}

* With acpi and pnpacpi, use these commands:
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|echo 'activate' > /sys/devices/pnp0/00:06/resources}}

It seems that with very new kernels and ACPI enabled, you will need to manually enable the device even if you have correctly disabled "Quick Boot".

This only works with newer kernels that fully support pnpacpi, and provided that [http://bugzilla.kernel.org/show_bug.cgi?id=3912 this patch] has been applied (applied to Linus' tree in july 2005).

It seems that the default dma numbers change when pnpacpi is used (to dma1=1 dma2=3, for instance).

If you're using acpi and pnpacpi, you can see which resources the sound card is using like this:
:{{cmdroot|cat /sys/devices/pnp0/00:05/resources}}
:{{cmdroot|cat /sys/devices/pnp0/00:06/resources}}

===Using ALSA===
Compile the sound driver as a module and load it after everything else.
You can add the following line to a boot script, ie. {{path|rc.local}} for that:
/sbin/modprobe snd-cs4236 index=0 port=0x530 cport=0x538 irq=5 dma1=1 dma2=0 isapnp=0

This is reported to work at least with kernel 2.6.9, 2.6.13 and 2.6.15.

On the 770x using kernel 2.6.16/2.6.17 you may try this:
/sbin/modprobe snd-cs4232 port=0x530 cport=0x120 irq=5 dma1=1 dma2=0 isapnp=0

There is a [[Script for configuring the CS4239 sound chip in PnP mode|nice script]] which can do all this for you, including activation of the device and detecting the correct resource settings to use.

===Using OSS===
Add the following lines to a boot script, ie. {{path|rc.local}}:
modprobe sound
insmod ad1848
insmod uart401
insmod cs4232 io=0x530 irq=5 dma=1 dma2=0

or try from commandline:

modprobe cs4232 io=0x530 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=7 synthio=0x330 synthirq=7 (parameter not necessarily)

In case an insmod or modprobe of cs4232 fails with the following error appearing at the console, via dmesg, or in {{path|/var/log/messages}}, double-check you have ''QUICKBOOT (in the BIOS) disabled''.
modprobe: FATAL: Error inserting cs4232: No such device

====Audio loops====
If your OSS module loads like it should, but audio loops or sounds choppy then reloading the module should help:
:{{cmdroot|rmmod cs4232 && modprobe cs4232}}

(For the modprobe command to work without IRQ/IO/DMA parameters, you'll probably want to add the correct parameters as an "options" clause in {{path|/etc/modprobe.conf}}).

Template:Industry News

2007-09-05T15:16:54Z

Gsmenden: New drivers in September

5. 9. 2007: AMD/ATI announces [http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20070904006432&newsLang=en new HD2k Radeon drivers], pledging composite support and significant performance improvements on modern (2.6.22) kernels.

8. 8. 2007: New [[fglrx]] driver version 8.40.4 [https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.40.4.html released].

19. 7. 2007: New [[fglrx]] driver version 8.39.4 [https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.39.4.html released].

26. 6. 2007: New [[fglrx]] driver version 8.38.6 [https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.38.6.html released].

31. 5. 2007: New [[fglrx]] driver version 8.37.6 [https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.37.6.html released].

18. 4. 2007: New [[fglrx]] driver version 8.36.5 [https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.36.5.html released]. Now supports 2.6.20 series kernels.

Problems with fglrx

2007-06-13T11:30:06Z

Gsmenden: /* Composite Support */

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 ([http://www.sidux.com/PNphpBB2-viewtopic-t-3162-postdays-0-postorder-asc.html Debian] and [http://www.phoronix.net/forums/showthread.php?t=2382 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 [http://rage3d.com/board/showthread.php?s=4638d94143536f6acacbccd8f0443472&t=33889029 (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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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:

:{{cmduser|fglrxinfo}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.1)}}

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri}}

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

instead of that:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|drmOpenByBusid: busid is PCI:1:0:0}}
:{{cmdresult|drmOpenDevice: minor is 0}}
:{{cmdresult|drmOpenDevice: node name is /dev/dri/card0}}
:{{cmdresult|drmOpenDevice: open result is 4, (OK)}}
:{{cmdresult|drmOpenByBusid: drmOpenMinor returns 4}}
:{{cmdresult|drmOpenByBusid: drmGetBusid reports PCI:1:0:0}}
:{{cmdresult|Can't open configuration file /home/merlin/.drirc: No such file or directory.}}
:{{cmdresult|fglrx: DPD supported.}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: ATI Technologies Inc.}}
:{{cmdresult|OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)}}
:{{cmdresult|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
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so}}
:{{cmdresult|libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)}}
:{{cmdresult|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
:{{cmduser|<nowiki>export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'</nowiki>}}
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
:{{cmduser|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 <code>/etc/profile.env</code> and <code>/etc/profile.csh</code>. 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|-
|{{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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
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: {{path|/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: <s>[http://bugs.gentoo.org/show_bug.cgi?id=113685 113685]</s>. 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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.35.5-for-2.6.20.patch For kernel 2.6.20], part of the Fedora packaging scripts in the ATI installer

===fglrx 8.34.8===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.34.8-for-2.6.20.patch For kernel 2.6.20]

===fglrx 8.32.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.19/fglrx-8.32.5-for-2.6.19.patch For kernel 2.6.19]

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Ipw2200

2007-02-06T18:46:36Z

Gsmenden: Put correct path for 99.9% of all users

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
=== Intel PRO/Wireless 2200/2915 Driver for WiFi ===
Linux driver for the 802.11bg and 802.11abg NICs - miniPCI cards - found in Centrino laptops. This driver only works on 2.6.x kernels (2.6.4 or newer).

Starting with kernels 2.6.14 the driver is included in kernel.

The following adapters sold by IBM use these chips:
* [[Intel PRO/Wireless 2200BG Mini-PCI Adapter]]
* [[Intel PRO/Wireless 2915ABG Mini-PCI Adapter]]
|}

{{NOTE|Make sure you have installed the firmware! The ipw2200 documentation will tell you where to find these firmware files and where to install those.}}

=== Project Homepage / Availability ===
http://ipw2200.sourceforge.net/

Included in mainline Linux kernels, tracking the SourceForge version with about 6 months delay.

=== Packages ===
*{{Fedora}} Packages(1): Fedora Core includes the ipw2200-drivers in FC3 (with updates) and FC4. You still need to grab the firmware from http://rpm.livna.org/
*{{Fedora}} Packages(2): http://www.atrpms.net/name/ipw2200/
*{{Mandriva}}: The ipw2200 driver modules are included in the stock kernel package; the firmware is included in the commercial distribution or available from http://plf.zarb.org/.
*{{Gentoo}}: The driver is in the portage tree: emerge net-wireless/ipw2200 and net-wireless/ipw2200-firmware
*{{Debian}} Packages: http://packages.debian.org/ipw2200-source

=== Status ===
In development, usable, WEP 128bit encryption works, WPA and WPA2 work with drivers >= 1.0.2 using [[wpa_supplicant]], monitor/rfmon is supported as with version >= 1.0.6. Generally works well, but some users experience problems (especially with firmware restarts and with WPA functionality using [[wpa_supplicant]]). Passing the <tt>hwcrypto=0</tt> module parameter improves reliability for many users.

The [[ipw2200]] driver up to version 1.0.6 (in combination with some newer kernels) had a problem getting DHCP leases (it turned out to be a bug in the broadcasting code). Version 1.0.7 seems to have fixed this.

Older [[ipw2200]] driver versions shipped by many distributions have been reported to freeze a T43 after several minutes of intensive communication. Installing version 1.1.2 of the driver solved the problem.

Latest stable versions:
* ipw2200 driver: 1.2.0
* firmware: 3.0
* ieee80211 stack: 1.2.15

Latest development versions:
* ipw2200 driver: 1.1.4
* firmware: 3.0
* ieee80211 stack: 1.2.15

Mainline kernels contain older (but mostly functional) versions of ipw2200 and ieee80211, and still require the addition of the [http://ipw2200.sourceforge.net/firmware.php firmware] files. To get the latest versions you need to separately install the [http://ipw2200.sourceforge.net/downloads.php ipw2200] module and [http://ieee80211.sourceforge.net/downloads.php ieee80211] stack.

==Installation==
=== Installation from sourcecode ===
Download the latest [http://ieee80211.sourceforge.net/downloads.php ieee80211] stack and install it:
:{{cmdroot|tar xzvf ieee80211-1.2.15.tgz}}
:{{cmdroot|cd ieee80211-1.2.15}}
:{{cmdroot|make}}
:{{cmdroot|make install}}

Download the latest [http://ipw2200.sourceforge.net/downloads.php ipw2200] module and install it:
:{{cmdroot|tar xzvf ipw2200-1.2.0.tgz}}
:{{cmdroot|cd ipw2200-1.2.0}}
:{{cmdroot|make}}
:{{cmdroot|make install}}

Download the matching [http://ipw2200.sourceforge.net/firmware.php firmware] and install it:
:{{cmdroot|tar xzvf ipw2200-fw-3.0.tgz -C /lib/firmware}}

=== Installation on Debian ===
Install ieee80211-source:
:{{cmdroot|apt-get install ieee80211-source}}
:{{cmdroot|module-assistant -t build ieee80211-source}}

Install ipw2200-source:
:{{cmdroot|apt-get install ipw2200-source}}
:{{cmdroot|module-assistant -t build ipw2200-source}}

There is a bug in the {{Debian}} package (last checked: Dec 30th 2005) that prevents from linking to <tt>ieee80211</tt> modules using module-assistant. In case it is not fixed in your version, fall back to the regular source installation procedure described above.

The firmware is not distributed with debian due to licensing reasons, download the matching [http://ipw2200.sourceforge.net/firmware.php firmware] and install it:

:{{cmdroot|tar xzvf ipw2200-fw-2.4.tgz -C /usr/lib/hotplug/firmware}}

see /etc/hotplug/firmware.agent for details on configured firmware locations

In etch the firmware can also be placed in /lib/firmware. Make sure that your firmware files are not in a subdirectory (dmesg will give you warnings after any modprobe when firmware can't be loaded)

=== Installation on Fedora Core ===
Installation on Fedora Core 5 works out of the box provided you install the ipw2200-firmware package. However, certain parts of the install process may not set up the wireless networking in a friendly manner using GNOME system tray icons and other tools. Bill Moss has written some excellent HowTo articles, including using VPNC to connect to a remote Cisco IPSec network.

* [http://www.ces.clemson.edu/linux/fc2-ipw2200.shtml Fedora Core 5 and the IPW2200 Wireless Driver]
* [http://www.ces.clemson.edu/linux/nm.shtml Fedora Core 5 NetworkManager, NetworkManager-vpnc and Wireless Driver IPW2200]

===Testing the driver ===
:{{cmdroot|modprobe ipw2200}}
:{{cmdroot|iwconfig}}

{{cmdroot|dmesg}} output might look similar to this:
ieee80211: 802.11 data/management/control stack, 1.1.6
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.8
ipw2200: Copyright(c) 2003-2005 Intel Corporation
ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection

NB: To make the wifi LED work on the thinkpad, pass the option {{bootparm|led|1}} to the kernel while loading the module. eg. {{cmdroot|1=modprobe ipw2200 led=1}}. This can also be accomplished by adding that option to the file where your distribution looks for modprobe options so that it becomes automatic.

In debian this can be done by putting a file named after the module in /etc/modutils with the options in it

here we might run a cmd like this

:{{cmdroot|1=echo options ipw2200 led=1 > /etc/modutils/ipw2200 }}

then we must run update-modules to remake /etc/module.conf

:{{cmdroot|update-modules}}

== WPA support ==

Use [[wpa_supplicant]] with the <tt>-Dwext</tt> argument (not <tt>-Dipw</tt>), and pass the <tt>hwcrypto=0</tt> argument to the <tt>ipw2200</tt> module.

There are some very detailed instructions with working sample configurations on the following link:
[http://www.bughost.org/ipw/wpa_howto.txt ipw2200 WPA instruction]

== Power Management ==
To enable power management, issue:
:{{cmdroot|iwpriv wlan0 set_power 7}}
where <tt>wlan0</tt> is the name of your interface. This will reduce idle power consumption by several Watts compared to no power management.

*To disable the radio (and further reduce power consumption) when the card is not in use, issue:
:{{cmdroot|echo 1 > /sys/bus/pci/drivers/ipw2200/*/rf_kill}}
*To enable the radio, issue:
:{{cmdroot|echo 0 > /sys/bus/pci/drivers/ipw2200/*/rf_kill}}
*To make the radio off by default after boot, add
options ipw2200 disable=1
to your {{path|/etc/modprobe.conf}} or equivalent (on kubuntu 6.10 {{path|/etc/modprobe.d/options}}).

See {{path|README.ipw2200}} in the <tt>ipw2200</tt> package for details and other options.

== Changing the enabled channels ==
Permitted WiFi channels vary with geography due to regulation. The EEPROM in this chip contains a country code (programmed by the hardware manufacturer), and the driver converts this to a channel list and enforces it.

If you carry your laptop to a different regulatory region, you may need to change the list of permitted channels according to local regulations. There are two ways to accomplish this:

===Patching the ipw2200 driver===
You can alter the ipw2200 driver sourcecode to hard-code the country code instead of reading it from EEPROM. For example, this will allow all 14 channels (perfect for those special occasions in international water):
<pre>
--- ipw2200.c.orig
+++ ipw2200.c
@@ -11344,7 +11344,7 @@ static int ipw_up(struct ipw_priv *priv)
memcpy(priv->net_dev->dev_addr, priv->mac_addr, ETH_ALEN);

for (j = 0; j < ARRAY_SIZE(ipw_geos); j++) {
- if (!memcmp(&priv->eeprom[EEPROM_COUNTRY_CODE],
+ if (!memcmp("ZZR",
ipw_geos[j].name, 3))
break;
}
</pre>

For the list of codes and their meaning, see the "<tt>ipw_geos</tt>" table in the [http://lxr.free-electrons.com/source/drivers/net/wireless/ipw2200.c#10382 ipw2200.c sourcecode].

===Patching the EEPROM===

Alternatively, you can change the country code in the EEPROM once and for all, and then use the standard ipw2200 driver.

See this guide:
* [http://saftware.de/#ipw2200 Patching the EEPROM].

Instead of the <tt>hd</tt> program mentioned there, you can use the more common <tt>od</tt> program:
echo -n ZZD | od -t x1
0000000 5a 5a 44
0000003

{{WARN|If this procedure goes wrong, you may ruin your wireless card.}}

== Additional Comments ==
Your kernel may include an old version of the ipw2200 driver. It is recommended to use the latest version.

Make sure you also install the firmware version needed by the driver version you use. You can find the firmware [http://ipw2200.sourceforge.net/firmware.php here]. To install it, decompress the <tt>.tgz</tt> file into {{path|/usr/lib/hotplug/firmware}}.

The driver doesn't appear to support the MII interface, so any tools like automatic network configuration managers (i.e. whereami) that rely on mii-tool do not work.

[[Category:Drivers]]

Fglrx

2006-12-23T22:44:53Z

Gsmenden: /* Suspending */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: http://ati.amd.com/support/drivers/linux/linux-radeon.html

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}} packages: http://www.stanchina.net/~flavio/debian-official/fglrx-driver.html
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide Edgy Eft Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.32.5 (13th December 2006).
Major changes:
* 8.32.5: support for X1650, X.Org 7.2 RC2 support, bugfixes. Suspend-to-ram is broken with specific cards, *no* 2.6.19 support (see [[Problems_with_fglrx#fglrx_8.32.5|fglrx patches section]]).

* 8.31.5: no new features, only bugfixes. Of note, for some users, this version breaks suspend-to-ram.
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!
However the situation seems to be changing today. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps without any single crash so far.

=== 3D acceleration ===

According to [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] you need these options:

Section "Module"
...
Load "GLcore"
Load "glx"
Load "dri"
...
EndSection

# Of course you need to activate the driver
Section "Device"
...
Driver "fglrx"
EndSection

Don't forget to load the module <tt>fglrx</tt> (<tt>modprobe fglrx</tt>). Under Debian the module can be placed in <tt>/etc/modules</tt>.

With current fglrx drivers (as of 8.29.6) you must disable composite to get 3D DRI acceleration.

If you are unsure whether you have DRI running, issue <tt>glxinfo | grep -i direct</tt> after disabling composite. Note, this

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.

You may be able to preserve VideoOverlay acceleration if you explicitly remove the OpenGLOverlay using:

Option "VideoOverlay" "True" and Option "OpenGLOverlay" "False". See [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] for detail.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

=== Suspending with fglrx ===

On a ThinkPad T42 with Kernel 2.6.19 with Software Suspend 2, the following addition to <tt>/etc/hibernate/suspend2.conf</tt> is required:

# For fglrx
ProcSetting extra_pages_allowance 20000

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}, {{Z61p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Fglrx

2006-12-23T22:42:17Z

Gsmenden: Please keep the official entry encylcopedic in nature -- they should be "proven" and not signed entries. Random user experience should go in the talk section.

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: http://ati.amd.com/support/drivers/linux/linux-radeon.html

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}} packages: http://www.stanchina.net/~flavio/debian-official/fglrx-driver.html
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide Edgy Eft Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.32.5 (13th December 2006).
Major changes:
* 8.32.5: support for X1650, X.Org 7.2 RC2 support, bugfixes. Suspend-to-ram is broken with specific cards, *no* 2.6.19 support (see [[Problems_with_fglrx#fglrx_8.32.5|fglrx patches section]]).

* 8.31.5: no new features, only bugfixes. Of note, for some users, this version breaks suspend-to-ram.
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!
However the situation seems to be changing today. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps without any single crash so far.

=== 3D acceleration ===

According to [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] you need these options:

Section "Module"
...
Load "GLcore"
Load "glx"
Load "dri"
...
EndSection

# Of course you need to activate the driver
Section "Device"
...
Driver "fglrx"
EndSection

Don't forget to load the module <tt>fglrx</tt> (<tt>modprobe fglrx</tt>). Under Debian the module can be placed in <tt>/etc/modules</tt>.

With current fglrx drivers (as of 8.29.6) you must disable composite to get 3D DRI acceleration.

If you are unsure whether you have DRI running, issue <tt>glxinfo | grep -i direct</tt> after disabling composite. Note, this

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.

You may be able to preserve VideoOverlay acceleration if you explicitly remove the OpenGLOverlay using:

Option "VideoOverlay" "True" and Option "OpenGLOverlay" "False". See [http://xoomer.alice.it/flavio.stanchina/debian/fglrx-installer.html#configure Flavio's page] for detail.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

=== Suspending ===

Suspending works for me (Helios42) on ThinkPad T42 with Kernel 2.6.19 and Software Suspend 2 and hibernate after adding the following option to <tt>/etc/hibernate/suspend2.conf</tt>

# For fglrx
ProcSetting extra_pages_allowance 20000

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}, {{Z61p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Fglrx

2006-12-15T19:11:52Z

Gsmenden: /* Status */ - from forums, it seems nobody else can get suspend to work either...

Fglrx

2006-12-14T03:32:52Z

Gsmenden: Frustrating... new driver from ATI doesn't do much.

Fglrx

2006-12-13T23:32:27Z

Gsmenden: /* Status */

Template:Industry News

2006-12-13T23:31:18Z

Gsmenden: New fglrx

13.12.2006: New [[fglrx]] driver version 8.32.5 released.

15.11.2006: New [[fglrx]] driver version 8.31.5 released

14.11.2006 New ThinkPad X60 Tablet [http://www.tabletpcreview.com/default.asp?newsID=632&review=ThinkPad+X60+Tablet+PC reviewed], including SXGA+ model.

03.11.2006: New [[fglrx]] driver version 8.30.3 released

20.09.2006: New [[fglrx]] driver version 8.29.6 released

18.08.2006: New [[fglrx]] driver version 8.28.8 released

04.08.2005: According to [http://www.desktoplinux.com/news/NS7778908329.html desktoplinux.com], Lenovo will sell Thinkpads with SuSE Enterprise Desktop 10 preloaded.

28.07.2006: New [[fglrx]] driver version 8.27.10 released including support for XOrg 7.1

27.06.2006: New [[fglrx]] driver version 8.26.18 released

05.06.2006: According to CNET [http://news.com.com/2100-1003_3-6080115.html?part=rss&tag=6080115&subj=news], Lenovo is now denying dropping official Linux support.

04.06.2006: Sad news! According to CRN [http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=188701277], Lenovo drops official Linux support for its PCs, including ThinkPads.

24.05.2006 New [[fglrx]] driver version 8.25.18 released

15.04.2006 Several news ([http://www.notebookreview.com/default.asp?newsID=2843], [http://www.graphiland.fr/produc_t/produc1b.asp?Code=X60&Ed=]) appeared that the next Lenovo models will be the {{R60}}, {{Z61m}}, {{Z61t}} and a new Tablet PC {{X60t}}.

Fglrx

2006-11-27T02:54:36Z

Gsmenden: /* Status */

How to setup Bluetooth

2006-09-24T15:52:28Z

Gsmenden: /* Mount a phone as a directory */

How to setup Bluetooth

2006-09-24T15:51:11Z

Gsmenden: Moved already to new section.

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#efefef; align:right;">
This HOWTO tells you how to install and configure Bluetooth on your Linux driven ThinkPad and how to make the most common Bluetooth applications (like connecting your mobile phone etc.) work.
</div>
|}

==Enabling Bluetooth==
If Bluetooth is disabled and you have [[Ibm-acpi]] running you could enable/disable bluetooth by entering:
:{{cmdroot|echo enable > /proc/acpi/ibm/bluetooth}}
or
:{{cmdroot|echo disable > /proc/acpi/ibm/bluetooth}}

==Configuring the kernel==
Since the Bluetooth card is connected to the USB subsystem, you will need to enable USB support in your kernel:
:{{kernelconf|CONFIG_USB|<M>|Support for Host-side USB|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_DEVICEFS|[*]|USB device file system|USB support|Device Drivers||}}

Choose an appropriate USB host driver, one of:
:{{kernelconf|CONFIG_USB_EHCI_HCD|<M>|EHCI HCD (USB 2.0) support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_UHCI|<M>|UHCI HCD support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_OHCI|<M>|OHCI HCD support|USB support|Device Drivers||}}

Enable Bluetooth subsystem and drivers:
:{{kernelconf|CONFIG_BT|<*>|Bluetooth subsystem support|Networking|||}}
:{{kernelconf|CONFIG_BT_L2CAP|<*>|L2CAP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_SCO|<*>|SCO links support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM|<*>|RFCOMM protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM_TTY|[*]|RFCOMM TTY support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_BNEP|<*>|BNEP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HID|<*>|HID protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HCIUSB|<M>|HCI USB driver|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}
:{{kernelconf|CONFIG_BT_HCIUSB_SCO|[*]|SCO (voice) support|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}

Make sure that the according modules are loaded:
:{{cmdroot|modprobe uhci_hcd ; modprobe ehci_hcd ; modprobe hci_usb}}

==Serial connection over Bluetooth==
One common application is to connect your mobile phone and use it as a modem to connect to the internet via GPRS or 3G (UMTS). A lot of phones do this through using AT-commands on a serial over Bluetooth connection.

By configuring {{path|/etc/bluetooth/rfcomm.conf}} correctly, you'll get a device {{path|/dev/rfcomm0}}.

Eventually one could use the command:
:{{cmdroot|rfcomm bind 0 00:15:A0:7A:90:F2 3}}

The hardware address should be replaced with that of your phone. If you don't know the hardware address of your phone yet, you can get it by running:
:{{cmdroot|hcitool scan}}

The last parameter ('3') is the channel to use. I spent quite some time fighting before I found out of that one; I didn't find it documented anywhere, but by running
:{{cmdroot|sdptool records 00:15:A0:7A:90:F2}}
I found channel 3 to be the right one for my phone. You will have to experiment to find the right one for your phone setup; for T-Mobile GSM/GPRS carrier in USA this is channel 1.
{{NOTE|By experimenting, the bluetooth stack on the cellphone may crash. Reboot it if that happens.}}

Alternativly one could use the following to find the right channel:
:{{cmdroot|sdptool search DUN}}

Inquiring ...
Searching for DUN on 00:11:22:33:44:55 ...
Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4

Now {{path|/dev/rfcomm0}} exists.

At this point you can use an automatic dialing utility such as wvdial, editing the config file to point to the modem at {{path|/dev/rfcomm0}}, and everything should work just like a land line!

{{NOTE|If you experience strange disconnects while using wvdial, disable "Carrier Check" in your wvdial configuration.}}

You may directly access the modem (i.e. by using minicom:)
:{{cmduser|minicom -s}}
set the serial device to be {{path|/dev/rfcomm0}}, choose 'exit' and then the AT-commands can be typed in.
With my operator (Telenor, Norway) it seemed simple enough, I just entered
:ATDT *99#
and lots of cryptic letters started dancing across the screen, indicating a ppp session startup.

To configure pppd create {{path|/etc/ppp/peers/nokia}} with particularly those lines:
/dev/rfcomm0
connect '/usr/sbin/chat -v -f /etc/ppp/chat-nokia'
debug
10.0.1.3
crtscts
noipdefault
ipcp-accept-local
defaultroute
novj
nobsdcomp
novjccomp
nopcomp
noaccomp
usepeerdns

Furthermore, you need a simple chat script. Create {{path|/etc/ppp/chat-nokia}}:
'TIMEOUT' '5'
'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO ANSWER'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'' 'ATZ'
'OK' 'ATDT*99#'
'~--' ''

Here's a script that works for Cingular's network:
TIMEOUT 35
ECHO ON
ABORT '\nBUSY\r'
ABORT '\nERROR\r'
ABORT '\nNO ANSWER\r'
ABORT '\nNO CARRIER\r'
ABORT '\nNO DIALTONE\r'
ABORT '\nRINGING\r\n\r\nRINGING\r'
'' \rAT
OK 'AT+CGDCONT=1,"IP","WAP.CINGULAR"'
OK ATD*99***1#
CONNECT ""

See more [https://help.ubuntu.com/community/BluetoothDialup#preview here]

Run pppd with:
:{{cmduser|pppd call nokia}}
This should establish the internet connection.

{{NOTE|Different network operators may require different call strings. For many carriers (including T-Mobile USA) "*99#" works without additional parameters.}}

For editing phonebook / ringtones / etc., the gammu utils (http://www.gamu.net) has been reported to work well, but this appears to be primarily for Nokia phones.

==File Transfer==
File transfers are accomplished through OBEX transfer, which I believe is basically an FTP over bluetooth connection. Once you have bonded with your phone (yes, I know you love your sexy RAZR, but here I mean paired it with your laptop via bluetooth), you can easily use "obexftp" to transfer files. As an example,

:obexftp -b 00:01:02:03:04:05 -l

will list the root directory of the phone with bluetooth address 00:01:02:03:04:05. Refer to the man page for more of the unique commands. What a wonderful interface! Unfortunately there doesn't seem to be a way to get a standard 'ftp' session using familiar commands (e.g. 'mget').

For a more user-friendly experience, you can use the kde tools, just launch
:kbtobexclient

for a file browser. In the Location: option put
:obex://[00:01:02:03:04:05]

to list the files. Note that the brackets *are* necessary. From there, you can list directories easily and batch download files.

==Mount a phone as a directory==
You can also mount a phone as a standard directory using obexfs and the FUSE (file system in userspace) utilities.

{{NOTE|The ibm bluetooth card can works like an usb-dongle. You don't need the bcm203x module}}

Configure your kernel as outlined above. Include the following packages:

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|CONFIG_USB|<*>|Support for Host-side USB|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_DEVICEFS|[*]|USB device file system|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_EHCI_HCD|<*>|EHCI HCD (USB 2.0) support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_UHCI|<*>|UHCI HCD support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_OHCI|<*>|OHCI HCD support|USB support|Device Drivers||}}

:{{kernelconf|CONFIG_BT|<M>|Bluetooth subsystem support|Networking|||}}
:{{kernelconf|CONFIG_BT_L2CAP|<M>|L2CAP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM|<M>|RFCOMM protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM_TTY|[*]|RFCOMM TTY support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HCIUSB|<M>|HCI USB driver|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}

:{{cmdroot|make && make modules_install}}

* Install the requiered packages
To mount the filesystem we need the fuse program. FuseFS is also implemented in the kernel, but for some reason it only works with 2.6.18. If you run 2.6.17 or earlier, please download it and build the module according to your distro.

* Emerge or apt-get bluez-utils and obexfs. This should pull other required packages (bluez-libs, openobex, obexftp, sys-fs/fuse) as dependencies.

:{{cmdroot|emerge bluez-utils obexfs}}

* Modify /etc/bluetooth/hcid.conf if you haven't already. It can be done as above, or use the following:
options {
autoinit yes"
security user
pairing multi
pin_helper /usr/bin/bluepin
}
device {
name testname
class 0x3e0100
iscan enable
pscan enable
lm accept
lp rswitch,hold,sniff,park
}

* load the modules:
:{{cmdroot|modprobe fuse}}
:{{cmdroot|modprobe bluetooth}}
:{{cmdroot|modprobe ehci-hcd}}
:{{cmdroot|modprobe uhci-hcd}}
:{{cmdroot|modprobe hci_usb}}
:{{cmdroot|modprobe l2cap}}
:{{cmdroot|modprobe rfcomm}}

* activate your bluetooth (show howto ibm-acpi for more details) by using fn+f5 or:
:{{cmdroot|echo enable >/proc/acpi/ibm/bluetooth}}

* start the bluetooth device:
:{{cmdroot|/etc/init.d/bluetooth start}}

* turn on bluetooth of your mobile phone (visible mode) and get the mac-address of your phone using hcitool.
:{{cmdroot|hcitool scan}}

=== For non symbian mobile phones ===

* mount your phone - don't forget to umount it when you're finished
:{{cmdroot|mkdir /mnt/phone}}
:{{cmdroot|mount -t fuse "obexfs#-b00:16:20:32:25:3C -B6" /mnt/phone}}
''use your mac-address instead of my 00:16:20:32:25:3C and don't forget the -b option in front of the mac''

Works perfectly with IBM T43p, X41, sony ericsson k750i, nokia 6280, samsung z400, sony ericsson k700i.

=== Mounting Symbian Phones ===

* You need network file system support in your kernel

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|NFS_FS|<M>|NFS file system support|Network File Systems|File Systems|||}}
:{{kernelconf|NFS_V3|<M>|Provide NFSv3 client support|Network File Systems|File Systems|||}}

:{{kernelconf|NFSD|<M>|NFS server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_V3|<*>|Provide NFSv3 server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_TCP|<*>|Provide NFS server over TCP support|Network File Systems|File Systems|||}}

:{{cmdroot|make && make modules_install}}

* Install required programs

:{{cmdroot|emerge -av p3nfs}}

* Modify your /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:0F:DE:8C:E6:94;
channel 13;
comment "symbian connection"
}

* restart your bluetooth device, load kernel modules and start portmap (required for p3nfs)

:{{cmdroot|/etc/init.d/bluetooth restart}}
:{{cmdroot|modprobe nfs}}
:{{cmdroot|modprobe nfsd}}

:{{cmdroot|/etc/init.d/portmap start}}

* get the application for your mobile phone [http://www.koeniglich.de/p3nfs.html here]

* start bt at your mobile phone, send application to mobilephone, install and launch the nfsapp with bluetooth at channel 13 (default)

:{{cmdroot|obexftp -b 00:0F:DE:8C:E6:94 -p /home/tava/ablage/nfsapp*}}

* mount your mobile phone:

:{{cmdroot|p3nfsd -UIQ -tty /dev/rfcomm0 -dir /mnt/bluetooth}} (-UIQ is only for UIQ-Phones, type p3nfsd --help and get informations for your phone)

* if doesn't work, make sure rfcomm0 is clean

:{{cmdroot|rfcomm}}

----

===Building from source===
Get the source packages from [http://www.bluez.org www.bluez.org].

Build each of them with the usual steps:
:{{cmduser|./configure && make}}
:{{cmdroot|make install}}

===Gentoo ebuilds===
Under {{Gentoo}}, install the following ebuilds:
*net-wireless/bluez-bluefw
*net-wireless/bluez-firmware
*net-wireless/bluez-hcidump
*net-wireless/bluez-hciemu
*net-wireless/bluez-libs
*net-wireless/bluez-utils

{{NOTE|net-wireless/bluez-kernel is not needed, since the current version is included in your kernel.}}

===Other distributions===
You will find packages for {{Debian}}, {{Redhat}} and {{Slackware}} on the [http://www.bluez.org/packages.html packages page] of the BlueZ project.

==Troubleshooting==
If you cant get hci0 up with a /etc/init.d/bluetooth restart (or similar) then you might want to try a
:{{cmdroot|hciconfig hci0 down && hciconfig hci0 up}}
(solved the problem on a X60s (debian/testing))

==External Links==
*http://gagravarr.org/series-60/
*http://www.polycon.fi/~laa/biblo/linux_gprs.html
*[http://www.gentoo.org/doc/en/bluetooth-guide.xml Guide on how to set up Bluetooth in Gentoo]
*[http://www.linux.ie/articles/bluetoothheadset.php www.linux.ie:Linux and Bluetooth Headset howto (AKA: Fedora, BTSCO, Bluez, Jabra and Skype)]

[[Category:A30]] [[Category:A30p]] [[Category:A31]] [[Category:A31p]] [[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:T60]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:X60]] [[Category:X60s]] [[Category:Z60m]] [[Category:Z60t]]

How to setup Bluetooth

2006-09-24T15:50:02Z

Gsmenden: /* File Transfer */ - moved to more appropriate section

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#efefef; align:right;">
This HOWTO tells you how to install and configure Bluetooth on your Linux driven ThinkPad and how to make the most common Bluetooth applications (like connecting your mobile phone etc.) work.
</div>
|}

== Mount a mobile phone with bluetooth (symbian and non symbian phones) ==

{{NOTE|You don't need any other package except the ones described here.}}

{{NOTE|The ibm bluetooth card can works like an usb-dongle. You don't need the bcm203x module}}

For {{Gentoo}} do the following:
* First of all, we must config your kernel

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|CONFIG_USB|<*>|Support for Host-side USB|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_DEVICEFS|[*]|USB device file system|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_EHCI_HCD|<*>|EHCI HCD (USB 2.0) support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_UHCI|<*>|UHCI HCD support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_OHCI|<*>|OHCI HCD support|USB support|Device Drivers||}}

:{{kernelconf|CONFIG_BT|<M>|Bluetooth subsystem support|Networking|||}}
:{{kernelconf|CONFIG_BT_L2CAP|<M>|L2CAP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM|<M>|RFCOMM protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM_TTY|[*]|RFCOMM TTY support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HCIUSB|<M>|HCI USB driver|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}

:{{cmdroot|make && make modules_install}}

* Install the requiered packages
For exchange files we need the fuse filesystem. FuseFS is also implemented in the kernel, but it does not work for me.

* Emerge bluez-utils and obexfs. This should pull other required packages (bluez-libs, openobex, obexftp, sys-fs/fuse) as dependencies.

:{{cmdroot|emerge bluez-utils obexfs}}

* Modify /etc/bluetooth/hcid.conf
options {
autoinit yes"
security user
pairing multi
pin_helper /usr/bin/bluepin
}
device {
name testname
class 0x3e0100
iscan enable
pscan enable
lm accept
lp rswitch,hold,sniff,park
}

* load the modules:
:{{cmdroot|modprobe fuse}}
:{{cmdroot|modprobe bluetooth}}
:{{cmdroot|modprobe ehci-hcd}}
:{{cmdroot|modprobe uhci-hcd}}
:{{cmdroot|modprobe hci_usb}}
:{{cmdroot|modprobe l2cap}}
:{{cmdroot|modprobe rfcomm}}

* activate your bluetooth (show howto ibm-acpi for more details)
:{{cmdroot|echo enable >/proc/acpi/ibm/bluetooth}}

* start the bluetooth device:
:{{cmdroot|/etc/init.d/bluetooth start}}

* turn on bluetooth of your mobile phone (visible mode)
* get the mac-address of your phone
:{{cmdroot|hcitool scan}}

=== For non symbian mobile phones ===

* mount your phone - don't forget to umount it when you're finished
:{{cmdroot|mkdir /mnt/phone}}
:{{cmdroot|mount -t fuse "obexfs#-b00:16:20:32:25:3C -B6" /mnt/phone}}
''use your mac-address instead of my 00:16:20:32:25:3C and don't forget the -b option in front of the mac''

finished, now you can improve this howto ;-)

Tested with ibm x41, sony ericsson k750i, nokia 6280, samsung z400, sony ericsson k700i

=== For symbian phones ===

* You need network file system support in your kernel

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|NFS_FS|<M>|NFS file system support|Network File Systems|File Systems|||}}
:{{kernelconf|NFS_V3|<M>|Provide NFSv3 client support|Network File Systems|File Systems|||}}

:{{kernelconf|NFSD|<M>|NFS server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_V3|<*>|Provide NFSv3 server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_TCP|<*>|Provide NFS server over TCP support|Network File Systems|File Systems|||}}

:{{cmdroot|make && make modules_install}}

* Install required programs

:{{cmdroot|emerge -av p3nfs}}

* Modify your /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:0F:DE:8C:E6:94;
channel 13;
comment "symbian connection"
}

* restart your bluetooth device, load kernel modules and start portmap (required for p3nfs)

:{{cmdroot|/etc/init.d/bluetooth restart}}
:{{cmdroot|modprobe nfs}}
:{{cmdroot|modprobe nfsd}}

:{{cmdroot|/etc/init.d/portmap start}}

* get the application for your mobile phone [http://www.koeniglich.de/p3nfs.html here]

* start bt at your mobile phone, send application to mobilephone, install and launch the nfsapp with bluetooth at channel 13 (default)

:{{cmdroot|obexftp -b 00:0F:DE:8C:E6:94 -p /home/tava/ablage/nfsapp*}}

* mount your mobile phone:

:{{cmdroot|p3nfsd -UIQ -tty /dev/rfcomm0 -dir /mnt/bluetooth}} (-UIQ is only for UIQ-Phones, type p3nfsd --help and get informations for your phone)

* if doesn't work, make sure rfcomm0 is clean

:{{cmdroot|rfcomm}}

----

===Building from source===
Get the source packages from [http://www.bluez.org www.bluez.org].

Build each of them with the usual steps:
:{{cmduser|./configure && make}}
:{{cmdroot|make install}}

===Gentoo ebuilds===
Under {{Gentoo}}, install the following ebuilds:
*net-wireless/bluez-bluefw
*net-wireless/bluez-firmware
*net-wireless/bluez-hcidump
*net-wireless/bluez-hciemu
*net-wireless/bluez-libs
*net-wireless/bluez-utils

{{NOTE|net-wireless/bluez-kernel is not needed, since the current version is included in your kernel.}}

===Other distributions===
You will find packages for {{Debian}}, {{Redhat}} and {{Slackware}} on the [http://www.bluez.org/packages.html packages page] of the BlueZ project.

==Enabling Bluetooth==
If Bluetooth is disabled and you have [[Ibm-acpi]] running you could enable/disable bluetooth by entering:
:{{cmdroot|echo enable > /proc/acpi/ibm/bluetooth}}
or
:{{cmdroot|echo disable > /proc/acpi/ibm/bluetooth}}

==Configuring the kernel==
Since the Bluetooth card is connected to the USB subsystem, you will need to enable USB support in your kernel:
:{{kernelconf|CONFIG_USB|<M>|Support for Host-side USB|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_DEVICEFS|[*]|USB device file system|USB support|Device Drivers||}}

Choose an appropriate USB host driver, one of:
:{{kernelconf|CONFIG_USB_EHCI_HCD|<M>|EHCI HCD (USB 2.0) support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_UHCI|<M>|UHCI HCD support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_OHCI|<M>|OHCI HCD support|USB support|Device Drivers||}}

Enable Bluetooth subsystem and drivers:
:{{kernelconf|CONFIG_BT|<*>|Bluetooth subsystem support|Networking|||}}
:{{kernelconf|CONFIG_BT_L2CAP|<*>|L2CAP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_SCO|<*>|SCO links support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM|<*>|RFCOMM protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM_TTY|[*]|RFCOMM TTY support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_BNEP|<*>|BNEP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HID|<*>|HID protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HCIUSB|<M>|HCI USB driver|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}
:{{kernelconf|CONFIG_BT_HCIUSB_SCO|[*]|SCO (voice) support|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}

Make sure that the according modules are loaded:
:{{cmdroot|modprobe uhci_hcd ; modprobe ehci_hcd ; modprobe hci_usb}}

==Serial connection over Bluetooth==
One common application is to connect your mobile phone and use it as a modem to connect to the internet via GPRS or 3G (UMTS). A lot of phones do this through using AT-commands on a serial over Bluetooth connection.

By configuring {{path|/etc/bluetooth/rfcomm.conf}} correctly, you'll get a device {{path|/dev/rfcomm0}}.

Eventually one could use the command:
:{{cmdroot|rfcomm bind 0 00:15:A0:7A:90:F2 3}}

The hardware address should be replaced with that of your phone. If you don't know the hardware address of your phone yet, you can get it by running:
:{{cmdroot|hcitool scan}}

The last parameter ('3') is the channel to use. I spent quite some time fighting before I found out of that one; I didn't find it documented anywhere, but by running
:{{cmdroot|sdptool records 00:15:A0:7A:90:F2}}
I found channel 3 to be the right one for my phone. You will have to experiment to find the right one for your phone setup; for T-Mobile GSM/GPRS carrier in USA this is channel 1.
{{NOTE|By experimenting, the bluetooth stack on the cellphone may crash. Reboot it if that happens.}}

Alternativly one could use the following to find the right channel:
:{{cmdroot|sdptool search DUN}}

Inquiring ...
Searching for DUN on 00:11:22:33:44:55 ...
Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4

Now {{path|/dev/rfcomm0}} exists.

At this point you can use an automatic dialing utility such as wvdial, editing the config file to point to the modem at {{path|/dev/rfcomm0}}, and everything should work just like a land line!

{{NOTE|If you experience strange disconnects while using wvdial, disable "Carrier Check" in your wvdial configuration.}}

You may directly access the modem (i.e. by using minicom:)
:{{cmduser|minicom -s}}
set the serial device to be {{path|/dev/rfcomm0}}, choose 'exit' and then the AT-commands can be typed in.
With my operator (Telenor, Norway) it seemed simple enough, I just entered
:ATDT *99#
and lots of cryptic letters started dancing across the screen, indicating a ppp session startup.

To configure pppd create {{path|/etc/ppp/peers/nokia}} with particularly those lines:
/dev/rfcomm0
connect '/usr/sbin/chat -v -f /etc/ppp/chat-nokia'
debug
10.0.1.3
crtscts
noipdefault
ipcp-accept-local
defaultroute
novj
nobsdcomp
novjccomp
nopcomp
noaccomp
usepeerdns

Furthermore, you need a simple chat script. Create {{path|/etc/ppp/chat-nokia}}:
'TIMEOUT' '5'
'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO ANSWER'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'' 'ATZ'
'OK' 'ATDT*99#'
'~--' ''

Here's a script that works for Cingular's network:
TIMEOUT 35
ECHO ON
ABORT '\nBUSY\r'
ABORT '\nERROR\r'
ABORT '\nNO ANSWER\r'
ABORT '\nNO CARRIER\r'
ABORT '\nNO DIALTONE\r'
ABORT '\nRINGING\r\n\r\nRINGING\r'
'' \rAT
OK 'AT+CGDCONT=1,"IP","WAP.CINGULAR"'
OK ATD*99***1#
CONNECT ""

See more [https://help.ubuntu.com/community/BluetoothDialup#preview here]

Run pppd with:
:{{cmduser|pppd call nokia}}
This should establish the internet connection.

{{NOTE|Different network operators may require different call strings. For many carriers (including T-Mobile USA) "*99#" works without additional parameters.}}

For editing phonebook / ringtones / etc., the gammu utils (http://www.gamu.net) has been reported to work well, but this appears to be primarily for Nokia phones.

==File Transfer==
File transfers are accomplished through OBEX transfer, which I believe is basically an FTP over bluetooth connection. Once you have bonded with your phone (yes, I know you love your sexy RAZR, but here I mean paired it with your laptop via bluetooth), you can easily use "obexftp" to transfer files. As an example,

:obexftp -b 00:01:02:03:04:05 -l

will list the root directory of the phone with bluetooth address 00:01:02:03:04:05. Refer to the man page for more of the unique commands. What a wonderful interface! Unfortunately there doesn't seem to be a way to get a standard 'ftp' session using familiar commands (e.g. 'mget').

For a more user-friendly experience, you can use the kde tools, just launch
:kbtobexclient

for a file browser. In the Location: option put
:obex://[00:01:02:03:04:05]

to list the files. Note that the brackets *are* necessary. From there, you can list directories easily and batch download files.

==Mount a phone as a directory==
You can also mount a phone as a standard directory using obexfs and the FUSE (file system in userspace) utilities.

{{NOTE|The ibm bluetooth card can works like an usb-dongle. You don't need the bcm203x module}}

Configure your kernel as outlined above. Include the following packages:

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|CONFIG_USB|<*>|Support for Host-side USB|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_DEVICEFS|[*]|USB device file system|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_EHCI_HCD|<*>|EHCI HCD (USB 2.0) support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_UHCI|<*>|UHCI HCD support|USB support|Device Drivers||}}
:{{kernelconf|CONFIG_USB_OHCI|<*>|OHCI HCD support|USB support|Device Drivers||}}

:{{kernelconf|CONFIG_BT|<M>|Bluetooth subsystem support|Networking|||}}
:{{kernelconf|CONFIG_BT_L2CAP|<M>|L2CAP protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM|<M>|RFCOMM protocol support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_RFCOMM_TTY|[*]|RFCOMM TTY support|Bluetooth subsystem support|Networking||}}
:{{kernelconf|CONFIG_BT_HCIUSB|<M>|HCI USB driver|Bluetooth device drivers|Bluetooth subsystem support|Networking|}}

:{{cmdroot|make && make modules_install}}

* Install the requiered packages
To mount the filesystem we need the fuse program. FuseFS is also implemented in the kernel, but for some reason it only works with 2.6.18. If you run 2.6.17 or earlier, please download it and build the module according to your distro.

* Emerge or apt-get bluez-utils and obexfs. This should pull other required packages (bluez-libs, openobex, obexftp, sys-fs/fuse) as dependencies.

:{{cmdroot|emerge bluez-utils obexfs}}

* Modify /etc/bluetooth/hcid.conf if you haven't already. It can be done as above, or use the following:
options {
autoinit yes"
security user
pairing multi
pin_helper /usr/bin/bluepin
}
device {
name testname
class 0x3e0100
iscan enable
pscan enable
lm accept
lp rswitch,hold,sniff,park
}

* load the modules:
:{{cmdroot|modprobe fuse}}
:{{cmdroot|modprobe bluetooth}}
:{{cmdroot|modprobe ehci-hcd}}
:{{cmdroot|modprobe uhci-hcd}}
:{{cmdroot|modprobe hci_usb}}
:{{cmdroot|modprobe l2cap}}
:{{cmdroot|modprobe rfcomm}}

* activate your bluetooth (show howto ibm-acpi for more details) by using fn+f5 or:
:{{cmdroot|echo enable >/proc/acpi/ibm/bluetooth}}

* start the bluetooth device:
:{{cmdroot|/etc/init.d/bluetooth start}}

* turn on bluetooth of your mobile phone (visible mode) and get the mac-address of your phone using hcitool.
:{{cmdroot|hcitool scan}}

=== For non symbian mobile phones ===

* mount your phone - don't forget to umount it when you're finished
:{{cmdroot|mkdir /mnt/phone}}
:{{cmdroot|mount -t fuse "obexfs#-b00:16:20:32:25:3C -B6" /mnt/phone}}
''use your mac-address instead of my 00:16:20:32:25:3C and don't forget the -b option in front of the mac''

Works perfectly with IBM T43p, X41, sony ericsson k750i, nokia 6280, samsung z400, sony ericsson k700i.

=== Mounting Symbian Phones ===

* You need network file system support in your kernel

:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|make menuconfig}}

:{{kernelconf|NFS_FS|<M>|NFS file system support|Network File Systems|File Systems|||}}
:{{kernelconf|NFS_V3|<M>|Provide NFSv3 client support|Network File Systems|File Systems|||}}

:{{kernelconf|NFSD|<M>|NFS server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_V3|<*>|Provide NFSv3 server support|Network File Systems|File Systems|||}}
:{{kernelconf|NFSD_TCP|<*>|Provide NFS server over TCP support|Network File Systems|File Systems|||}}

:{{cmdroot|make && make modules_install}}

* Install required programs

:{{cmdroot|emerge -av p3nfs}}

* Modify your /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:0F:DE:8C:E6:94;
channel 13;
comment "symbian connection"
}

* restart your bluetooth device, load kernel modules and start portmap (required for p3nfs)

:{{cmdroot|/etc/init.d/bluetooth restart}}
:{{cmdroot|modprobe nfs}}
:{{cmdroot|modprobe nfsd}}

:{{cmdroot|/etc/init.d/portmap start}}

* get the application for your mobile phone [http://www.koeniglich.de/p3nfs.html here]

* start bt at your mobile phone, send application to mobilephone, install and launch the nfsapp with bluetooth at channel 13 (default)

:{{cmdroot|obexftp -b 00:0F:DE:8C:E6:94 -p /home/tava/ablage/nfsapp*}}

* mount your mobile phone:

:{{cmdroot|p3nfsd -UIQ -tty /dev/rfcomm0 -dir /mnt/bluetooth}} (-UIQ is only for UIQ-Phones, type p3nfsd --help and get informations for your phone)

* if doesn't work, make sure rfcomm0 is clean

:{{cmdroot|rfcomm}}

----

===Building from source===
Get the source packages from [http://www.bluez.org www.bluez.org].

Build each of them with the usual steps:
:{{cmduser|./configure && make}}
:{{cmdroot|make install}}

===Gentoo ebuilds===
Under {{Gentoo}}, install the following ebuilds:
*net-wireless/bluez-bluefw
*net-wireless/bluez-firmware
*net-wireless/bluez-hcidump
*net-wireless/bluez-hciemu
*net-wireless/bluez-libs
*net-wireless/bluez-utils

{{NOTE|net-wireless/bluez-kernel is not needed, since the current version is included in your kernel.}}

===Other distributions===
You will find packages for {{Debian}}, {{Redhat}} and {{Slackware}} on the [http://www.bluez.org/packages.html packages page] of the BlueZ project.

==Troubleshooting==
If you cant get hci0 up with a /etc/init.d/bluetooth restart (or similar) then you might want to try a
:{{cmdroot|hciconfig hci0 down && hciconfig hci0 up}}
(solved the problem on a X60s (debian/testing))

==External Links==
*http://gagravarr.org/series-60/
*http://www.polycon.fi/~laa/biblo/linux_gprs.html
*[http://www.gentoo.org/doc/en/bluetooth-guide.xml Guide on how to set up Bluetooth in Gentoo]
*[http://www.linux.ie/articles/bluetoothheadset.php www.linux.ie:Linux and Bluetooth Headset howto (AKA: Fedora, BTSCO, Bluez, Jabra and Skype)]

[[Category:A30]] [[Category:A30p]] [[Category:A31]] [[Category:A31p]] [[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:T60]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:X60]] [[Category:X60s]] [[Category:Z60m]] [[Category:Z60t]]

Talk:How to setup Bluetooth

2006-09-24T15:42:45Z

Gsmenden: Adding file mount info

I just wanted to write down my experiences using Bluetooth to connect my Nokia N70 to my Thinkpad T43, using Gentoo Linux. I'm not sure if ThinkWiki is the right place for this. Feel free to point me into another direction.

Tobias Brox, tobias@nordicbet.com - 2005-12-04

----
Hi,

indeed ThinkWiki is not exactly the right place since the information has not very much to do with ThinkPads in particular. However, since we are missing any Bluetooth documentation at the time, I'm going to give this page a reasonable title and will do some reformatting later on. Please read [[Help:Editing]].

[[User:Wyrfel|Wyrfel]] 20:18, 5 Jan 2006 (CET)
----

Hei,

I renamed the page to reflect the idea of having it as a general Bluetooth setup howto. The first two sections are already generic enough for that. Connecting to a mobile phone should be a section in this page, like it is at current state in the serial connection section. I think that's fine, since you might want to connect to other modem like devices through serial over bluetooth and the procedure should be the same. Hence, lets structure this page in "applications" like "serial over bluetooth", "obex file transfer" etc., very much as it is now. However, things still need to be improved.

[[User:Wyrfel|Wyrfel]] 12:23, 8 Jan 2006 (CET)
----

== BT_RFCOMM note ==

Why does BT_RFCOMM can not be made a module? There is no explanation anywhere in the text for that note...

[[User:Hmh|hmh]] 2006-02-22 01:48 UTC
----
It's an information the original author took from an external HOWTO. Don't know about it but was always wondering myself. If anyone can prove this wrong, please remove the note.

[[User:Wyrfel|Wyrfel]] 13:33, 27 February 2006 (CET)
----
I'm using BT_RFCOMM as a module with my BTA-6030 USB dongle. I expect the same with a one built-in Thinkpads.

cstamas 20:05, 8 Apr 2006 (CET)
----

The recent addition regarding file mounting and fuse, while accurate, was added without regard for the duplicate information in the article (was just "pasted" on top.) It makes the article long and confusing. I'll revise, and am open to comments.
[[User:gsmenden|gsmenden]] 11:43, 24 September 2006 (EST)

Problems with fglrx

2006-09-23T18:39:25Z

Gsmenden: /* Composite Support */ - working much better with latest x.org and 2.6.18

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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:

:{{cmduser|fglrxinfo}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.1)}}

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri}}

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

instead of that:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|drmOpenByBusid: busid is PCI:1:0:0}}
:{{cmdresult|drmOpenDevice: minor is 0}}
:{{cmdresult|drmOpenDevice: node name is /dev/dri/card0}}
:{{cmdresult|drmOpenDevice: open result is 4, (OK)}}
:{{cmdresult|drmOpenByBusid: drmOpenMinor returns 4}}
:{{cmdresult|drmOpenByBusid: drmGetBusid reports PCI:1:0:0}}
:{{cmdresult|Can't open configuration file /home/merlin/.drirc: No such file or directory.}}
:{{cmdresult|fglrx: DPD supported.}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: ATI Technologies Inc.}}
:{{cmdresult|OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)}}
:{{cmdresult|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.

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|-
|{{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.
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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 kernel 2.6.18, and 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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
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: {{path|/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: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

Intalling version >= 8.25.18 of the fglrx driver (Debian package at [http://www.stanchina.net/~flavio/debian-official/fglrx-driver.html]) may solve this problem.

===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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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.

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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Problems with fglrx

2006-08-14T04:10:01Z

Gsmenden: /* Composite Support */ - wrong braces

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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 [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
gandalf:~$ 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:
gandalf:~$ 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.

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# 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
</pre>

=== 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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|-
|{{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.
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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. Depending on your tolerances for slow window refresh, you may find it useful for a quite beautiful desktop. Expect the 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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
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: {{path|/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: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

===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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Problems with fglrx

2006-08-14T04:07:30Z

Gsmenden: /* Composite Support */

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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 [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
gandalf:~$ 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:
gandalf:~$ 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.

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# 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
</pre>

=== 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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|-
|{{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.
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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. Depending on your tolerances for slow window refresh, you may find it useful for a quite beautiful desktop. Expect the drivers to improve in the future, but it seems that composite does require a very fast 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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
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: {{path|/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: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

===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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Problems with fglrx

2006-08-14T04:05:48Z

Gsmenden: /* Composite Support */ - now works with R300 drivers

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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 [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
gandalf:~$ 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:
gandalf:~$ 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.

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# 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
</pre>

=== 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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|-
|{{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.
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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. Depending on your tolerances for slow window refresh, you may find it useful for a quite beautiful desktop. Expect the drivers to improve in the future, but it seems that composite does require a very fast 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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
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: {{path|/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: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

===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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Talk:How to hotswap Ultrabay devices

2006-06-20T02:23:42Z

Gsmenden: libata and 2.6.17

I recently tried using the libata-tj patch tarball for 2.6.16.16, applying this against the newly released 2.6.16.18 kernel (released today.) Patch applied cleanly. Upon boot, I immediately get a multitude of "weird" errors -- strange lockups, programs segmentation fault (running "top" resulted in a seg fault), and ultimately a hard lockup.

I booted back to my vanilla 2.6.16.16, ran fsck (appeared to just replay a few transactions, no major damage), and am back to normal. However, it successfully scared me off - unfortunately can't risk too much downtime (or worse, subtle fs corruption) right now on my main system. Anybody have experiences with this on a T43p using piix driver?

--[[User:gsmenden|gsmenden]] 00:00, 23 May 2006 (EST)
----

The 2.6.16.16 patch works fine on my T43. There's a git tree (mentioned on the patch's webpage) which is closer to 2.6.18, but AFAIK no simple unified patch was prepred.

--[[User:Thinker|Thinker]] 08:37, 23 May 2006 (CEST)
----

Cool. If I get brave I'll try it again on the 43p against 2.6.16.16 proper and report back.

--[[User:gsmenden|gsmenden]] 15:29, 23 May 2006 (EST)
----

Works fine here on 2.6.16.
I got only one crash with Suspend to Ram, which I'm unable to reproduce yet.
I renamed the acpi event files because at least my acpid doesn't read files that ends with .conf

--[[User:Defiant|Defiant]] 21:09, 28 May 2006 (CEST)

----
Update - patched against 2.6.16.19, works fine. It appears my previous problems were due to a disk error unrelated to the patch. Excellent!

--[[User:gsmenden|gsmenden]] 00:57, 31 May 2006 (EST)

Anybody have time to make a patch of the libata(-tj) .git tree against the recently released 2.6.17? I hope to make one in the future if not...

--[[User:gsmenden|gsmenden]] 22:08, 19 Jun 2006 (EST)

Talk:How to change the BIOS bootsplash screen

2006-06-06T00:00:50Z

Gsmenden: Flash off CDROM

Q:What happens if the laptop is protected by fingerprint/password?
Will I need to enter the password first, or can I reboot from a CD even without the password?

A:On a T43p it will allow you to upgrade the BIOS after you swipe your fingerprint or input the password. The upgrade *does not* erase the password/biometric information you had on file. (Very useful, as the utility to enroll fingerprint was deleted when I wiped Windows for Linux...)

If you don't have the fingerprint / password, well, umm... what happened to your finger? :)

---

Anyone know if this works on a T20? There's no mention of it in the article, and I can't find any mention of "BIOS splash(screen)" at htpp://ibm.com 
- I'd be grateful if you could email me at stroller at bigfoot dot com if you know the answer to this

---

Q:Hm, where to get the prepare.exe? It's not included in the BIOS upgrade disk of my i1200. But, of coursem one has to keep in mind that the i1200 is equiped with an ACER BIOS, so the described procedure may not work at all. Heck, I'll just try it out using the sample mod file, off for rebooting ... wich doesn't work because - i fear - my CD drive is again going downhill.

A: Prepare.exe is found in the compressed cab file 1yu****.exe (BIOS upgrade file from IBM). It is used by corporations so they can equip their fleets with custom bootsplash screens like we do at work...

---

Q:I'm getting an error saying that the diskette isn't compatible with my system, and to reboot (with all versions of the software). My best guess so far is that it is because I deleted the partition used by the "Access IBM" button (the one that was previously hidden). Does anyone have any experience similar to this?

A: I don't think that is the problem -- I deleted my access IBM / recovery partition and still flashed my BIOS ok. What is your system model #? I burned the upgrade image to CD-ROM (outlined in the wiki) and booted off this to flash the BIOS without problem...
[[User:gsmenden|gsmenden]] 19:53 05 Jun 2006 (EST)

== Changing logos! ==
An interesting bit of trivia - the superimposed "Centrino" logo will change to a superimposed "Pentium M" logo if you disable the wi-fi networking in the BIOS. The "Centrino" label requires wireless networking... :)
[[User:gsmenden|gsmenden]] 19:33 11 Feb 2006 (EST)

== Brocken Link ==
I can't access logo.bmp and logo.mod. anybody know where they are now ? --[[User:Xtophe|Xtophe]] 20:14, 24 February 2006 (CET)

Template:ThinkWiki News

2006-06-05T23:11:56Z

Gsmenden: Full desc. too long.

05.06.2006: According to CNET [http://news.com.com/2100-1003_3-6080115.html?part=rss&tag=6080115&subj=news], Lenovo is now denying dropping official Linux support.

04.06.2006: Sad news! According to CRN [http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=188701277], Lenovo drops official Linux support for its PCs, including ThinkPads.

23.05.2006: New Xorg 7.1 released! Including support for AIGLX and more. [http://xorg.freedesktop.org/releases/X11R7.1/doc/RELNOTES.html Releasenotes]

14.05.2006: New kernel patches enable [[How_to_hotswap_UltraBay_devices#When_using_the_ata_piix_driver|UltraBay hotswapping on recent ThinkPads]]

05.05.2006: It's proven! [http://www.lifehacker.com/software/mac-os-x/dual-boot-windows-xp-mac-os-on-a-thinkpad-151121.php Mac OS X] runs on ThinkPads.

12.04.2006: ThinkWiki's user count has exceeded 1 KB.

25.03.2006: ThinkWiki has been upgraded to [[Special:Version|MediaWiki 1.5.7]]

20.03.2006: New [http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.bz2 Linux 2.6.16] with better energy saving and improved SATA support.

Template:ThinkWiki News

2006-06-05T23:10:37Z

Gsmenden: Linux support

05.06.2006: According to CNET [http://news.com.com/2100-1003_3-6080115.html?part=rss&tag=6080115&subj=news], Lenovo is now denying dropping Linux, and will support Linux in the third quarter through its Novell agreement, likely SuSE distro.

04.06.2006: Sad news! According to CRN [http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=188701277], Lenovo drops official Linux support for its PCs, including ThinkPads.

23.05.2006: New Xorg 7.1 released! Including support for AIGLX and more. [http://xorg.freedesktop.org/releases/X11R7.1/doc/RELNOTES.html Releasenotes]

14.05.2006: New kernel patches enable [[How_to_hotswap_UltraBay_devices#When_using_the_ata_piix_driver|UltraBay hotswapping on recent ThinkPads]]

05.05.2006: It's proven! [http://www.lifehacker.com/software/mac-os-x/dual-boot-windows-xp-mac-os-on-a-thinkpad-151121.php Mac OS X] runs on ThinkPads.

12.04.2006: ThinkWiki's user count has exceeded 1 KB.

25.03.2006: ThinkWiki has been upgraded to [[Special:Version|MediaWiki 1.5.7]]

20.03.2006: New [http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.bz2 Linux 2.6.16] with better energy saving and improved SATA support.

Problems with fglrx

2006-06-04T00:54:05Z

Gsmenden: /* Composite Support */

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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 [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# 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
</pre>

=== 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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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' (rage3d.com/board) Linux area.

There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 7.0 (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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
AlwaysRestartServer=true

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

Another reason of hardlock my be agp driver. Make sure that you have proper driver for your motherboard loaded before fglrx: (gentoo: {{path|/etc/modules.autoload.d/kernel-2.6}}):
intel-agp
fglrx

Information from gentoo bugtracker: http://bugs.gentoo.org/show_bug.cgi?id=113685

===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 {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

Talk:Problem with fan noise

2006-06-02T03:10:03Z

Gsmenden: /* Fan speed control? */

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...
----
"Word on the net" is usually synonym to bullshit. The datasheets are available for download at Intel's site, go read them. For the P4, 80C is the absolute maximum limit, and in the newer Pentiums, the chip itself will MCE and enable clock modulation if you try to make it exceed 80C. I didn't read the new Pentium-M's datasheet yet.

Letting the machine run hot is not a good idea, anyway. It shortens its lifespan considerably, especially the harddrive's. Don't play games with this.
----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more safe version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

On my machine this seems to be related to the third temperature in /proc/acpi/ibm/thermal. The fan will be started whenever this value climbs to 46 degrees. It won't be stopped once the value drops to 45, of course. But if you detach/attach AC supply, this somehow resets the control logic and the fan will stop if the value is <=45. Unfortunately, it will quickly increase to 46, and the fan will start again.

The threshold temperature for stopping the fan seems to be 41 degrees, but the fan running at its default speed of ~4500 will only keep it around 44-46.

It would be quite interesting to know where that sensor No. 3 is located on the X41.

--[[User:Robert-qfh|Robert-qfh]] 20:11, 02 Mar 2006 (CET)

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

----

Anybody tried to slow down the fan and have it running at ~1000-1500rpm? That would make it almost silent and you could have it always running (like Apple does on Macs).

--[[User:Micampe|Micampe]] 12:56, 7 Dec 2005 (CET)
----

Goot question. The embedded controller [[patch_for_controlling_fan_speed|interface]] we have discovered allows only for setting a fan level between 0 and 7, not the actual RPM. And IBM has been ramping up the RPM assignment of each fan level (look at the model-specific data there), so that on the T43, even the lowest accessible level is at a pretty fast 3300RPM. The following ''might'' provide a way around this, if the hardware is capable of generating lower speeds:
* Patch the embedded controller firmware. You will need the information in [http://forum.thinkpads.com/viewtopic.php?p=113904#113904 this post] and the following one, a lot of patience, and an active warranty.
* Find out how the embedded controller is setting the speed (maybe by disassembling it as above, but at least you don't need to load patched firmware). Maybe the EC is changing the speed by instructing ''another'' component over an interface (SMBus?) that can also be accessed directly by the CPU. In this case, maybe you can put the embedded controller in disengaged mode and control that component directly.

Then, there's the soldering-iron approach. Assuming the fan uses the standard wiring and that its speed determined by the provided voltage, you can make all speeds somewhat slower simply by putting a resistor in series with the fan. You can do that by splicing one of the wires or, to avoid voiding your warranty, just build an extension cable like this:

fan cable extension
#------- Vfan --------#> >#---~~R~~---#> >#SYSTEM
FAN#------- SENSE -------#> >#-----------#> >#BOARD
#------- GND ---------#> >#-----------#> >#CONNECTOR

Use an appropriate resistor R, and make sure it doesn't get too hot (if it does, attach it to the fan's cooling assembly). Worked nicely for me a few years ago on some desktop motherboard. If you're into that kind of stuff, you can also use fancier electronics instead of the resistor to avoid the (minor) power waste.

It would be useful to have some pictures of the fan cable connector so we can get a matching pair (it's above the rear right corner of the PCMCIA slot, under the palmrest but maybe visible with just the keyboard removed).

--[[User:Thinker|Thinker]] 14:36, 7 Dec 2005 (CET)
----
It's just barely visible without the fan assembly removed. Here is a [http://hcs.harvard.edu/~gsmenden/t43pfan.JPG picture of the area]. The fan assembly connector is the white 3 prong connector almost obscured by the PCMCIA doors, female end visible on the removed fan assembly. I can give you a closeup if it will be useful, but it is a pretty standard connector. The long grey wire in the photo is for the microphone input. Surprisingly, there is a lot of room in that local area (see the notch in the fan assembly), clearly enough for an extension with resistor. Of course, the need is kind of obviated by the software fan speed control now.
--[[User:gsmenden|gsmenden]] 22:53, 1 Jun 2006 (EST)

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

This discussion was moved to [[Talk:Thermal sensors]].

== X21 overacceleration problem ==

On my X21 2662-66U, the fan runs all the time. That's not an issue, because of how hot my laptop runs.

However, at load, it runs really hot. I can hear the fan attempt to accelerate past the maximum speed, click three times, and drop back down to the max. It's not the same as the pulsing problem, yet similar.

New fan, ordered direct from IBM, due to my old fan running WAY too hot, even underclocked. As it is, I'm running underclocked because 95 C at full load is just NOT my cup of tea. 40 C idle temps at 500MHz, around 60 at 700MHz. 70 C load at 500, 95 C load at 700.

== Startup noise ==

My T43 accelerates the fan to very high speed twice during startup: immediately after power-on, and during the bootloader prompt (i.e., after the BIOS but before Linux loads). This is independent of the unit's temperature, and is loud enough to cause some ugly stares when sitting in a lecture. Is this a universal phenomenon, worth mentioning in the article page?

Potential solutions: the first fan acceleration can't be fixed by anything but an EC firmware update. For the second acceleration (after BIOS), a workaround can be implemented by adding basic fan control code (i.e., a few accesses to I/O ports 0x62 and 0x66 as explained in the [[Patch_for_controlling_fan_speed#Hardware_specs|fan control specs]] and Linux's {{path|drivers/acpi/ec.c}}) to the bootloader. GRUB 2 has a module infrastructure that should make this pretty easy, and other boot loaders can also be patched.

--[[User:Thinker|Thinker]] 20:36, 27 Dec 2005 (CET)
----

== Leftover bits ==

The following data didn't belong where it was posted, and was deleted when the containing section swre moved to [[How to control fan speed]]:

* On my T41 (gentoo-sources-2.6.11.11 ) I noticed that after unloading the fan module the fan noise stopped. With the module loaded the fan was working even at very low cpu temperatures, without the module it's ok so far.

* On a 770X the fan can be fully controlled through ACPI. Thermal Zone THM5 (possibly the battery/charging circuit, it's definitely warmer when using 5v PCMCIA cards and AC) triggers it to turn on and not ever off by design. Can be solved by a custom DSDT, which also makes use of the variable-speed features of the fan (will release this once I've finished tweaking and testing it).

--[[User:Thinker|Thinker]] 20:48, 20 January 2006 (CET)
----

== Embedded controller firmware disassembly ==

[http://forum.thinkpads.com/viewtopic.php?t=20958 This thread] points to, and discusses, a commented (partial) disassembly of the embedded controller. Following this lead, it may be possible to patch the firmware (perhaps transiently) to change the fan level selection algorithm and/or the RPMs.

--[[User:Thinker|Thinker]] 07:10, 24 February 2006 (CET)
----

== R50e with CELERON M: fan for life ==

I am such a loser. I bought a R50e with CELERON M CPU, and thus will
never get longer than 90 seconds of peace before the next 62 to 54
degree fan cycle. --jidanni

== FAN Problem with T42 ==

Hello I have got a T42 and implemented on my gentoo System with a 2.6.15 kernel the fan script. My problem is that I don't know which values I have to set in the fan-control script. My fan ist loudless for only about 5 minutes than the cpu temperature arrives about 50 degree. Another problem ist the combination with the "conservative" govenour. If I use a Software which raises cpu load the script seems to raise up the fan to the maximum for about 2 seconds and then calm it down. This not fine for office work. Do you have some ideas? Another problem is my /proc/acpi/processor/CPU0/throttling, because it never switches the states!
Any help? Thanks for answers

state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%

== Mowing the lawn ==
For the past two days, my thinkpad fan suddenly turned extremely loud - it really sounds like when we'd put playing cards on the spokes of our bikes as kids to make them sound like motorbikes. It's loud enough that I can't take my laptop to the library, and extremely annoying.

We have a new onsite thinkpad repair place here at Harvard, and I took the laptop to them. Unfortunately, the guys wanted me to sign something that said, "If we can't find anything wrong with your computer on hardware diagnostics, then you will pay $45 for a diagnostic fee." I repeatedly told them that any hardware diagnostic scan will show that the system is normal; I think it is a bad bearing or some sort of obstruction of the fan. However, then they switched, "if we find it is within operating decibels for the laptop." Alas, I asked them if they actually have a microphone they hold to the machine, and they really wouldn't answer. We fired up the machine, but their office in the basement of our science center was so loud that it was hard to hear the clanging noise, which really gets going after a few minutes...

Alas, I elected to drop ship the machine to Lenovo / IBM because I felt these guys wouldn't repair / replace the fan. Alternatively, I am thinking of ordering the FRU and just doing it myself, it's around $40, and possibly doing some thermal mods as described in various linked threads.

Thinker, did you ever figure out a way to hardwire the fan to constant rpm perchance?
--[[User:gsmenden|gsmenden]] 18:24, 29 May 2006 (EST)

Update - I received the fan assembly (FRU 26R9074, retail $37.50 USD) and replaced it without any problem. There are a couple places where one could definitely go wrong / damage the laptop, but warnings are pretty clearly outlined in the Hardware Maintenance Manual. All done, for less than the diagnostic fee. You'll need some heatsink grease - I'll put pictures online of the process if I ever get a chance.

I did not bother with any thermal "mods" - I believe that heat transfer is not the problem regarding the fan always on, as described elsewhere in this wiki and fixed (at least partially) by Thinker et al's script.

No wires were contacting my old fan, nor was it excessively dirty. Flicking it to spin with my finger makes the same rattling sound - I think the axis just came off or one of the bearings was bad. Now my laptop is whisper-quiet.

Do NOT get the IBM "Screwdriver kit" for $34. I thought it would be a nice toolset with case, but it is a cheapo set of screwdrivers in a cheapo plastic case, literally available online for $5.95 (the EXACT SAME model!). Go to Fry's, get some nice tools, and then head to your local pub for 6 more screwdrivers with the money you saved. Needless to say, I will return this.
--[[User:gsmenden|gsmenden]] 22:09, 01 Jun 2006 (EST)

Talk:Problem with fan noise

2006-06-02T03:08:30Z

Gsmenden: /* Fan speed control? */

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...
----
"Word on the net" is usually synonym to bullshit. The datasheets are available for download at Intel's site, go read them. For the P4, 80C is the absolute maximum limit, and in the newer Pentiums, the chip itself will MCE and enable clock modulation if you try to make it exceed 80C. I didn't read the new Pentium-M's datasheet yet.

Letting the machine run hot is not a good idea, anyway. It shortens its lifespan considerably, especially the harddrive's. Don't play games with this.
----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more safe version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

On my machine this seems to be related to the third temperature in /proc/acpi/ibm/thermal. The fan will be started whenever this value climbs to 46 degrees. It won't be stopped once the value drops to 45, of course. But if you detach/attach AC supply, this somehow resets the control logic and the fan will stop if the value is <=45. Unfortunately, it will quickly increase to 46, and the fan will start again.

The threshold temperature for stopping the fan seems to be 41 degrees, but the fan running at its default speed of ~4500 will only keep it around 44-46.

It would be quite interesting to know where that sensor No. 3 is located on the X41.

--[[User:Robert-qfh|Robert-qfh]] 20:11, 02 Mar 2006 (CET)

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

----

Anybody tried to slow down the fan and have it running at ~1000-1500rpm? That would make it almost silent and you could have it always running (like Apple does on Macs).

--[[User:Micampe|Micampe]] 12:56, 7 Dec 2005 (CET)
----

Goot question. The embedded controller [[patch_for_controlling_fan_speed|interface]] we have discovered allows only for setting a fan level between 0 and 7, not the actual RPM. And IBM has been ramping up the RPM assignment of each fan level (look at the model-specific data there), so that on the T43, even the lowest accessible level is at a pretty fast 3300RPM. The following ''might'' provide a way around this, if the hardware is capable of generating lower speeds:
* Patch the embedded controller firmware. You will need the information in [http://forum.thinkpads.com/viewtopic.php?p=113904#113904 this post] and the following one, a lot of patience, and an active warranty.
* Find out how the embedded controller is setting the speed (maybe by disassembling it as above, but at least you don't need to load patched firmware). Maybe the EC is changing the speed by instructing ''another'' component over an interface (SMBus?) that can also be accessed directly by the CPU. In this case, maybe you can put the embedded controller in disengaged mode and control that component directly.

Then, there's the soldering-iron approach. Assuming the fan uses the standard wiring and that its speed determined by the provided voltage, you can make all speeds somewhat slower simply by putting a resistor in series with the fan. You can do that by splicing one of the wires or, to avoid voiding your warranty, just build an extension cable like this:

fan cable extension
#------- Vfan --------#> >#---~~R~~---#> >#SYSTEM
FAN#------- SENSE -------#> >#-----------#> >#BOARD
#------- GND ---------#> >#-----------#> >#CONNECTOR

Use an appropriate resistor R, and make sure it doesn't get too hot (if it does, attach it to the fan's cooling assembly). Worked nicely for me a few years ago on some desktop motherboard. If you're into that kind of stuff, you can also use fancier electronics instead of the resistor to avoid the (minor) power waste.

It would be useful to have some pictures of the fan cable connector so we can get a matching pair (it's above the rear right corner of the PCMCIA slot, under the palmrest but maybe visible with just the keyboard removed).

--[[User:Thinker|Thinker]] 14:36, 7 Dec 2005 (CET)
----
It's not quite visible without the fan assembly removed. Here is a [http://hcs.harvard.edu/~gsmenden/t43pfan.JPG picture of the area]. The fan assembly connector is the white 3 prong connector almost obscured by the PCMCIA doors, female end visible on the removed fan assembly. I can give you a closeup if it will be useful, but it is a pretty standard connector. The long grey wire in the photo is for the microphone input. Surprisingly, there is a lot of room in that local area (see the notch in the fan assembly), clearly enough for an extension with resistor. Of course, the need is kind of obviated by the software fan speed control now.
--[[User:gsmenden|gsmenden]] 22:53, 1 Jun 2006 (EST)

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

This discussion was moved to [[Talk:Thermal sensors]].

== X21 overacceleration problem ==

On my X21 2662-66U, the fan runs all the time. That's not an issue, because of how hot my laptop runs.

However, at load, it runs really hot. I can hear the fan attempt to accelerate past the maximum speed, click three times, and drop back down to the max. It's not the same as the pulsing problem, yet similar.

New fan, ordered direct from IBM, due to my old fan running WAY too hot, even underclocked. As it is, I'm running underclocked because 95 C at full load is just NOT my cup of tea. 40 C idle temps at 500MHz, around 60 at 700MHz. 70 C load at 500, 95 C load at 700.

== Startup noise ==

My T43 accelerates the fan to very high speed twice during startup: immediately after power-on, and during the bootloader prompt (i.e., after the BIOS but before Linux loads). This is independent of the unit's temperature, and is loud enough to cause some ugly stares when sitting in a lecture. Is this a universal phenomenon, worth mentioning in the article page?

Potential solutions: the first fan acceleration can't be fixed by anything but an EC firmware update. For the second acceleration (after BIOS), a workaround can be implemented by adding basic fan control code (i.e., a few accesses to I/O ports 0x62 and 0x66 as explained in the [[Patch_for_controlling_fan_speed#Hardware_specs|fan control specs]] and Linux's {{path|drivers/acpi/ec.c}}) to the bootloader. GRUB 2 has a module infrastructure that should make this pretty easy, and other boot loaders can also be patched.

--[[User:Thinker|Thinker]] 20:36, 27 Dec 2005 (CET)
----

== Leftover bits ==

The following data didn't belong where it was posted, and was deleted when the containing section swre moved to [[How to control fan speed]]:

* On my T41 (gentoo-sources-2.6.11.11 ) I noticed that after unloading the fan module the fan noise stopped. With the module loaded the fan was working even at very low cpu temperatures, without the module it's ok so far.

* On a 770X the fan can be fully controlled through ACPI. Thermal Zone THM5 (possibly the battery/charging circuit, it's definitely warmer when using 5v PCMCIA cards and AC) triggers it to turn on and not ever off by design. Can be solved by a custom DSDT, which also makes use of the variable-speed features of the fan (will release this once I've finished tweaking and testing it).

--[[User:Thinker|Thinker]] 20:48, 20 January 2006 (CET)
----

== Embedded controller firmware disassembly ==

[http://forum.thinkpads.com/viewtopic.php?t=20958 This thread] points to, and discusses, a commented (partial) disassembly of the embedded controller. Following this lead, it may be possible to patch the firmware (perhaps transiently) to change the fan level selection algorithm and/or the RPMs.

--[[User:Thinker|Thinker]] 07:10, 24 February 2006 (CET)
----

== R50e with CELERON M: fan for life ==

I am such a loser. I bought a R50e with CELERON M CPU, and thus will
never get longer than 90 seconds of peace before the next 62 to 54
degree fan cycle. --jidanni

== FAN Problem with T42 ==

Hello I have got a T42 and implemented on my gentoo System with a 2.6.15 kernel the fan script. My problem is that I don't know which values I have to set in the fan-control script. My fan ist loudless for only about 5 minutes than the cpu temperature arrives about 50 degree. Another problem ist the combination with the "conservative" govenour. If I use a Software which raises cpu load the script seems to raise up the fan to the maximum for about 2 seconds and then calm it down. This not fine for office work. Do you have some ideas? Another problem is my /proc/acpi/processor/CPU0/throttling, because it never switches the states!
Any help? Thanks for answers

state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%

== Mowing the lawn ==
For the past two days, my thinkpad fan suddenly turned extremely loud - it really sounds like when we'd put playing cards on the spokes of our bikes as kids to make them sound like motorbikes. It's loud enough that I can't take my laptop to the library, and extremely annoying.

We have a new onsite thinkpad repair place here at Harvard, and I took the laptop to them. Unfortunately, the guys wanted me to sign something that said, "If we can't find anything wrong with your computer on hardware diagnostics, then you will pay $45 for a diagnostic fee." I repeatedly told them that any hardware diagnostic scan will show that the system is normal; I think it is a bad bearing or some sort of obstruction of the fan. However, then they switched, "if we find it is within operating decibels for the laptop." Alas, I asked them if they actually have a microphone they hold to the machine, and they really wouldn't answer. We fired up the machine, but their office in the basement of our science center was so loud that it was hard to hear the clanging noise, which really gets going after a few minutes...

Alas, I elected to drop ship the machine to Lenovo / IBM because I felt these guys wouldn't repair / replace the fan. Alternatively, I am thinking of ordering the FRU and just doing it myself, it's around $40, and possibly doing some thermal mods as described in various linked threads.

Thinker, did you ever figure out a way to hardwire the fan to constant rpm perchance?
--[[User:gsmenden|gsmenden]] 18:24, 29 May 2006 (EST)

Update - I received the fan assembly (FRU 26R9074, retail $37.50 USD) and replaced it without any problem. There are a couple places where one could definitely go wrong / damage the laptop, but warnings are pretty clearly outlined in the Hardware Maintenance Manual. All done, for less than the diagnostic fee. You'll need some heatsink grease - I'll put pictures online of the process if I ever get a chance.

I did not bother with any thermal "mods" - I believe that heat transfer is not the problem regarding the fan always on, as described elsewhere in this wiki and fixed (at least partially) by Thinker et al's script.

No wires were contacting my old fan, nor was it excessively dirty. Flicking it to spin with my finger makes the same rattling sound - I think the axis just came off or one of the bearings was bad. Now my laptop is whisper-quiet.

Do NOT get the IBM "Screwdriver kit" for $34. I thought it would be a nice toolset with case, but it is a cheapo set of screwdrivers in a cheapo plastic case, literally available online for $5.95 (the EXACT SAME model!). Go to Fry's, get some nice tools, and then head to your local pub for 6 more screwdrivers with the money you saved. Needless to say, I will return this.
--[[User:gsmenden|gsmenden]] 22:09, 01 Jun 2006 (EST)

Problem with fan noise

2006-06-02T02:36:24Z

Gsmenden: /* Cleaning the fan or removing obstructions */

Information about the fan noise problem in Thinkpad models from 2003/2004/2005.

==Problem description==

There seem to be two different issues causing annoyance from fan noise:

===Acceleration (pulsing) problem===
The Thinkpad fan briefly accelerates in regular intervals (every few seconds), causing an annoying periodic pulse noise.

See [http://lophiomys.gmxhome.de/Thinkpad_R50_Periodic_Fan_Noise.html here] for audio recordings of this noise on ThinkPad {{R50}} and {{R51}}.

===Always-on problem===
The fan is always on, even when the laptop is rather cool.

==Affected Models==

===Acceleration (pulsing) problem:===
*ThinkPad {{600E}}
*ThinkPad {{R40}}
*ThinkPad {{T40}}, {{T40p}}, {{T41}}, {{T42}}, {{T43}}

===Always-on problem:===
*ThinkPad {{600X}}
*ThinkPad {{770X}}
*ThinkPad {{A31p}}
*ThinkPad {{R32}}, {{R50}}, {{R50p}}, {{R51}}, {{R52}}
*ThinkPad {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}
*ThinkPad {{X32}}, {{X40}}, {{X41}}
*ThinkPad {{Z60m}}

==Affected Operating Systems==

===Acceleration (pulsing) problem:===
*Linux, all flavours
*Windows XP

===Always-on problem:===
*Linux, all flavours
*FreeBSD 5.3
*OpenBSD 3.7 (Tested with X40)
*Windows XP
*Windows 2000 pro

==Status==

===Acceleration (pulsing) problem:===
The pulsing seems to be triggered by the embedded controller when it monitors the fan speed and adjusts the fan control accordingly every few seconds.

For some models, IBM released an update to the embedded controller program that seems to at least partially solve this problem:

Version 3.03 - 1RHT70WW
NOTE: This version of Embedded Controller Program will only work with BIOS Version 3.06f (or higher).
* (Fix) Reduced Fan noise in some models.

The update can be found here: http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50279

For other models (e.g., ThinkPad {{T43}}), there is a software workaround (see below).

===Always-on problem:===
The problem is yet unsolved. But see the partial fix below.

IBM made a statement regarding this on their homepage:
http://www-307.ibm.com/pc/support/site.wss/MIGR-56504.html

==Solutions==

===Acceleration problem:===

====Replacing the fan====
Some people reported that they replaced the original fan against one of a similar notebook without the problem has worked for them, i.e. changing a {{T41}}s fan against one from a {{T41p}}.

====BIOS upgrade====
For relevant models, you can try upgrading your embedded controller program to version 3.03 or newer.
The update can be found here: http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50279

Also, in late November 2005 IBM released a BIOS and embedded controller update (BIOS 1.24, EC 1.04) for the T43/p
(Machine types 2668, 2669, 2678, 2679, 2686, 2687). Reported results are not consistent and range from cooler sensor readings (some sensors seem to report lower temperatures with this patch), less fan pulsing (also only reported by some users), and slightly different fan behaviour.
The link to this update is: http://www-306.ibm.com/pc/support/site.wss/document.do?sitestyle=ibm&lndocid=MIGR-58597#bios

====Software workaround====
The problem can be solved through appropriate modulation of the embedded controller, using an [[ACPI fan control script#Variable speed control scripts|ACPI fan control script]].

===Always on problem:===

====Reducing power consumption====
Generally, this problem is triggered by heating due to high power consumption. See [[How to reduce power consumption]].

It seems like for some people a combination of enabling dynamic frequency scaling and using the most recent radeon drivers (from xorg 6.8.x) with the DynamicClocks option enabled helped lowing the fan rotation and hence making it more quiet.

Also the fglrx driver from ATI is said to show the same effect when used together with dynamic frequency scaling.

I can confirm that on my R51, the graphics card seems to be the problem. The fan keeps running most of the time even with AC on, but even though I activated DynamicClocks (with the radeon driver), I can see in /proc/acpi/ibm/thermal that the GPU (4th value) is at 52-53Â°. The fan stops running as soon as the temperature gets down to 50 degrees and starts again at 53. While debugging, I seemed(!) to be able to reduce the temperature together with the resolution (e.g. "xrandr -s 2" to get from 1400x1050 to 1024x768) or by switching off the graphics with "xset dpms force off". The bottom line is that the below "partial fix" won't work because the GPU temperature is the problem.

The GPU also seems to be the culprit on the t43p. Even with the fan always on (with speeds of around 4K reported in /proc/acpi/ibm/fan), the temperature never drops below 55. This is with the Xorg driver and DynamicClocks=on. With the ATI's fglrx driver, the GPU temp seems slightly higher (although I haven't performed a careful comparison). Without the fan, the temperature very quickly climbs to above 60.

With the Pentium M, CPU heat dissipation can be reduced through [[Pentium M undervolting and underclocking|undervolting and underclocking]].

In regard to the technical side of controlling the fan, see [[How to control fan speed]] for a description of the embedded controller byte at offset 0x2F which controls the fan activity (T4X series and other later models). In addition to these in the discussion to this topic [http://www.thinkwiki.org/wiki/Talk:Problem_with_fan_noise] a user observed hidden temperature sensors. In the ACPI DSDT dump a {{T43}} reports 8 temp values at offset 0x78 (some of which may be off and yield a constant value of 0x80), but there are at least three more values at offset 0xC0 which from observation seem to show temperatures as well. One of these sensors (0xC1) is most likely in the area of the mini PCI slot (related to WLAN activity) and seem to trigger the fan at 43Â°C ({{T43}}, Windows XP). Another one (0xC2) seems to be located below the power supply (rear left, in the area under the Esc, F1-F3 keys). This one noticeably increases when the battery is charged. Both, the 0xC1 and 0xC2 react quite slowly to fan activity.

For more information about the thermal sensors that are monitored to decide the fan speed, see [[Thermal sensors]].

====Software solution - Windows====

http://sourceforge.net/projects/tp4xfancontrol/ actively monitors the CPU Temperature and uses ACPI to manually control the fan speed. It was written for T43, but works on my T40 too.

====Software solution - Linux====

See [[How to control fan speed]].

{{WARN|This circumvents the BIOS fan control, so be careful and use at your own risk! Don't toast your ThinkPad.}}

====Cleaning the fan or removing obstructions====

If your ThinkPad is old or has been exposed to dusty environment, it is possible that accumulated dirt on the fan and the heatsink cause abnormal behavior (though the problems have also been reported for brand new units). You can use a combination of a vacuum cleaner and an air dusting spray to clean things up from the outside. Bigger agglomerations of dust may require removing by tweezers through the openings in the fan grill. Getting to the fan itself from the inside is quite tricky and may require removing the keyboard or LCD - see [[Maintenance#Cleaning_the_Interior|Cleaning the Interior]].

If the fan is especially noisy, there may be some obstruction other than dirt in the way. For instance, in some ThinkPad models, a wire that is not properly taped down can become draped over the CPU fan, slowing down fan rotation and emitting a loud buzzing sound. Moving such an obstruction out of the way can greatly decrease fan noise.

After you clean things up, power on your ThinkPad. You should hear the fan start up for a bit when booting. If it does not, this means that the cleaning procedure has actually blocked the fan and your computer will overheat at some point (BIOS POST test does not appear to catch obstructed fans). Keep cleaning.

If cleaning does not fix the problem, the fan can be replaced as described in your laptop's appropriate Hardware Maintenace Manual: select your laptop at the [[Models#Available Models|Models Page]] and follow the links. All that is generally required is some screwdrivers and heat sink thermal grease. Do NOT attempt to install without the silicon grease.

If you feel comfortable using a soldering iron, you are more than qualified to do the procedure. Just remember do NOT force anything, at several steps there are tiny plastic "tabs" that can break off necessiting a more expensive bezel / keyboard / GPU replacement.

====Hardware modification====
An extensive forum discussion of this problem for the ThinkPad {{T43}}/{{T43p}}, and possible hardware mods for thermal enhancement, appear [http://forum.thinkpads.com/viewtopic.php?t=14580http://forum.thinkpads.com/viewtopic.php?t=14580 here]. There users who had opened the machine reported uncooled Northbridge and Southbrige chips, having no physical connectino to the heat pipe. Building a hardware copper bridge to these did change the temperature characteristics but did not cure the "always on" problem. In an other discussion on that forum a user said that amongh other areas the WLAN chip may be responsible for generating extra heat and that disabling WLAN (among other unused devices) may help.

Talk:Problem with fan noise

2006-06-02T02:24:52Z

Gsmenden: /* Fan noise fixed */

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...
----
"Word on the net" is usually synonym to bullshit. The datasheets are available for download at Intel's site, go read them. For the P4, 80C is the absolute maximum limit, and in the newer Pentiums, the chip itself will MCE and enable clock modulation if you try to make it exceed 80C. I didn't read the new Pentium-M's datasheet yet.

Letting the machine run hot is not a good idea, anyway. It shortens its lifespan considerably, especially the harddrive's. Don't play games with this.
----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more safe version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

On my machine this seems to be related to the third temperature in /proc/acpi/ibm/thermal. The fan will be started whenever this value climbs to 46 degrees. It won't be stopped once the value drops to 45, of course. But if you detach/attach AC supply, this somehow resets the control logic and the fan will stop if the value is <=45. Unfortunately, it will quickly increase to 46, and the fan will start again.

The threshold temperature for stopping the fan seems to be 41 degrees, but the fan running at its default speed of ~4500 will only keep it around 44-46.

It would be quite interesting to know where that sensor No. 3 is located on the X41.

--[[User:Robert-qfh|Robert-qfh]] 20:11, 02 Mar 2006 (CET)

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

----

Anybody tried to slow down the fan and have it running at ~1000-1500rpm? That would make it almost silent and you could have it always running (like Apple does on Macs).

--[[User:Micampe|Micampe]] 12:56, 7 Dec 2005 (CET)
----

Goot question. The embedded controller [[patch_for_controlling_fan_speed|interface]] we have discovered allows only for setting a fan level between 0 and 7, not the actual RPM. And IBM has been ramping up the RPM assignment of each fan level (look at the model-specific data there), so that on the T43, even the lowest accessible level is at a pretty fast 3300RPM. The following ''might'' provide a way around this, if the hardware is capable of generating lower speeds:
* Patch the embedded controller firmware. You will need the information in [http://forum.thinkpads.com/viewtopic.php?p=113904#113904 this post] and the following one, a lot of patience, and an active warranty.
* Find out how the embedded controller is setting the speed (maybe by disassembling it as above, but at least you don't need to load patched firmware). Maybe the EC is changing the speed by instructing ''another'' component over an interface (SMBus?) that can also be accessed directly by the CPU. In this case, maybe you can put the embedded controller in disengaged mode and control that component directly.

Then, there's the soldering-iron approach. Assuming the fan uses the standard wiring and that its speed determined by the provided voltage, you can make all speeds somewhat slower simply by putting a resistor in series with the fan. You can do that by splicing one of the wires or, to avoid voiding your warranty, just build an extension cable like this:

fan cable extension
#------- Vfan --------#> >#---~~R~~---#> >#SYSTEM
FAN#------- SENSE -------#> >#-----------#> >#BOARD
#------- GND ---------#> >#-----------#> >#CONNECTOR

Use an appropriate resistor R, and make sure it doesn't get too hot (if it does, attach it to the fan's cooling assembly). Worked nicely for me a few years ago on some desktop motherboard. If you're into that kind of stuff, you can also use fancier electronics instead of the resistor to avoid the (minor) power waste.

It would be useful to have some pictures of the fan cable connector so we can get a matching pair (it's above the rear right corner of the PCMCIA slot, under the palmrest but maybe visible with just the keyboard removed).

--[[User:Thinker|Thinker]] 14:36, 7 Dec 2005 (CET)
----

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

This discussion was moved to [[Talk:Thermal sensors]].

== X21 overacceleration problem ==

On my X21 2662-66U, the fan runs all the time. That's not an issue, because of how hot my laptop runs.

However, at load, it runs really hot. I can hear the fan attempt to accelerate past the maximum speed, click three times, and drop back down to the max. It's not the same as the pulsing problem, yet similar.

New fan, ordered direct from IBM, due to my old fan running WAY too hot, even underclocked. As it is, I'm running underclocked because 95 C at full load is just NOT my cup of tea. 40 C idle temps at 500MHz, around 60 at 700MHz. 70 C load at 500, 95 C load at 700.

== Startup noise ==

My T43 accelerates the fan to very high speed twice during startup: immediately after power-on, and during the bootloader prompt (i.e., after the BIOS but before Linux loads). This is independent of the unit's temperature, and is loud enough to cause some ugly stares when sitting in a lecture. Is this a universal phenomenon, worth mentioning in the article page?

Potential solutions: the first fan acceleration can't be fixed by anything but an EC firmware update. For the second acceleration (after BIOS), a workaround can be implemented by adding basic fan control code (i.e., a few accesses to I/O ports 0x62 and 0x66 as explained in the [[Patch_for_controlling_fan_speed#Hardware_specs|fan control specs]] and Linux's {{path|drivers/acpi/ec.c}}) to the bootloader. GRUB 2 has a module infrastructure that should make this pretty easy, and other boot loaders can also be patched.

--[[User:Thinker|Thinker]] 20:36, 27 Dec 2005 (CET)
----

== Leftover bits ==

The following data didn't belong where it was posted, and was deleted when the containing section swre moved to [[How to control fan speed]]:

* On my T41 (gentoo-sources-2.6.11.11 ) I noticed that after unloading the fan module the fan noise stopped. With the module loaded the fan was working even at very low cpu temperatures, without the module it's ok so far.

* On a 770X the fan can be fully controlled through ACPI. Thermal Zone THM5 (possibly the battery/charging circuit, it's definitely warmer when using 5v PCMCIA cards and AC) triggers it to turn on and not ever off by design. Can be solved by a custom DSDT, which also makes use of the variable-speed features of the fan (will release this once I've finished tweaking and testing it).

--[[User:Thinker|Thinker]] 20:48, 20 January 2006 (CET)
----

== Embedded controller firmware disassembly ==

[http://forum.thinkpads.com/viewtopic.php?t=20958 This thread] points to, and discusses, a commented (partial) disassembly of the embedded controller. Following this lead, it may be possible to patch the firmware (perhaps transiently) to change the fan level selection algorithm and/or the RPMs.

--[[User:Thinker|Thinker]] 07:10, 24 February 2006 (CET)
----

== R50e with CELERON M: fan for life ==

I am such a loser. I bought a R50e with CELERON M CPU, and thus will
never get longer than 90 seconds of peace before the next 62 to 54
degree fan cycle. --jidanni

== FAN Problem with T42 ==

Hello I have got a T42 and implemented on my gentoo System with a 2.6.15 kernel the fan script. My problem is that I don't know which values I have to set in the fan-control script. My fan ist loudless for only about 5 minutes than the cpu temperature arrives about 50 degree. Another problem ist the combination with the "conservative" govenour. If I use a Software which raises cpu load the script seems to raise up the fan to the maximum for about 2 seconds and then calm it down. This not fine for office work. Do you have some ideas? Another problem is my /proc/acpi/processor/CPU0/throttling, because it never switches the states!
Any help? Thanks for answers

state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%

== Mowing the lawn ==
For the past two days, my thinkpad fan suddenly turned extremely loud - it really sounds like when we'd put playing cards on the spokes of our bikes as kids to make them sound like motorbikes. It's loud enough that I can't take my laptop to the library, and extremely annoying.

We have a new onsite thinkpad repair place here at Harvard, and I took the laptop to them. Unfortunately, the guys wanted me to sign something that said, "If we can't find anything wrong with your computer on hardware diagnostics, then you will pay $45 for a diagnostic fee." I repeatedly told them that any hardware diagnostic scan will show that the system is normal; I think it is a bad bearing or some sort of obstruction of the fan. However, then they switched, "if we find it is within operating decibels for the laptop." Alas, I asked them if they actually have a microphone they hold to the machine, and they really wouldn't answer. We fired up the machine, but their office in the basement of our science center was so loud that it was hard to hear the clanging noise, which really gets going after a few minutes...

Alas, I elected to drop ship the machine to Lenovo / IBM because I felt these guys wouldn't repair / replace the fan. Alternatively, I am thinking of ordering the FRU and just doing it myself, it's around $40, and possibly doing some thermal mods as described in various linked threads.

Thinker, did you ever figure out a way to hardwire the fan to constant rpm perchance?
--[[User:gsmenden|gsmenden]] 18:24, 29 May 2006 (EST)

Update - I received the fan assembly (FRU 26R9074, retail $37.50 USD) and replaced it without any problem. There are a couple places where one could definitely go wrong / damage the laptop, but warnings are pretty clearly outlined in the Hardware Maintenance Manual. All done, for less than the diagnostic fee. You'll need some heatsink grease - I'll put pictures online of the process if I ever get a chance.

I did not bother with any thermal "mods" - I believe that heat transfer is not the problem regarding the fan always on, as described elsewhere in this wiki and fixed (at least partially) by Thinker et al's script.

No wires were contacting my old fan, nor was it excessively dirty. Flicking it to spin with my finger makes the same rattling sound - I think the axis just came off or one of the bearings was bad. Now my laptop is whisper-quiet.

Do NOT get the IBM "Screwdriver kit" for $34. I thought it would be a nice toolset with case, but it is a cheapo set of screwdrivers in a cheapo plastic case, literally available online for $5.95 (the EXACT SAME model!). Go to Fry's, get some nice tools, and then head to your local pub for 6 more screwdrivers with the money you saved. Needless to say, I will return this.
--[[User:gsmenden|gsmenden]] 22:09, 01 Jun 2006 (EST)

Talk:How to hotswap Ultrabay devices

2006-05-31T05:10:15Z

Gsmenden: hotswap works with 2.6.16.19

Talk:Problem with fan noise

2006-05-30T22:38:10Z

Gsmenden: Fan noise again...

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...
----
"Word on the net" is usually synonym to bullshit. The datasheets are available for download at Intel's site, go read them. For the P4, 80C is the absolute maximum limit, and in the newer Pentiums, the chip itself will MCE and enable clock modulation if you try to make it exceed 80C. I didn't read the new Pentium-M's datasheet yet.

Letting the machine run hot is not a good idea, anyway. It shortens its lifespan considerably, especially the harddrive's. Don't play games with this.
----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more safe version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

On my machine this seems to be related to the third temperature in /proc/acpi/ibm/thermal. The fan will be started whenever this value climbs to 46 degrees. It won't be stopped once the value drops to 45, of course. But if you detach/attach AC supply, this somehow resets the control logic and the fan will stop if the value is <=45. Unfortunately, it will quickly increase to 46, and the fan will start again.

The threshold temperature for stopping the fan seems to be 41 degrees, but the fan running at its default speed of ~4500 will only keep it around 44-46.

It would be quite interesting to know where that sensor No. 3 is located on the X41.

--[[User:Robert-qfh|Robert-qfh]] 20:11, 02 Mar 2006 (CET)

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

----

Anybody tried to slow down the fan and have it running at ~1000-1500rpm? That would make it almost silent and you could have it always running (like Apple does on Macs).

--[[User:Micampe|Micampe]] 12:56, 7 Dec 2005 (CET)
----

Goot question. The embedded controller [[patch_for_controlling_fan_speed|interface]] we have discovered allows only for setting a fan level between 0 and 7, not the actual RPM. And IBM has been ramping up the RPM assignment of each fan level (look at the model-specific data there), so that on the T43, even the lowest accessible level is at a pretty fast 3300RPM. The following ''might'' provide a way around this, if the hardware is capable of generating lower speeds:
* Patch the embedded controller firmware. You will need the information in [http://forum.thinkpads.com/viewtopic.php?p=113904#113904 this post] and the following one, a lot of patience, and an active warranty.
* Find out how the embedded controller is setting the speed (maybe by disassembling it as above, but at least you don't need to load patched firmware). Maybe the EC is changing the speed by instructing ''another'' component over an interface (SMBus?) that can also be accessed directly by the CPU. In this case, maybe you can put the embedded controller in disengaged mode and control that component directly.

Then, there's the soldering-iron approach. Assuming the fan uses the standard wiring and that its speed determined by the provided voltage, you can make all speeds somewhat slower simply by putting a resistor in series with the fan. You can do that by splicing one of the wires or, to avoid voiding your warranty, just build an extension cable like this:

fan cable extension
#------- Vfan --------#> >#---~~R~~---#> >#SYSTEM
FAN#------- SENSE -------#> >#-----------#> >#BOARD
#------- GND ---------#> >#-----------#> >#CONNECTOR

Use an appropriate resistor R, and make sure it doesn't get too hot (if it does, attach it to the fan's cooling assembly). Worked nicely for me a few years ago on some desktop motherboard. If you're into that kind of stuff, you can also use fancier electronics instead of the resistor to avoid the (minor) power waste.

It would be useful to have some pictures of the fan cable connector so we can get a matching pair (it's above the rear right corner of the PCMCIA slot, under the palmrest but maybe visible with just the keyboard removed).

--[[User:Thinker|Thinker]] 14:36, 7 Dec 2005 (CET)
----

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

This discussion was moved to [[Talk:Thermal sensors]].

== X21 overacceleration problem ==

On my X21 2662-66U, the fan runs all the time. That's not an issue, because of how hot my laptop runs.

However, at load, it runs really hot. I can hear the fan attempt to accelerate past the maximum speed, click three times, and drop back down to the max. It's not the same as the pulsing problem, yet similar.

New fan, ordered direct from IBM, due to my old fan running WAY too hot, even underclocked. As it is, I'm running underclocked because 95 C at full load is just NOT my cup of tea. 40 C idle temps at 500MHz, around 60 at 700MHz. 70 C load at 500, 95 C load at 700.

== Startup noise ==

My T43 accelerates the fan to very high speed twice during startup: immediately after power-on, and during the bootloader prompt (i.e., after the BIOS but before Linux loads). This is independent of the unit's temperature, and is loud enough to cause some ugly stares when sitting in a lecture. Is this a universal phenomenon, worth mentioning in the article page?

Potential solutions: the first fan acceleration can't be fixed by anything but an EC firmware update. For the second acceleration (after BIOS), a workaround can be implemented by adding basic fan control code (i.e., a few accesses to I/O ports 0x62 and 0x66 as explained in the [[Patch_for_controlling_fan_speed#Hardware_specs|fan control specs]] and Linux's {{path|drivers/acpi/ec.c}}) to the bootloader. GRUB 2 has a module infrastructure that should make this pretty easy, and other boot loaders can also be patched.

--[[User:Thinker|Thinker]] 20:36, 27 Dec 2005 (CET)
----

== Leftover bits ==

The following data didn't belong where it was posted, and was deleted when the containing section swre moved to [[How to control fan speed]]:

* On my T41 (gentoo-sources-2.6.11.11 ) I noticed that after unloading the fan module the fan noise stopped. With the module loaded the fan was working even at very low cpu temperatures, without the module it's ok so far.

* On a 770X the fan can be fully controlled through ACPI. Thermal Zone THM5 (possibly the battery/charging circuit, it's definitely warmer when using 5v PCMCIA cards and AC) triggers it to turn on and not ever off by design. Can be solved by a custom DSDT, which also makes use of the variable-speed features of the fan (will release this once I've finished tweaking and testing it).

--[[User:Thinker|Thinker]] 20:48, 20 January 2006 (CET)
----

== Embedded controller firmware disassembly ==

[http://forum.thinkpads.com/viewtopic.php?t=20958 This thread] points to, and discusses, a commented (partial) disassembly of the embedded controller. Following this lead, it may be possible to patch the firmware (perhaps transiently) to change the fan level selection algorithm and/or the RPMs.

--[[User:Thinker|Thinker]] 07:10, 24 February 2006 (CET)
----

== R50e with CELERON M: fan for life ==

I am such a loser. I bought a R50e with CELERON M CPU, and thus will
never get longer than 90 seconds of peace before the next 62 to 54
degree fan cycle. --jidanni

== FAN Problem with T42 ==

Hello I have got a T42 and implemented on my gentoo System with a 2.6.15 kernel the fan script. My problem is that I don't know which values I have to set in the fan-control script. My fan ist loudless for only about 5 minutes than the cpu temperature arrives about 50 degree. Another problem ist the combination with the "conservative" govenour. If I use a Software which raises cpu load the script seems to raise up the fan to the maximum for about 2 seconds and then calm it down. This not fine for office work. Do you have some ideas? Another problem is my /proc/acpi/processor/CPU0/throttling, because it never switches the states!
Any help? Thanks for answers

state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%

== Mowing the lawn ==
For the past two days, my thinkpad fan suddenly turned extremely loud - it really sounds like when we'd put playing cards on the spokes of our bikes as kids to make them sound like motorbikes. It's loud enough that I can't take my laptop to the library, and extremely annoying.

We have a new onsite thinkpad repair place here at Harvard, and I took the laptop to them. Unfortunately, the guys wanted me to sign something that said, "If we can't find anything wrong with your computer on hardware diagnostics, then you will pay $45 for a diagnostic fee." I repeatedly told them that any hardware diagnostic scan will show that the system is normal; I think it is a bad bearing or some sort of obstruction of the fan. However, then they switched, "if we find it is within operating decibels for the laptop." Alas, I asked them if they actually have a microphone they hold to the machine, and they really wouldn't answer. We fired up the machine, but their office in the basement of our science center was so loud that it was hard to hear the clanging noise, which really gets going after a few minutes...

Alas, I elected to drop ship the machine to Lenovo / IBM because I felt these guys wouldn't repair / replace the fan. Alternatively, I am thinking of ordering the FRU and just doing it myself, it's around $40, and possibly doing some thermal mods as described in various linked threads.

Thinker, did you ever figure out a way to hardwire the fan to constant rpm perchance?
--[[User:gsmenden|gsmenden]] 18:24, 29 May 2006 (EST)

Fglrx

2006-05-25T13:47:13Z

Gsmenden: /* Building for Xorg 7.0 */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a binary-only driver for ATI graphic chips with support for 3D acceleration.
|}

==Availability / Project Homepage==
Home page: https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=356

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}} packages: http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge x11-drivers/ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** Creating and installing a custom RPM for a custom-compiled kernel on {{Fedora}} 4:
::{{cmdroot|yum install ati-fglrx}}
::{{cmdroot|1=VER=8.20.8.1-0.lvn.1.4 # copy version string from output of above command}}
::{{cmdroot|wget http://rpm.livna.org/fedora/4/i386/SRPMS.lvn/ati-fglrx-$VER.src.rpm}}
::{{cmdroot|rpmbuild --rebuild --target $(uname -m) --define "ksrc /lib/modules/$(uname -r)/build" --without userland ati-fglrx-$VER.src.rpm}}
::{{cmdroot|rpm -Uvh --replacepkgs /usr/src/redhat/RPMS/$(uname -m)/kernel-module-fglrx-$(uname -r)-$VER.$(uname -m).rpm}}
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.25.18 (24th May 2006)

Major changes:
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!
{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).
* [http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Installing Version 8.24.8 in Ubuntu] for X1*00 support.

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Fglrx

2006-05-25T09:50:27Z

Gsmenden: /* Status */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a binary-only driver for ATI graphic chips with support for 3D acceleration.
|}

==Availability / Project Homepage==
Home page: https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=356

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}} packages: http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge x11-drivers/ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** Creating and installing a custom RPM for a custom-compiled kernel on {{Fedora}} 4:
::{{cmdroot|yum install ati-fglrx}}
::{{cmdroot|1=VER=8.20.8.1-0.lvn.1.4 # copy version string from output of above command}}
::{{cmdroot|wget http://rpm.livna.org/fedora/4/i386/SRPMS.lvn/ati-fglrx-$VER.src.rpm}}
::{{cmdroot|rpmbuild --rebuild --target $(uname -m) --define "ksrc /lib/modules/$(uname -r)/build" --without userland ati-fglrx-$VER.src.rpm}}
::{{cmdroot|rpm -Uvh --replacepkgs /usr/src/redhat/RPMS/$(uname -m)/kernel-module-fglrx-$(uname -r)-$VER.$(uname -m).rpm}}
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)

== Building for Xorg 7.0==
To compile for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, one needs to move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.25.18 (24th May 2006)

Major changes:
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!
{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open source drivers don't support newer cards, while the ATI drivers don't support older cards.}}

=== Power saving ===
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).
* [http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Installing Version 8.24.8 in Ubuntu] for X1*00 support.

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

How to setup Bluetooth

2006-05-24T05:53:03Z

Gsmenden: /* Serial connection over Bluetooth */

Help talk:Editing

2006-05-24T05:41:45Z

Gsmenden: Better place for this...

In general, what is the prevailing philosophy on removing out of date information? Regarding the fglrx page, a lot of the stuff is regarding historical patches for old driver versions, and really ceases to be useful now. Nevertheless, there is possibly a rare situation where a person constrained to an older kernel / driver for hardware issues would need to reference this stuff. I guess the person could always dig through the diffs to find out what has happened in the past.

I think a moderate pruning approach is best, where really arcane / historical issues are simply deleted, and anything a user might realistically run into can be briefly summarized...

--[[User:gsmenden|gsmenden]] 24 May 2006 01:16 (EST)

Talk:Issues with the Wiki

2006-05-24T05:41:26Z

Gsmenden:

Talk:Issues with the Wiki

2006-05-24T05:29:20Z

Gsmenden: Maintenance of the wikiwiki

Problems with fglrx

2006-05-24T05:23:16Z

Gsmenden: /* Kernel-specific troubles */

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

== Known Troubles and Solutions ==

=== X-specific issues ===

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.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|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 {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=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 {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|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 <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/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 [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

=== 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 {{cmduser|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
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|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 <tt>mesa.bkup</tt>, 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:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|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:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# 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
</pre>

=== 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 <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=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 [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.

{| cellspacing="0" cellpadding="2" border="1"
|+ 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html 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 [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 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||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 2.6.15]||8.22.5||suspend2 2.2||yes||without vbetool or UseDummyXServer, with DRI enabled
|}

=== 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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|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 <tt>vesa</tt> 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.24.8).

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 7.0 (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: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
AlwaysRestartServer=true

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

Another reason of hardlock my be agp driver. Make sure that you have proper driver for your motherboard loaded before fglrx: (gentoo: {{path|/etc/modules.autoload.d/kernel-2.6}}):
intel-agp
fglrx

Information from gentoo bugtracker: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Error messages in system log===

If you find something like the following in {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

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

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 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

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]

User:Gsmenden

2006-05-24T05:15:57Z

Gsmenden: System/user profile

My system:
T43p running Debian unstable

Kernel: 2.6.16.17
Patches: CPU Undervolt
CPU: Pentium 4M undervolted (1196, 1052, 956, 860, 780, 700) -> no CPU errors, but this is about the limit that I can go.

Video: fglrx 8.24.8 <- when is this darn thing going to support composite? Xorg 7.1 supports it...

----------

Other tweaks:

Thinker et. al.'s custom fan control daemon
Enabled special keys, etc.

Other notes:

Gnome or KDE? KDE. I know this is subjects of constant flame-waring, but Gnome's file picker bugs the heck out of me, and I just simply can't stand some of the UI design choices they made and correlated lack of customizability. KDE is extremely pretty, and the QT licensing issues of the past are now resolved.

Firefox or IE? Come on, really...
APM or ACPI? No, really, come on.
Alsa or OSS? I mean it, stop now.

Java or C++? Uhh... C. I really must become more proficient in C++.

Gentoo or Debian? Debian for now, but keep in mind I ran slackware until 2002 (eventually got fed up with lack of releases and package management.) I am keeping a close eye on Gentoo though, as I do apprciate custom compilation. However, one can always do this with Debian too, with a small bit of effort. Debian's release schedule (even for sid) is also a tad slow...

Suspend or suspend2? I just use the built-in 2.6 kernel suspend -- I don't need encryption or any other fancy stuff.

Blondes or brunettes? Never dated a blonde, so I wouldn't know yet. There is always hope! :)

Talk:How to hotswap Ultrabay devices

2006-05-23T19:43:11Z

Gsmenden: