ThinkWiki - User contributions [en]

Problems with fglrx

2006-12-26T14:15:01Z

Felixdv: /* Added my thinkpad T60 as a working configuration */

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

=== 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 (/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: http://bugs.gentoo.org/show_bug.cgi?id=113685

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

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.

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

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

Problem with high pitch noises

2006-12-26T13:59:38Z

Felixdv: /* Added T60 to list of thinkpads where the C2 state was needed to get rid of the noise */

Information on strange high pitch, low volume noises emitted by ThinkPads.

==Problem description==
Even though ThinkPads are known as very silent notebooks, they tend to emit different, mostly high pitch noises in certain circumstances. The noises are of low volume and hence not realized by everyone or at least tolerated by most people. However, there are those with "bat like ears" that hear them and might be annoyed by that.

==Affected Models==
Noises have been experienced in the following situations:
{| border="1" cellspacing="0" cellpadding="2"
|-
! style="vertical-align:top;background-color:#DDDDDD;" | situation
! style="vertical-align:top;background-color:#DDDDDD;" | noise description
! style="vertical-align:top;background-color:#DDDDDD;" | affected models
|-
| style="vertical-align:top;" |
Plugged into AC / running at high CPU frequency
| style="vertical-align:top;" |
soft crackling, buzzing noise
| style="vertical-align:top;" |
*{{T41}}
**2379-DJU
|-
| style="vertical-align:top;" |
ThinkPad suspended to RAM
| style="vertical-align:top;" |
constant high pitch noise
| style="vertical-align:top;" |
*{{T42p}}
|-
| style="vertical-align:top;" |
ThinkPad connected to power and switched off, with battery fully charged
| style="vertical-align:top;" |
constant high pitch noise
| style="vertical-align:top;" |
*{{T41p}}
**2373-GHG
|-
| style="vertical-align:top;" |
moving windows or just the mouse in xorg
| style="vertical-align:top;" |
strange noise like a rapid series of very short high pitch noises adding to a constant kind of whistling (only as long as the movement goes)
| style="vertical-align:top;" |
*{{T41p}}
**2373-GHG
|-
| style="vertical-align:top;" |
Thinkpad connected to power or working on battery, also when suspended to RAM
| style="vertical-align:top;" |
High pitch noise also when HD is powered down.
| style="vertical-align:top;" |
*{{T23}}
**2647-DG4
*{{X24}}
**2662-MWG
|-
| style="vertical-align:top;" |
Thinkpad connected to power battery charged less than 60%
| style="vertical-align:top;" |
High pitch noise till battery is charged more than 60%.
| style="vertical-align:top;" |
*{{T41p}}
**2373-GEG
|-
| style="vertical-align:top;" |
Constantly, if AC connected
| style="vertical-align:top;" |
High pitched, low volume constant noise.
| style="vertical-align:top;" |
*{{T40}}
**2373-88U
|-
| style="vertical-align:top;" |
When the CPU freq jumps up to 1Ghz or above, or when the laptop is in suspend mode
| style="vertical-align:top;" |
Constant high pitched
| style="vertical-align:top;" |
*{{R50}}
**1829-6DM
|-
| style="vertical-align:top;" |
(May come from harddisk.)
| style="vertical-align:top;" |
continuous, intermittent, low volume, high pitched
| style="vertical-align:top;" |
*{{600X}}
|-
| style="vertical-align:top;" |
ACPI puts the processor into the C3 or C4 power saving states (i.e., the system is idle).
| style="vertical-align:top;" |
High-pitched crackling noise.
| style="vertical-align:top;" |
*{{X41}}
*{{T43}}
**2686-DGU
*{{T43p}}
*{{T60}}
**2007-72U
*{{T21}}
*{{T20}}
**2648-46U
|-
| style="vertical-align:top;" |
Cpufreqd (or powernowd etc.) slows down the processor, for exemple at the end of an heavy task.
| style="vertical-align:top;" |
High-pitched crackling noise.
| style="vertical-align:top;" |
*{{T42}}
|-
| style="vertical-align:top;" |
When on battery
| style="vertical-align:top;" |
Noise level varies from inaudible to clearly audible, screeching sound, or sometimes beeping (when wifi is on)
| style="vertical-align:top;" |
*{{R52}}
**1858-A11
*{{T43}}
**2686-DGU
**1871-4AG
*{{T60}}
**2007-72U
*{{x60}}
*{{x31}}
**2673-CBU
*{{Z61m}}
**9450-3HG
*{{Z61t}}
**9440-2QU

|-
| CPU is used much AND laptop is on AC power AND the TFT panel is enabled.
| Screetching high pitch noise, like a million crickets
|
* {{X41}}

|-
| Network is pluged in and networkload is ~100%.
| low volume highfreq. pitch noise from left speaker or cpu.
|
*{{Z60m}}, {{Z60t}}
*{{T40}}
*{{T43}}
**2687-DDU
|}

==Affected Operating Systems==
All, though Linux appears especially susceptible.

==Possible sources==

* '''CPU activity:''' On some models the noise is triggered by certain CPU power states or activity patterns (as proven [http://www.wisdom.weizmann.ac.il/~tromer/acoustic here]).
* '''Graphics processor:''' In some models from the T2x era, e.g. the {{T23}}, the problem was related to the graphics circuitry and occured especially or only while making use of DirectDraw functions. IBM was able to fix it through a BIOS upgrade.
* '''Hard disk:''' On some ThinkPads the processor and hard disk are adjacent and produce similar noise. For example, in the {{X41}} the sound generated by the hard disk is likely to be loudest at the vent.
* '''Gigabit Ethernet processor:''' In some models (e.g., {{T43}}) high ethernet activity causes a high pitch noise.

* '''Screen brightness:''' on an {{X31}}, a hissing sound is started whenever screen brightness is not full.

==Status==

The problem is highly specific to operating system, model and even individual machines. There is no universal solution, but on most machines one of the following will reduce or eliminate the noise (possibly at some cost in power consumption).

==Solutions for CPU-triggered noise==

===Limit ACPI CPU power states===

There are four ACPI CPU power states, called C1 through C4. Often only the extreme power saving modes C4 or C3 produce the noise, so the noise can be stopped by insructing the Linux ACPI code to use only lower modes.

To forbid the ACPI driver from using C4 (this fixed the problem with on some ThinkPad {{T43}}, {{T43p}} and {{T41}}):
* If the ACPI processor component is compiled as built-in (<tt>CONFIG_ACPI_PROCESSOR=y</tt>):
**Pass the {{bootparm|max_cstate|3}} kernel argument.
* If the ACPI processor component is loaded as a module (<tt>CONFIG_ACPI_PROCESSOR=m</tt> and <tt>processor</tt> shows in the output of {{cmdroot|lsmod}}), do either of:
** Pass the {{bootparm|processor.max_cstate|3}} kernel argument (this does not work in Ubuntu 5.10 with default kernel).
** Add <code>options processor max_cstate=3</code> to {{path|/etc/modprobe.conf}} (or {{path|/etc/modprobe.conf.local}}, or {{path|/etc/modprobe.d/...}}, depending on your system) (this does not work in Ubuntu 5.10 with default kernel).
** {{cmdroot|echo 3 > /sys/module/processor/parameters/max_cstate}} (this can be changed in runtime for experimentation). (If may need to be set again upon resume from suspend, e.g., in the wakeup script.)
** (On Ubuntu 5.10, the default kernel uses <code>processor</code> as a module. Unfortunately, the script loading it, {{path|/etc/init.d/acpid}}, ignores the <code>options processor max_cstate=3</code> setting in {{path|/etc/modprobe.d/<my file>}}. As a solution for this specific problem, add the line <code>echo 2 > /sys/module/processor/parameters/max_cstate</code> directly to {{path|/etc/init.d/acpid}}, at the end of the function <code>load_modules()</code>, immediately after the line <code>echo "$PRINTK" > /proc/sys/kernel/printk</code>.)
** On Gentoo: Configure your Thinkpad as described in the [http://www.gentoo.org/doc/en/power-management-guide.xml Power Management Guide]. Then as root create the files {{path|/etc/init.d/limit-sleep-states}} and {{path|/etc/conf.d/limit-sleep-states}} as below. After that just issue the command {{cmdroot|rc-update add limit-sleep-states default}} to limit the sleep states only when running on AC power, or {{cmdroot|rc-update add limit-sleep-states default battery}} to always limit the sleep states.
cat <<EOF > /etc/init.d/limit-sleep-states
#!/sbin/runscript

depend() {
need acpid
}

start() {
ebegin "Limiting CPU sleep state to C${LIMIT_CSTATE}"
echo $LIMIT_CSTATE > /sys/module/processor/parameters/max_cstate
eend $?
}

stop() {
ebegin "Removing CPU sleep state limit"
echo $REMOVE_CSTATE > /sys/module/processor/parameters/max_cstate
eend $?
}
EOF

cat <<EOF > /etc/conf.d/limit-sleep-states
# limit CPU sleep state to the following value (adjust accordingly)
LIMIT_CSTATE=3
# some value which is higher than all available sleep states
REMOVE_CSTATE=8
EOF

To also forbid the C3 state, replace "<tt>3</tt>" with "<tt>2</tt>" above (this fixed the problem on some ThinkPad {{X40}}, {{X41}}, {{X60}}, {{T60}}, {{Z61t}} and {{R52}}, as well as on {{T20}} where C4 is not supported at all):

Note that these options affect power consumption when the CPU is idle. For example, here is the [[How to measure power consumption|measured power consumption]] on a ThinkPad {{T43}}:
* {{bootparm|processor.max_cstate|4}}: 15160mW (default, noisy)
* {{bootparm|processor.max_cstate|3}}: 15770mW (660mW higher, silent)
* {{bootparm|processor.max_cstate|2}}: 16100mW (2940mW higher, silent)

See the [http://thinkwiki.org/wiki?title=Talk:Problem_with_high_pitch_noises discussion page] for further information and success reports.

*Jakob Schou Pedersen: Editing the file {{path|/etc/init.d/acpid}} as described above (the last solution) worked on my T43 :-)

===Turn off CPU power saving in in BIOS===

Go into the BIOS and turn off the power saving processor feature that puts it into idle mode. (This worked on a ThinkPad {{T43}}, {{T21}}, {{X60s}} and {{Z61m}}). However, this also affects power consumption when the CPU is idle, it's similar to disabling the C4/C3 ACPI CPU power state. For example, on a Z61m 9450-3HG, a full charged battery with power management enabled in the BIOS provides the notebook with power for about 3.5h, if disabled, the battery-lifetime is only about 2h.

===Disable ACPI CPU power states===

Completely disable CPU ACPI power states. Discussion:

*From Martin Steigerwald: I made the observation that I get at least less high pitch noises on my {{T23}} when I do not use the two ACPI modules "processor" and "thermal" (depends on the first one). I have no clue, why. Anyone with similar experiences?
:Omar Yasin: I've got a {{R52}} and when I load the same ACPIO modules the high pitch noises are not as loud but I can still hear them.
*Niko Ehrenfeuchter: I'm experiencing the same here on my {{X24}}. Removing the "processor" module also stops the pitch noise, which does ONLY occur when setting the CPU to maximum speed (using cpufreq). On low speed it's completely silent, even having loaded the processor module.

*Rolf Adelsberger: I can confirm this: the high pitch noise is only remarkable (at least with my ears ;-) ) if the processor speed is set to maximum frequency.

*Stefan Baums: My {{X41}} produced a high-pitched crackle from the processor vent on the left. Changing HZ did nothing, and the 'processor' module could not easily be removed from the system (Ubuntu 5.04). What solved the problem for me was adding {{bootparm|idle|halt}} to the boot command line. Unfortunately, this solution only lasts until the first hibernation or suspend - when the computer ({{X41}}) resumes, the high-pitched crackle is back.

* The {{bootparm|idle|halt}} solution combined with setting <code>#define HZ 100</code> in the kernel fixes the problem on a {{T43}}.

* jhatch: {{bootparm|idle|halt}} plus <code>#define HZ 100</code> also worked on my {{T43}}. It still reverts back to noisy after a suspend/resume though. This needs to be fixed...

===Change the timer interrupt frequency===

Change the "HZ" kernel constants to alter the frequency of timer interrupts. Discussion:

{{NOTE|The timer interrupt frequency (HZ) in current Linux kernels is directly tied to the kernel task scheduler. Lower frequencies provide larger time-slices and thus also higher latencies (which may kill latency-sensitive applications like audio processing). 100Hz ended up as the recommended "server" setting (because it increases disk/CPU throughput in a latency-insensitive environment). Higher frequencies are better for latency-sensitive applications, and improve desktop responsivity at the cost of less processor throughput. 1000Hz ended up as the recommended "desktop" setting.}}

*Andreas Karnahl: i've read in several forums it has something to do with the "idle"-state (or "C3") of the processor. There is a frequency called "timer interrupt" (or so mething like that). Since kernel 2.6x it is set to 1000 Hz by default (compared to 100 Hz in Kernel 2.4x). The exact reason i don't know, but it is safe to change this frequency to 100 Hz in kernel 2.6x (by the way, windows up to XP uses 100 Hz by default). Just do the following: 
: In {{path|[path to kernel-sources]/include/asm-i386/param.h}} find the line
:: <code>#define HZ 1000</code>
: and change the value of HZ to 100:
:: <code>#define HZ 100</code>
:Then recompile the kernel. After i changed it on my ThinkPad {{A30}} (under SuSE 9.2 and 9.3) and recompiling the kernel the high pitch noise is gone away.

* Omar Yasin: Worked on my {{R52}}, thanks.

* [[User:Thinker|Thinker]]: In modern kernels this constant is in the kernel configuration {{kernelconf|CONFIG_HZ|Processor type and features||Timer Frequency|||||}}.

===Prevent idling===

Indirectly avoid power saving states by making sure the CPU is rarely idle:

* Paul RIVIER: Here is a really simple workaround. C3 / C4 states are mainly called when the cpu freq is higher than required, for example if your cpufreqd is lazy to slow down the frequency but quick to raise it. That is why I use powernowd with the builtin "passive" mode, which is lazy for raising frequency, but quick to go back to the lowest. Now I don't hear them as often as before, as I avoid C3/C4 states at high frequency.

* The problem also occurs on my {{X41}} with 2.6.11. Setting up [[How to make use of Dynamic Frequency Scaling|frequency scaling]] with the <code>ondemand</code> governor makes things a lot better, as the processor does not stay with the maximum frequency when in idle mode. It can be still heard sometimes, though.

* On a {{T43}} the noise was gone after dropping cpufreqd and switching to the ondemand governor - maybe because of the high sampling rate? (used the default: 10ms)

===Change the processor voltage===

Reducing the processor voltage (when possible) may decrease or eliminate the noise. On one ThinkPad {{T43}}, [[Pentium M undervolting and underclocking|undervolting the Pentium M processor]] eliminated the high-pitched noise. Compared to the other solutions this has the benefit of lower power consumption, both due to the undervolting itself and because there is no need to forbid high APCI CPU power saving modes.

==Solutions for screen brightness related sounds==

===Disable BIOS brightness control===

The sound starts when on batteries as the BIOS automatically reduces screen brightness. To disable this, simply switch Config>Display>Brightness from
Normal to High. See also [[User:Piccobello/Hissing sound on battery|here]].

==Other solutions==

===Disable UltraBay===
*Naheed Vora: My {{T41}} (2373-268) started to give high pitch noise ocassionally, when I upgraded to 2.6.11 kernel. I tried to unload lot of modules but finally figured out that disabling bay stops the noise. If you have [[ibm-acpi]], do (need a cleaner solution): {{cmduser|echo eject >/proc/acpi/ibm/bay}} .

===Disable IrDA===
*Mike Perry: I was able to cure an intermittent high-pitched whine on both my {{X24}} and {{X40}} by disabling the Infrared port.

===Disable the Linuxant Modem Driver===
*Joern Heissler: I made another experience. I played around with linuxant conexant [[Modem Devices|modem]] drivers. After loading them I got some noise on my {{T42p}}.

===Media Player paused===
*Eilif Muller: On my {{R52}} the high-pitched noises go away if I load XMMS, play something then pause it.
*Jacob: On my {{T43}} DGU it goes away if I open mplayerc.exe and press play then pause it. This is the high-pitched noise that only shows up when I'm on battery.

''I'd guess that the above tip works as when xmms or similar is running, it is uncompressing compressed audio/video, which is a processor intensive action. Keeping this paused means that the app won't 'let go' of the processor, forcing it to stay up and running, which stops it entering the higher powersave modes.''

===Upgrade BIOS===
On a ThinkPad [[X60s]], [[BIOS_Upgrade|upgrading the BIOS]] to version 1.06 eliminated the high pitch noise when running on battery.

===Disable USB===
On one {{T43}} and one {{X60}}, (partially) disabling USB using {{cmdroot|rmmod uhci_hcd}} significantly reduced the noise.