ThinkWiki - User contributions [en]

Fan control scripts

2007-11-06T17:02:57Z

Theclaw: /* Comprehensive <tt>bash</tt> script with fine control over fan speed */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page provides several scripts for controlling the ThinkPad's system fan according the its [[thermal sensors]] (overriding the embedded controller), in order to reduce [[problem with fan noise|fan noise]] and decrease [[how to reduce power consumption|power consumption]].

{{WARN|These scripts rely on undocumented hardware features and override nominal hardware behavior. They may thus cause arbitrary damage to your laptop or data. Watch your temperatures!}}
|}

==Variable speed control scripts==
The following scripts sets the fan speed according to the system's [[thermal sensors]]. In addition, they include a hack for preventing the annoying fan pulsing that occurs on some systems. Note that the fan levels, thresholds and anti-pulsing hacks are system-specific, so you may need to adjust them.

===Comprehensive <tt>bash</tt> script with fine control over fan speed===
This script works with any recent Linux kernel (2.6.14 and higher). It requires the [[ibm-acpi]] module to be loaded with the <tt>experimental=1</tt> module parameter (e.g., {{cmdroot|1=modprobe ibm_acpi experimental=1}}).

In Linux 2.6.22 and higher you need to additionally pass fan_control=1 to the module thinkpad_acpi (e.g., {{cmdroot|1=modprobe thinkpad-acpi experimental=1 fan_control=1}})

The code lets you define a temperature range for each [[thermal sensors|thermal sensor]]. The script computes the fan level needed by each sensor based on the configured range, and then sets the the actual fan level to the slowest that will satisfy all sensors (plus some hysteresis to avoid fluctiations). It also includes a workaround for the [[Problem with fan noise|pulsing noise]] problem. The scipt provides an (optional) daemon mode and logging to syslog. The method of controlling fan speed is documented [[How to control fan speed|here]].

The system hard disk temperature is monitored as well, using the hard disk's internal sensor. This works only on certain Hitachi disks and requires kernel >= 2.6.19-rc1 or the ide driver, since it uses a [[Thermal Sensors#Hitachi_harddisks_SENSE_CONDITION_temperature_sensor|non-standard method]] for reading the temperature without causing a head unload or spinup.

The code:
* {{CodeRef|tp-fancontrol}}

Current options:

Usage: ./tp-fancontrol [OPTION]...

Available options:
-s N Shift up the min temperature thresholds by N degrees
(positive for quieter, negative for cooler).
Max temperature thresholds are not affected.
-S N Shift up the max temperature thresholds by N degrees
(positive for quieter, negative for cooler). DANGEROUS.
-t Test mode
-q Quiet mode
-d Daemon mode, go into background (implies -q)
-l Log to syslog
-k Kill already-running daemon
-u Tell already-running daemon that the system is being suspended
-p Pid file location for daemon mode
{{WARN|The list of temperature ranges used in this script is much more liberal than the rules used by the embedded controller firmware, and is derived mostly from anecdotal evidence, hunches and wishful thinking. It is also model-specific - see [[thermal sensors]].}}

====init script for the comprehensive script====

This is optional. It assumes that the above <tt>tp-fancontrol</tt> script is saved at {{path|/usr/bin/tp-fancontrol}}.
* Init script: {{CodeRef|tp-fancontrol.init}} (save as {{path|/etc/init.d/tp-fancontrol}})
* Init script (Debian): {{CodeRef|tp-fancontrol.init.debian}} (save as {{path|/etc/init.d/tp-fancontrol}})
* Configuration file for init script: {{CodeRef|tp-fancontrol.conf}} (save as {{path|/etc/tp-fancontrol.conf}})

===Simple <tt>bash</tt> script with fine control over fan speed (requires kernel patch)===
The following is a simpler patch (without extra features like daemon mode and logging). It requires the [[patch for controlling fan speed]] or a recent kernel (>=2.6.19).

{{CodeRef|tp-fancontrol-basic}}

===tp-fan: Automatic daemon with GTK+ GUI===
Provides easy setup and monitoring through graphical GTK+ interface. Temperature thresholds cannot be set separately for each sensor.

At the moment it is only tested on Ubuntu Gutsy Gibbon. However, porting to other distributions or manual setup should be easy.

* Home page: http://www.gambitchess.org/moin.py/tpfan

==Fan enable/disable scripts==
The following scripts were written before it was known [[patch for controlling fan speed|how to control the fan speed]], so they only toggle between fan disabled and default (noisy) fan behavior. In some models, they also do not monitor all available [[thermal sensors]].

===<tt>sh</tt> script example===
{{CodeRef|fan-enable-basic}}

===<tt>sh</tt> script with more features===
{{CodeRef|fan-enable-extended}}

===<tt>sh</tt> script with extra safety functionality===
ibm_acpi usually works well. But to rely on it completely, this script provides some extra safety functionality:
# It catches various signals and turns the fan on before it quits.
# It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

{{CodeRef|fan-enable-safe}}

==Init scripts==

===Init script example===

{{CodeRef|fan-enable.init}}

===Init script example for gentoo===
Assume one of the above control scripts is {{path|/usr/sbin/ibm-fancontrold}}, for gentoo use the following init script in /etc/init.d/ibm-fancontrol.
Copy the script to {{path|/etc/init.d/ibm-fancontrol}}, then do

# rc-update add ibm-fancontrol default

This will add the init script to the default runlevel.

{{CodeRef|ibm-fancontrol.init}}

===Init script example for rh/fedora===
Assume one of the above control scripts is {{path|/sbin/tp-fancontrold}},
copy the script to {{path|/etc/init.d/tp-fancontrol}}, then do

# chkconfig --add tp-fancontrol

This will add the init script to the default runlevel.

{{CodeRef|tp-fancontrol-fc.init}}

You'd have to install also "kernel-module-ibm-acpi" package.

==Other==

===fanctrld===
[http://log.does-not-exist.org/archives/2005/08/13/2043_t_43_fan_control_daemon.html fanctrld] is a daemon (written in C) that controls the Thinkpad's fan. The basic approach is to monitor both temperature and fan speed. The fan is enabled when a certain temperature is exceeded, and disabled when the BIOS slows down the fan below a certain speed.

==Ideas for improvement==
* Use the [[HDAPS]] sensor to automatically lower the temperature thresholds when the laptop is moving. Prolonged movement usually happens when the laptop is on the user's lap (see [[Problem with hot surfaces]] for implications), or when in a moving vehicle where fan noise is typically overshadowed by vehicle noise.
* Use a [http://en.wikipedia.org/wiki/PID_controller PID controller] feedback loop instead of simple thresholds.
* Monitor the UltraBay disk temperature too.

==See also==
* [[How to control fan speed]]
* Shimodax's ThinkPad fan control tool for a Windows offers functionality similar to these scripts; see the [http://forum.thinkpads.com/viewtopic.php?t=17715 forum discussion] at thinkpads.com.
* Yury Polyanskiy has a [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030697.html kernel patch] for automatic fan control in kernelspace (only enable/disable based on maximum temperature).

[[Category:Scripts]]

Problems with fglrx

2007-07-08T17:51:15Z

Theclaw: added xv-bug

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.<br>
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}.<br>
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.<br>
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
|-
|{{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 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 <br>
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

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

Problems with hwclock

2007-04-16T20:21:20Z

Theclaw: /* Possible solutions */

This page discusses the problem with /dev/rtc on certain models.

== Problem description ==
On bootup,a message like this shows up:

<pre>select() to /dev/rtc to wait for clock tick timed out</pre>

The RTC kernel driver can't handle the system clock.

== Possible solutions ==

=== Using the --directisa switch of hwclock(8) ===
The '''hwclock''' command knows the parameter ''--directisa'' to access the system clock "directly" instead of accessing it by using /dev/rtc. There are several ways of doing this automatically. One is to move /sbin/hwclock (or whereever it is located on your system) to '''/sbin/hwclock.dist''' and create the following shell script, which you place at /sbin/hwclock

<pre>#!/bin/sh
/sbin/hwclock.dist --directisa $*</pre>
Make the script executable (apply the same permissions you had for ''hwclock'' before) and keep your packaging system from overwriting it on updates.

Another way of doing this is editing the initscript of hwclock (e.g., /etc/init.d/hwclock.sh in Debian) so that "--directisa" is passed as a parameter

=== Compiling RTC-support into the kernel instead of as a module ===

Compiling RTC-support (CONFIG_RTC) into the kernel instead of compiling it as a module seems to work also. Tested on: 2.6.20.6 at Thinkpad {{Z61m}} 9450-3HG

== Affected Models ==

*Thinkpad {{T60}}
*Thinkpad {{T60p}}
*Thinkpad {{X60s}}
*Thinkpad {{Z61m}}

== Affected Operating Systems ==

*Linux, all flavours. Tested with kernel 2.6.18, 2.6.19, 2.6.20.6

Problems with hwclock

2007-04-16T20:03:43Z

Theclaw:

Problem with high pitch noises

2007-02-19T11:59:56Z

Theclaw: /* Affected Models */

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;" |
*{{R51}}
**EHG-1829
*{{R52}}
**1858-A11
**1846-B5G
*{{R60}}
**9461-DXG
**9462-77G
**9456-HTG
**9461-DXG
*{{R60e}}
**0657-A9G
**0657-3LG
*{{T43}}
**2686-DGU
**1871-4AG
*{{T60}}
**2007-72U
**1951-24G
**1951-24G
**2007-49G
**2007-FUG
*{{T60p}}
**2007-FBG
*{{x60}}
*{{x31}}
**2673-CBU
*{{Z61m}}
**9450-3HG
**9452-128
**9452-W5Q
*{{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 eight ACPI CPU power states, called C1 through C8 (but the ThinkPad BIOS often remaps them and uses only C1 to C4). Often only the extreme power saving modes C4 or C3 produce the noise, so the noise can be stopped by instructing 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)

One can control how often Linux tries to enter the C3 state by using the {{bootparm|processor.bm_history|<bitmask>}} parameter on kernels with a scheduler frequency below 800Hz (and if you have noise problems, you really should not be running the kernel at 1000Hz...). Setting {{bootparm|processor.bm_history|0xFFFFFFFF}} will cause C3 to be entered less often. This will waste more power as the CPU won't do C3 or C4 as often, but at least it doesn't forbid C3 and C4 permanently, unlike {{bootparm|max_cstate|2}}.

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 the 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.
*Kaspar Schleiser: On my {{T23}} the noise is less loud when setting max_cstate to 2, but to completely silence it, I have to set it to "1". Is that the same as removing the "processor"-module? "cat /proc/acpi/battery/BAT0/state" does not show increased power drain.
*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).<br />Just do the following:<br />
: 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.<br />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.''

===nice yes===

Run the command:
{{cmduser|nice yes > /dev/null}}.

This is a good way to test whether the processor is causing the interference, since it forces the CPU to stay at full power. Of course, this will make your system get warm, and probably turn on the fan, as well as eating power.

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

This is likely a CPU-induced noise case, as disabling USB UHCI will reduce a lot the amount of busmaster activity while the computer is idle, and thus has a direct effect on the need for ACPI C-state transitions from C3/C4 to C2 or lower states in a {{T43}} or {{X60}}.

Problem with high pitch noises

2007-02-17T14:37:26Z

Theclaw: /* Affected Models */

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;" |
*{{R51}}
**EHG-1829
*{{R52}}
**1858-A11
**1846-B5G
*{R60}
**9461-DXG
**9462-77G
**9456-HTG
**9461-DXG
*{{R60e}}
**0657-A9G
**0657-3LG
*{{T43}}
**2686-DGU
**1871-4AG
*{{T60}}
**2007-72U
**1951-24G
**1951-24G
**2007-49G
**2007-FUG
*{{T60p}}
**2007-FBG
*{{x60}}
*{{x31}}
**2673-CBU
*{{Z61m}}
**9450-3HG
**9452-128
**9452-W5Q
*{{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 eight ACPI CPU power states, called C1 through C8 (but the ThinkPad BIOS often remaps them and uses only C1 to C4). Often only the extreme power saving modes C4 or C3 produce the noise, so the noise can be stopped by instructing 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)

One can control how often Linux tries to enter the C3 state by using the {{bootparm|processor.bm_history|<bitmask>}} parameter on kernels with a scheduler frequency below 800Hz (and if you have noise problems, you really should not be running the kernel at 1000Hz...). Setting {{bootparm|processor.bm_history|0xFFFFFFFF}} will cause C3 to be entered less often. This will waste more power as the CPU won't do C3 or C4 as often, but at least it doesn't forbid C3 and C4 permanently, unlike {{bootparm|max_cstate|2}}.

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 the 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.
*Kaspar Schleiser: On my {{T23}} the noise is less loud when setting max_cstate to 2, but to completely silence it, I have to set it to "1". Is that the same as removing the "processor"-module? "cat /proc/acpi/battery/BAT0/state" does not show increased power drain.
*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).<br />Just do the following:<br />
: 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.<br />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.''

===nice yes===

Run the command:
{{cmduser|nice yes > /dev/null}}.

This is a good way to test whether the processor is causing the interference, since it forces the CPU to stay at full power. Of course, this will make your system get warm, and probably turn on the fan, as well as eating power.

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

This is likely a CPU-induced noise case, as disabling USB UHCI will reduce a lot the amount of busmaster activity while the computer is idle, and thus has a direct effect on the need for ACPI C-state transitions from C3/C4 to C2 or lower states in a {{T43}} or {{X60}}.

Problem with high pitch noises

2007-02-17T14:36:53Z

Theclaw: /* Affected Models */ see http://thinkpad-forum.de//thread.php?threadid=11164

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;" |
*{{R51}}
**EHG-1829
*{{R52}}
**1858-A11
**1846-B5G
*{R60}
**9461-DXG
**9462-77G
**9456-HTG
**9461-DXG
*{R60e}
**0657-A9G
**0657-3LG
*{{T43}}
**2686-DGU
**1871-4AG
*{{T60}}
**2007-72U
**1951-24G
**1951-24G
**2007-49G
**2007-FUG
*{{T60p}
**2007-FBG
*{{x60}}
*{{x31}}
**2673-CBU
*{{Z61m}}
**9450-3HG
**9452-128
**9452-W5Q
*{{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 eight ACPI CPU power states, called C1 through C8 (but the ThinkPad BIOS often remaps them and uses only C1 to C4). Often only the extreme power saving modes C4 or C3 produce the noise, so the noise can be stopped by instructing 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)

One can control how often Linux tries to enter the C3 state by using the {{bootparm|processor.bm_history|<bitmask>}} parameter on kernels with a scheduler frequency below 800Hz (and if you have noise problems, you really should not be running the kernel at 1000Hz...). Setting {{bootparm|processor.bm_history|0xFFFFFFFF}} will cause C3 to be entered less often. This will waste more power as the CPU won't do C3 or C4 as often, but at least it doesn't forbid C3 and C4 permanently, unlike {{bootparm|max_cstate|2}}.

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 the 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.
*Kaspar Schleiser: On my {{T23}} the noise is less loud when setting max_cstate to 2, but to completely silence it, I have to set it to "1". Is that the same as removing the "processor"-module? "cat /proc/acpi/battery/BAT0/state" does not show increased power drain.
*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).<br />Just do the following:<br />
: 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.<br />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.''

===nice yes===

Run the command:
{{cmduser|nice yes > /dev/null}}.

This is a good way to test whether the processor is causing the interference, since it forces the CPU to stay at full power. Of course, this will make your system get warm, and probably turn on the fan, as well as eating power.

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

This is likely a CPU-induced noise case, as disabling USB UHCI will reduce a lot the amount of busmaster activity while the computer is idle, and thus has a direct effect on the need for ACPI C-state transitions from C3/C4 to C2 or lower states in a {{T43}} or {{X60}}.

Rescue and Recovery

2007-01-06T21:25:31Z

Theclaw: /* MBR written by GRUB */ didn't work here, don't know the exact error message of grub

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
===Rescue and Recovery===
Rescue and Recovery version 3.0 consists of a bootable partition containing various system recovery tools, including full recovery of the preinstalled Windows XP partition. It can be activated by pressing the {{ibmkey|ThinkPad|#494949}}, {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkVantage|#495988}} [[ThinkPad Button|Button]] during system boot. It contains a FAT filesystem (labeled "IBM_SERVICE"), and has partition type 0x12 ("Compaq diagnostics" in <tt>fdisk</tt>).

As opposed to a [[Hidden Protected Area|Hidden Protected Area]] Recovery partitions are ordinary partitions, accessible through the partition table. As they are ordinary partitions they are accessible by ordinary partitioning tools. They should be dealt carefully with.
</div>
|}
==Proper MBR==
{{WARN|Only tinker with the MBR and the Rescue and Recovery partition if you know what you're doing. Mistakes can leave the system unbootable and can make it very difficult to retrieve the data on the harddisk.}}

Consideration 6 of the Readme states:
<blockquote>"The Master Boot Record (MBR) must be configured properly for the Rescue and Recovery application to function properly. When possible, the Rescue and Recovery application attempts to ensure the proper configuration of the MBR. This can only occur if the Rescue and Recovery application is installed after other applications that requires the MBR."</blockquote>

Apparently, the MBR is not "configured properly" if LILO or GRUB have written it. The following is the case:
*The default bootloader seems to ignore the active bit and always boots the first partition instead
*The default bootloader contains code to catch a press of the appropriate button during bootup and launch the Rescue and Recovery application in that case
*Before launching the Rescue and Recovery application at system boot, the default bootloader changes the partition type of the Rescue and Recovery partiton to 0x0b, otherwise it changes it to 0x12 (to hide it from Windows)
*The Rescue and Recovery application assumes that the first partition contains Windows
*The Rescue and Recovery partition needs to be of type 0x0b (FAT32) otherwise the default bootloader will not launch the Rescue and Recovery application (this conflicts with a point above)

Since neither LILO nor GRUB catch the press of the button (an undocumented mechanism anyway) it is not possible to launch the Rescue and Recovery application by pressing the appropriate button during system boot, once LILO or GRUB have altered the MBR for their boot procedure.

IBM provides a program to manage the Rescue and Recovery bootloader. It is located in {{path|C:\Program Files\IBM ThinkVantage\Common\BMGR}} or {{path|C:\Program Files\Common Files\Lenovo\BMGR}}. It can select the partition to boot, and also allows for rewriting the MBR if it was written by another bootloader. More information is needed about this program.

===MBR written by GRUB===
If the MBR was written by GRUB you can still use GRUB to launch the Rescue and Recovery application. However if you leave the type of the Rescue and Recovery partition to 0x12 (Compaq diagnostics), this will result in an error message "c000021a, Fatal System Error" if you try to launch it. To avoid that and to make sure the recovery partition always is of the right type, add a line to change the partition type to 0x0b to the Rescue and Recovery partition's entry in your {{path|/boot/grub/menu.lst}}. Assuming your Rescue and Recovery partition is the second partition, it could look like this: Please note that there are people who report that this didn't work, for example it didn't work on a {{Z61m}} 9450-3HG.

title IBM Rescue and Recovery
root (hd0,1)
'''parttype (hd0,1) 0x0b'''
'''unhide (hd0,1)'''
chainloader +1

Also add an <tt>unhide</tt> line here because we are going to hide the Rescue and Recovery partition on every boot of Windows, so we need to unhide it, when the recovery partition is booted. This is because if we don't hide the partition when booting Windows, it would be visible and accessable there and that's not what we want. So, assuming that Windows is on the first partition, the Windows entry could now look like this:
title Windows
root (hd0,0)
'''hide (hd0,1)'''
chainloader +1

===GRUB in a partition's boot sector===
A way to have your Access IBM button still functional on bootup, is to create a separate {{path|/boot}} partition, install GRUB to that partition and make it active. This will leave the MBR untouched.
{{NOTE|If the above finding is true that the MBR ignores the active bit, that partition has to be the first one. In most recent Linux distributions it is not easy to create /boot as first partition and shrink the Windows partition. In that case the Windows bootloader can be used to boot Windows and Linux, also preserving the Rescue and Recovery functionality. See below.}}
*In the BIOS, set the IBM Predesktop Area to 'Secure'.
*Boot your Linux distribution's installation CD.
*Follow the instructions and go through the regular installation process.
*Create a '''primary partition''' for /boot (the other stuff can go into the extended partitions) and when the time comes to install GRUB, make sure you install it into the boot sector of the boot partition.
*Set this boot partition as active.

===Using NTLDR to boot Linux===
It is possible to configure the Windows bootloader to also boot Linux (installed on separate partition). This allows to preserve the Rescue and Recovery functionality at system boot (as MBR is not modified), Windows XP (booted via its native bootloader) and Linux (booted from its own partition by Windows XP bootloader). A quick and dirty howto, regarding applying this procedure to Ubuntu Dapper Drake installation can be found [http://gawrysiak.org/corvus/?p=4 here].

==Older versions of Rescue and Recovery==
Some Thinkpads (e.g., T23 and T30) do not come with a Recovery CD, but also do not support the [[Hidden Protected Area]]. These ThinkPads have an older version of Rescue and Recovery preloaded on the hard disk to implement the factory recovery function. Most of the comments above also apply to the older versions, with the following differences:
*The recovery partition type is 0x1c, hidden FAT32, LBA-mapped (or 0xc when unhidden).
*The boot manager program is in {{path|C:\IBMTOOLS\RECOVERY}} and only runs in a 16-bit DOS environment
{{Fixme|name of this boot manager needed}}
*The IBM Predesktop area runs atop of Windows 98 (command-line) instead of WinPE

==External Sources==
* IBM page on [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4Q2QAK ThinkVantage Rescue and Recovery].
* [ftp://ftp.software.ibm.com/pc/pccbbs/thinkvantage_en/tvtrnr3_1027en.txt Rescue and Recovery Readme]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-46088 IBM page about accessing the Recovery Partition if Linux has been installed and the F11 button no longer works]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54483 IBM Rescue and Recovery repair diskette]

==Models featuring this technology==
* ThinkPad {{T23}}, {{T30}} (R&R 2.0)
* ThinkPad {{T42}}
* ThinkPad {{T43}}, {{T43p}}
* ThinkPad {{T60}}, {{T60p}}
* ThinkPad {{R52}}
* ThinkPad {{Z60m}}
* Thinkpad {{Z61m}}

[[Category:Glossary]]

High-pitch noise from AC-Adapter

2007-01-06T21:09:34Z

Theclaw:

== High-pitch noise from AC-Adapter ==

This appears in some AC adapters shipped with some {{T60}}, {{T60p}}, {{Z61m}} (they're possibly shipped with others, too)
So far, Lenovo did not offer any feedback for this problem.

Ordering Recovery CDs

2006-12-31T17:30:41Z

Theclaw: /* What happens then */ happened to me

Information on getting Recovery CDs from IBM.

The information on this page is unofficial. It is gathered from personal experiences. It is here to raise your chances of success when you give it a try yourself.

==About Recovery CDs==
Recovery CDs enable you to reproduce the original software state on your ThinkPad. Until the beginning of 2001 IBM delivered recovery CDs with the ThinkPads, but starting with the A30/T23/X22 models ThinkPads have a [[Predesktop Area]], which's purpose is to make Recovery CDs obsolete. However, this is flawed logic, since you will lose both the installed OS AND the [[Predesktop Area]] upon failure of the hard drive. Also, if you buy a drive upgrade the [[Predesktop Area]] will not be on the new drive. Furthermore, spyware and viruses are lately being designed to infiltrate recovery partitions, so if you restore the system from such, you will restore the invading malware along with it. For the time being, Recovery CDs are available on request.

Recovery CDs are localized, meaning that there are specific versions for each language. The language you will get depends on the language of the OS that was shipped with your ThinkPad. There's usually no way to get CDs in a different language from IBM.

==How to get them==

===Creating Recovery CDs from the preinstalled O/S===
In some ThinkPads IBM supplies a utility to create the recovery CDs. You'll find a utility called "Create Recovery Discs" in the "ACCESS IBM" folder of the Start Menu. To create the Recovery discs, you'll need a CD/DVD writer and blank media. The Product Recovery discs set consist of one Rescue and Recovery disc (size of 1 CD-R) and one or more Product recovery discs (size of 1 DVD-R).

Others might want to read the appendix "Creating an image of the hard drive" in this [ftp://ftp.software.ibm.com/pc/pccbbs/access_ibm_en/hpa_aibm.pdf document] from IBM for instructions. It is also usefull when replacing the hard disk. If your Thinkpad does not have a floppy drive, you could try to create a FAT partition on the harddisk and copy the files "fwbackup.exe" and "fwrestor.exe" there.

===From IBM===
Should you fail to create a set of recovery discs before your harddrive fails, you may try to contact IBM service and request for a set.
This can be done by eMail or phone.
[http://www.ibm.com/support/ Support phone numbers] are available online.
They are officially called ''Recovery CD service parts.''
If you actually get them, or not, seems to be more a personal decision of the service person dealing with you than following fixed rules. Also it seems to depend on your country (see below).

They will usually expect you to tell them a good reason for your request (see below).
As with every service request, you'll also have to provide your model and serial number to verify the warranty state.
The warranty for your ThinkPad is usually quite long though (3 years in my case), and you can
[http://www-307.ibm.com/pc/support/site.wss/ check online] if your warranty is still in force.
The model number is also used to determine which CDs you will get.

Orders placed during the first month after purchase have proven to be the most successful. Note some people needed to pay a $45.00 fee, plus shipping and tax, for the CDs, regardless of when ordering them. Again, this seems to depend on the mood of the service rep that handles your case.

Note that Recovery CDs are only available for Windows XP Professional for the X24, as per the Customer Service Center in Atlanta, GA. All other operating systems (Windows 2000, 98SE, OS/2, etc...) are no longer available. XP Home was apparently never available for the X24.

====Good reasons to tell====
*You replaced (or will be replacing) your hard drive.
*You installed Linux or some other OS and accidentally removed/destroyed the [[Predesktop Area]].
*You bought a machine in one country (e.g Germany) and need to convert the OS to use a different language (e.g. English).

====What happens then====
The time of delivery varies. In some cases its very fast (times from 16h to 3 days have been reported), on the other hand it has been reported that the time of delivery is very high, three weeks for example. The shipping can happen without prior confirmation of your request, so don't be worried if you hear nothing within this time.

A Dutch IBM customer reported next-day delivery of recovery CDs, on three different occasions. A customer in Belgium had to wait 8 days, so sometimes delivery is not that fast.

Apparently recovery CDs to the UK are now shipped from Hungary, with an estimated delivery of 8-9 days. Experience shows they tend to come a little sooner. It seems likely that this is now the source for all of Europe.

====Country overview====
Please put an entry for your country into this table if it's missing and you made a try to get the Recovery CDs.
{| border="1" cellspacing="0" cellpadding="2"
|-
! style="vertical-align:top;background-color:#cfefcf;" | CDs received in
! style="vertical-align:top;background-color:#ffcfbc;" | CDs were denied in
|-
| style="vertical-align:top;background-color:#e9f9e9;" |
*Argentina
*Austria
*Australia (depends on the service rep & reason)
*Brazil
*Belgium
*Canada
*Denmark
*Estonia
*Finland
*France
*Germany (cost: 39,90 Euro (+VAT) if device is out of warranty), otherwise is free
*Italy
*The Netherlands
*New Zealand
*Norway
*Poland (60 PLN +VAT (on warranty) via IBM Poland business partner)
*Philippines
*Spain
*Sweden
*Switzerland
*UK
*USA ($45 if out of warranty [in one case, at least])
*Turkey
| style="vertical-align:top;background-color:#fff0e0;" |
*Israel, but received after calling IBM Europe
*Australia, payment was requested
*India, just a plain "not possible"
*Russia, service reps claim that these CDs are not for end-users
*UK, denied using first reason (must be an IBM HDD), received using second reason.
*Hungary, service reps claim that these CDs are not for end-users
|}

[[Category:Windows]] [[Category:A30]] [[Category:A30p]] [[Category:A31]] [[Category:A31p]] [[Category:G40]] [[Category:G41]] [[Category:R30]] [[Category:R31]] [[Category:R32]][[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50e]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T23]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:X22]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]]

Problems with fglrx

2006-12-22T20:17:41Z

Theclaw: /* Hardlock on X logout */

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.<br>
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}.<br>
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.<br>
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.
|-
|{{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 <br>
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]

How to protect the harddisk through APS

2006-12-16T14:45:47Z

Theclaw: +cat z61m

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page tells you how to make the [[Active Protection System]] work under Linux to protect your harddrive from damage in case of a notebook drop or other kind of impact while it is running.

Specific instructions for {{Fedora}} can be found [[Installing_Fedora_Core_5_on_a_ThinkPad_X41_Tablet#Harddrive_Active_Protection_System_.28HDAPS.29|here]].

== How APS works in Linux ==
APS in Linux consists of four components on the software side:
* The [[HDAPS]] driver (included in recent kernels). It exports a sysfs interface providing the acceleration values.
* The [http://www.dresco.co.uk/hdaps/ <tt>hdaps_protect</tt>] disk protection kernel patch, which exports a sysfs interface that enables an ide or sata disk to be protected by a userspace process.
* The [http://www.dresco.co.uk/hdaps/ <tt>hdapsd</tt>] disk protection userspace daemon. It monitors the acceleration values through the HDAPS interface and automatically initiates disk protection through the hdaps_protect interface - given that the movement exceeds a user specified threshold.
* Optional: the [http://roy.marples.name/node/269 khdapsmonitor KDE System Tray applet] or [http://www.oakcourt.dyndns.org/projects/khdapsmon/ <tt>khdapsmon</tt> KDE System Tray applet] or the [http://www.dresco.co.uk/hdaps/ <tt>gnome-hdaps-applet</tt>]. These applets provide a visual indication of the disk protection status and also a graphical interface for adjusting configuration options for <tt>hdapsd</tt>.
|}

==Installation==
As mentioned above, the hdaps kernel driver found in recent kernels is only responsible for reading the accelerometer data and exporting it through the sysfs interface.

In order to use this information to protect the disk, some additional steps are required.

* Download and build the latest hdaps_protect disk protection kernel patches.
* Enable the drivers in the kernel (requires kernel rebuild).
* Download, build and configure the hdapsd userspace daemon.
* Download and build one of the applets to get a real-time representation of the disk protection status.

===Getting the files===
{| border="1" cellspacing="0" cellpadding="2"
! Latest Sources
|
*<tt>hdaps_protect</tt>, <tt>hdapsd</tt> and the <tt>gnome-hdaps-applet</tt>: http://www.dresco.co.uk/hdaps
*<tt>khdapsmon</tt>: http://www.oakcourt.dyndns.org/projects/khdapsmon/
|-
! {{Debian}}
|
*<tt>hdapsd</tt>, <tt>hdaps_protect</tt>, <tt>khdapsmon</tt>, <tt>gnome-hdaps-applet</tt>:
:{{cmdroot|deb http://www.oakcourt.dyndns.org/debian/ ./}}
:{{cmdroot|deb-src http://www.oakcourt.dyndns.org/debian/ ./}}
|-
! {{Fedora}}
| see instructions [[Installing_Fedora_Core_5_on_a_ThinkPad_X41_Tablet#Harddrive_Active_Protection_System_.28HDAPS.29|here]]
*kernel RPM packages including <tt>hdaps_protect</tt>: http://www.dresco.co.uk/hdaps/
*kernel RPM packages including <tt>hdaps_protect</tt> and [[Software Suspend 2]]: http://mhensler.de/swsusp/download/yum/development/fc5/ (build 2084_2 and up)
|-
! {{Gentoo}}
|
*<tt>hdapsd</tt> ebuild: http://bugs.gentoo.org/show_bug.cgi?id=119845
*<tt>khdapsmon</tt> ebuild: http://bugs.gentoo.org/show_bug.cgi?id=124175
|}

=== Adding kernel support ===
A kernel patch is required for disk head parking and queue freezing.

==== Manually patching and compiling a kernel ====
As root, do:
:{{cmdroot|cd /usr/src/linux}}
:{{cmdroot|patch -p1 < ~/hdaps_protect.20060409.patch}}
:{{cmdroot|make clean}}
:{{cmdroot|make}}
:{{cmdroot|make modules_install}}

=== Installing hdapsd ===
==== Manual compilation from source ====
* Download the <tt>hdapsd</tt> sources (see above)
* Compile using {{cmdroot|gcc -o hdapsd hdapsd-*.c}}
* Run {{cmdroot|./hdapsd -d sda -s 12 -a}} (replace <tt>sda</tt> with your hard disk device; run {{cmdroot|./hdapsd}} without arguments for help)

==== Gentoo ====
{{Gentoo}} users can try the ebuild attached to [http://bugs.gentoo.org/show_bug.cgi?id=119845 gentoo bug 119845].
{{NOTE|1=hdapsd was added to the official portage tree on the 26th June 2006.}}
*Add hdapsd support in your kernel: device drivers -> hardware monitoring -> ... (you need it as a module if you want to use tp_smapi and hdaps, see [[Tp_smapi]])
*Download the ebuild, use same ebuild date as the kernel-patch.
*Make known the portage an extern ebuild path and add the following line to {{path|/etc/make.conf}}:
PORTDIR_OVERLAY="/usr/local/portage/" (or any other location)
*Create directory {{path|/usr/local/portage}} and {{path|/usr/local/portage/app-laptop/}}
*Copy the downloaded ebuild to {{path|/usr/local/portage/app-laptop}} ({{path|/usr/local/portage/app-laptop/hdapsd}} should now exists)
*Make portage known the new ebuild and creat digist with:
:{{cmdroot|ebuild /usr/local/portage/app-laptop/hdapsd/hdapsd-20060326.ebuild digest}}
*Optional: Copy source file to portage distfiles (if no internet connection is available):
:{{cmdroot|cp hdapsd-20060326.c /usr/portage/distfiles}}
*Accept the x86 keyword for this package: {{cmdroot|echo "app-laptop/hdapsd ~x86" >> /etc/portage/package.keywords}}
*Install hdapsd with: {{cmdroot|emerge hdapsd}}.
*Edit {{path|/etc/conf.d/hdapsd}} (change your harddrive if neccessary: mine is sda, and change the value from 5, 5 is to sensitive, 12 is a good value in my opinion).
*start deamon with: {{cmdroot|/etc/init.d/hdapsd start}}
*Optional: add to default runlevel: {{cmdroot|rc-update add hdapsd default, rc-update add hdapsd battery}}
Write an eMail to abartel[Ã¤d]htwm.de, if you want to get my hdapsd-20060326.ebuild and please upload it.

=== Building an applet ===
====hdaps-gl====
*Make sure you have installed hdaps [and loaded] and ?opengl?
*Download <tt>hdaps-gl-0.0.5</tt> from the web.
*Extract files to {{path|/opt/hdaps-gl}}.
*{{cmdroot|make}}
*Start the applet: {{cmdroot|./hdaps-gl}}

====khdapsmon====
This application uses GNU autotools, so building it is the same as any other autotooled program:
*extract the source somewhere and change to that directory,
*run {{cmdroot|./configure && make && make install}}.
See [[#Getting the files|above]] for Debian packages and a Gentoo ebuild.

====gnome-hdaps-applet====
=====Debian/Ubuntu=====
Packages available at site listed above (with source packages that can do the building for you)

==Troubleshooting==
See the [[Problem with APS harddisk parking]] page for troubleshooting APS issues.
{{NOTE|1=If you use [[tp_smapi]], remember to include the option <tt>HDAPS=1</tt> when [[Tp_smapi#Installation|installing tp_smapi]]. Also, you might need to build the hdaps driver as module.}}

==Further Information==
*Additonal information and support is available through the [[Mailinglists#HDAPS Developers Mailinglist|hdaps-devel]] mailinglist and its archive.

[[Category:R50]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:T60]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:X60]] [[Category:X60s]] [[Category:Z60m]] [[Category:Z60t]] [[Category:Z61m]]

HDAPS

2006-12-16T14:44:54Z

Theclaw: +cat: z61m

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
=== HDAPS - IBM Active Protection System Linux Driver ===
This is the Linux driver for monitoring the acceleratometer known as [[Active Protection System|IBM Active Protection System]].

The driver only enables reading of the acceleration data. It does '''not''' perform [[#Harddisk Protection|automatic disk head parking]]. But there are already some other useful [[#Applications|applications]] for HDAPS, using the {{path|/sys}} interface it provides.
|}

=== Features ===
*provides accelerometer values via sysfs
*provides a joystick type input device

=== Project Homepage / Availability ===
*[http://hdaps.sourceforge.net/ Project Homepage]
*The driver is included in the 2.6-mm series of kernels since August, 26th 2005.
*The driver is now in the mainline (2.6.14).
*The [[tp_smapi]] package contains some patches to this driver. These are necessary for some recent models, and recommended for all.

=== Status ===
A driver is included in recent Linux kernels and is actively maintained.

=== How to install the driver ===
If you are using a version of the Linux kernel < 2.6.14, please upgrade. I struggled long and hard to get the driver working with an old version of the kernel, and it was a mess. I gave up, upgraded my kernel, and one recompile later, HDAPS was working.

=== Harddisk Protection ===
As mentioned above, the hdaps kernel driver is only responsible for reading the accelerometer data and exporting it through the sysfs interface. In order to use this information to protect the disk, some additional steps are required.

See [[How to protect the harddisk through APS]].

=== Input device support ===
The hdaps driver in the lastest kernels (2.6.14 and later?) also exports a joystick type input device, which can be used by games.

=== Applications ===
====Disk head parking====
You will need the kernel patch and userspace daemon. The GUI monitoring is optional.
* Kernel patch (apply using 'patch -p1 -l < hdaps_xx.patch')
**[http://lwn.net/Articles/154923/ disk park patch] <tt>an experimental patch for parking the disk (Linux 2.6.14 for 2.6.15 see below)</tt>
**[http://jenster.dyndns.org/files/blk_freeze-01-nodetection-for-2.6.14.patch disk park patch adapted for the t41p model] <tt> kernel 2.6.14 *([http://sourceforge.net/mailarchive/message.php?msg_id=13214288 capability detection disabled], no libata support)</tt>
**[http://jenster.dyndns.org/files/blk_freeze-01-nodetection-for-2.6.15.patch disk park patch adapted for the t41p model] <tt> kernel 2.6.15 *([http://sourceforge.net/mailarchive/message.php?msg_id=13214288 capability detection disabled], no libata support)</tt>
**[http://www.dresco.co.uk/hdaps/hdaps_protect.20060118.patch sata/ide disk protection patch for 2.6.15]
**[http://www.dresco.co.uk/hdaps/hdaps_protect.20060430.patch Latest sata/ide disk protection patch for 2.6.16]
**[http://whoopie.gmxhome.de/linux/patches/2.6.16-tj/05-hdaps_protect-20060430-for-2.6.16-tj.patch Latest sata/ide disk protection patch for use with the libata hotplug 2.6.16.16 patches] - See [[How_to_hotswap_UltraBay_devices]]
**[http://whoopie.gmxhome.de/linux/patches/2.6.17.14-tj/03-hdaps_protect-20060430-for-2.6.17-tj.patch Latest sata/ide disk protection patch for use with the libata hotplug 2.6.17.4 patches] - See [[How_to_hotswap_UltraBay_devices]]
**[http://exitzero.de/t41p-configs/hdaps_protect-2.6.17.1-20060625.patch Untested patch for 2.6.17.1]: see [http://thread.gmane.org/gmane.linux.drivers.hdaps.devel/708/focus=708]
**[http://www.dresco.co.uk/hdaps/hdaps_protect-2.6.18.3-2.patch Latest sata/ide disk protection patch for 2.6.18.3]
**[http://article.gmane.org/gmane.linux.kernel/470413 Latest sata/ide disk protection patch for 2.6.19-rc6]
*Userspace daemon
**[http://www.dresco.co.uk/hdaps/hdapsd-20060409.c userspace parking daemon]
**[ftp://rohrmoser-engineering.de/pub/ hdapsd-<date>.c is an improved version of the daemon, which computes an adaptive sensivity threshold]
*GUI monitoring
**[http://www.oakcourt.dyndns.org/projects/khdapsmon/ khdapsmon] <tt>KDE System Tray app similar to the Windows one (also at [http://www.kde-apps.org/content/show.php?content=34134 kde-apps.org])</tt>
**[http://roy.marples.name/node/269 khdapmonitor] Another userfriendly KDE System Tray Monitor
**[http://www.dresco.co.uk/hdaps/gnome-hdaps-applet-20060120.tar.gz gnome-hdaps-applet] <tt>visual display of disk protection status in gnome panel</tt>
See [[How to protect the harddisk through APS]] for more information.

====Security & safety====
*[[Script for theft alarm using HDAPS]]

====Tilt monitoring====
*[http://www.mulliner.org/collin/gkibm-acpi.php gkhdaps] <tt>a GKrellM applet displaying tilt data</tt>
*[http://rlove.org/log/2005082203.html gnome-tilt] <tt>a gnome applet showing tilt data</tt>

====Visualisation (of ThinkPad orientation)====
*[http://rlove.org/log/2005082401.html hdaps-gl] <tt>a little app animating a 3D-ThinkPad</tt>
*[https://sourceforge.net/project/showfiles.php?group_id=138242 hdapsgl-applet] <tt> a GNOME applet animating a 3D-ThinkPad</tt>
*[https://sourceforge.net/project/showfiles.php?group_id=138242 wmadhps] <tt>a WindowMaker DockApp animating a 3D-ThinkPad</tt>
*[http://www.cs.cmu.edu/~ecc/gyro.tar.gz OpenGL gyroscope hack] <tt>keeps your display levelled when tilting the ThinkPad</tt>

====Games====
*Robert Love mentions a [http://icculus.org/neverball/ Neverball] patch on [http://rlove.org/log/2005100302.html his blog] to keep the display aligned. However, the link there seems broken.
*Turn your ThinkPad into a Jedi Weapon (hey, it [http://isnoop.net/blog/2006/05/20/macsaber-turn-your-mac-into-a-jedi-weapon works for Mac laptops])

====Other====

*[http://blog.micampe.it/articles/2006/06/04/here-comes-the-smackpad smack.py] - switch workspace by smacking your laptop, inspired by the [http://blog.medallia.com/2006/05/smacbook_pro.html SmackBook] (an [http://weblogs.mozillazine.org/gerv/archives/2006/09/stablilised_smackpad.html improved version] adds stabilization])
*[http://www.gnome.org/~fherrera/gtollina.c GTollina] - another smack program for use with compiz (video [http://www.gnome.org/~fherrera/blog/gtollina.html here]).
*[http://blog.odonnell.nu/61.html xmms-smack.py] - move through your xmms playlist by smacking, based on the two smack scripts above.
*[http://www-128.ibm.com/developerworks/linux/library/l-knockage.html?ca=dgr-lnxw02aKnockBasedCommands KnockBasedCommands] - Execute commands by tapping your laptop.

=== Interesting links related to this project ===
* [https://lists.sourceforge.net/lists/listinfo/hdaps-devel HDAPS mailinglist and its archive]
* #hdaps channel on irc.freenode.org
* [https://sourceforge.net/projects/hdaps/ hdaps projects] overview of userspace programs using hdaps
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=TPAD-HDFIRM IBM ThinkPads hardware drive firmware site]
* [http://www.paul.sladen.org/thinkpad-r31/accelerometer.html http://www.paul.sladen.org/thinkpad-r31/accelerometer/]
* http://bugs.gentoo.org/show_bug.cgi?id=119845 Gentoo ebuild for hdaps driver and daemon including a initscript*
* http://bugs.gentoo.org/show_bug.cgi?id=137345 Gentoo ebuild for gkhdaps gkrell plugin
* http://bugs.gentoo.org/show_bug.cgi?id=137350 Gentoo ebuild for hdaps-gl application
* http://bugs.gentoo.org/show_bug.cgi?id=137351 Gentoo ebuild for gnome hdapsgl-applet
* http://bugs.gentoo.org/show_bug.cgi?id=137352 Gentoo ebuild for gnome tilt application
* http://bugs.gentoo.org/show_bug.cgi?id=137353 Gentoo ebuild for wmhdaps

[[Category:R50]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:R60]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:T60]] [[Category:T60p]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:X60]] [[Category:X60s]] [[Category:Z60m]] [[Category:Z60t]] [[Category:Drivers]] [[Category:Z61m]]

How to control fan speed

2006-12-16T14:36:04Z

Theclaw: /* Supported models */

This page discusses methods for controlling the system fan.

==For Linux==
===Using a patched kernel===
{{WARN|This patch is superceded by the patches in [[ibm-acpi]] [[Git]] repository}}

The [[Patch for controlling fan speed]] provides a convenient interface via {{path|/proc/acpi/ibm/fan}}.

Manual speed control can be done through the [[patch for controlling fan speed]]:

'''#cat /proc/acpi/ibm/fan'''
status: enabled
level: auto
speed: 4219
commands: enable, disable, level <level>
(<level> is 0-7, auto or disengaged)

'''#echo level 2 > /proc/acpi/ibm/fan'''

'''#cat /proc/acpi/ibm/fan'''
status: enabled
level: 2
speed: 3142
commands: enable, disable, level <level>
(<level> is 0-7, auto or disengaged)

===Using a stock kernel===

If you have the [[ibm-acpi]] module loaded with <tt>experimental=1</tt>, you can control the fan without patching the kernel by directly writing to the relevant embedded controller register using {{path|/proc/acpi/ibm/ecdump}}.

For example:

{{cmdroot|echo 0x2F 0x00 > /proc/acpi/ibm/ecdump}} (fan off)

{{cmdroot|echo 0x2F 0x02 > /proc/acpi/ibm/ecdump}} (low speed)

{{cmdroot|echo 0x2F 0x04 > /proc/acpi/ibm/ecdump}} (medium speed)

{{cmdroot|echo 0x2F 0x07 > /proc/acpi/ibm/ecdump}} (maximum speed)

{{cmdroot|echo 0x2F 0x80 > /proc/acpi/ibm/ecdump}} (automatic - default)

{{cmdroot|echo 0x2F 0x40 > /proc/acpi/ibm/ecdump}} (disengaged)

See the specifications below for the meaning of these modes.

===On/off control using stock kernel===

If you only wish to turn the fan on and off (with automatic control when it's on), you can use the following.

When loading [[ibm-acpi]] v0.11 with experimental switch ({{cmdroot|1=modprobe ibm_acpi experimental=1}}), it is possible to read and write the status of fan:

'''#cat /proc/acpi/ibm/fan'''
status: enabled
speed: 3580
commands: enable, disable

'''#echo disable > /proc/acpi/ibm/fan'''

'''cat /proc/acpi/ibm/fan'''
status: disabled
speed: 0
commands: enable, disable

When off, the fan will then '''never''' wake up. It is advised to use an automated control script to reduce the chance of hardware damage.

===Automated control scripts===

An [[ACPI fan control script#Variable speed control scripts|ACPI fan control script]] can be to override the firmware's fan algorithm with gentler, quieter version. It monitors the laptop's [[thermal sensors]] and sets the fan speed accordingly, according to customizable thresholds. For the default behavior, simply save the [[ACPI fan control script#Variable speed control scripts|script]] as {{path|tp-fancontrol}} and run; note that this script requires you to modprobe the ibm_acpi module as "modprobe ibm_acpi experimental=1"<br />
{{cmdroot|./tp-fancontrol}}

==For Windows==

Shimodax's ThinkPad fan control tool offers similar functionality (see [http://forum.thinkpads.com/viewtopic.php?t=17715 forum discussion] at thinkpads.com). Source and binaries are available through the [http://sourceforge.net/projects/tp4xfancontrol "Tp4xFanControl"] project on SourceForge.

==Hardware specs==

The following hardware behavior was discovered experimentally by [[User:Thinker|Thinker]] and neither provided by nor confirmed by IBM/Lenovo. The following description may be inaccurate and may vary by model (see list of models above). The terminology probably does not match the one used by IBM/Lenovo engineers.

{{NOTE|Information on other models is included in the [[ibm-acpi]] [[Git]] version.}}

ACPI DSDT register _SB.PCI0.LPC.EC.HFSP (8 bits, offset 0x2F in the <tt>EmbeddedController</tt> address space, accessed through the standard EC interface at IO ports 0x62 and 0x66) is read/writable and has the following meaning:

Bits 7 6 5 4 3 2 1 0
---------------
Value 1 0 * * * * * * - automatic
* 1 * * * * * * - disengaged
0 0 N N N N N N - manual (0..63; 0=disable fan, 1=min, ..., 7=max)

In ''automatic'' mode, the embedded controller sets the fan speed automatically according to system temperatures and some unknown algorithm.

In ''manual'' mode, the fan level is forced to the given value and the EC will auto-regulate the fan to maintain at a (roughly) constant RPM, which is model-dependent. Manual speed levels 8-63 yield the same behavior as level 7, and the the ACPI DSDT uses level 7 for the emergency mode it enters upon critical CPU/GPU temperature, so apparently 7 is the real maximum level.

In ''disengaged'' mode, the embedded controller does not read the fan RPM (hence <tt>EmbeddedController</tt> offset 0x84 is not updated), and does not maintain a stable fan speed. When disengaged mode is entered the fan speed is not immediately changed (except if the fan was disabed, in which case it is turned on at a low level). However, once in disengaged mode, fan speed will slowly increase to ''beyond'' the maximum manual level (this may cause hardware damage!).

{{NOTE|The "disengaged" mode has a different behaviour on ThinkPad {{A31}} than that described above. As above, the fan speed increases beyond the levels of the regular 0-7 speed settings. However, the speed increase is fairly instantaneous (the change being as fast as the transition between any other two speed levels, except 0 (off) which seems faster, i.e. immediate); and the fan speed reading is ''continuously'' available while in "disengaged" mode. In the {{A31}}, the speed reaches about 4000 RPM as listed in the table below.}}

After boot, the HFSP register may not reflect the true state of the EC (on some models it reads 0x07 even though the EC is actually in automatic mode).

{{HINT|Apparently the [[Problem with fan noise|pulsing fan noise]] experienced by some users can be cured by repeatedly running 2-4 seconds of manual control followed by 0.5-1 seconds of disengaged mode. The pulse occurs when the the embedded controller computes the fan speed and adjusts the fan voltage adaptively every few seconds (~4.8sec for the ThinkPad T43); the aforementioned mode switching doesn't give it a chance to do so. One of the [[ACPI fan control script#Variable speed control scripts|ACPI fan control scripts]] implements this solution.}}

==Supported models==

The above was successfully tested on the following models:

* ThinkPad {{T43}}, {{T43p}} (fan levels RPM: 1-2 = ~3300, 3-5 = ~4100, 6-7 = ~4700; disengaged mode works)
* ThinkPad {{T42}}, {{T42p}} (fan levels RPM: 1-2 = ~2900, 3-5 = ~3700, 6-7 = ~4700; disengaged mode works at ~5200)
* ThinkPad {{T41}}, {{T41p}} (fan levels RPM: 1-2 = ~2980, 3-5 = ~3500, 6-7 = ~4050; disengaged mode works at ~5100)
* ThinkPad {{T40}} (fan levels RPM: 1-2 = ~2950, 3-5 = ~3600, 6-7 = ~4050)
* ThinkPad {{T30}}
* ThinkPad {{T22}}
* ThinkPad {{T23}} (low speed = ~2200, medium and maximum speed = ~4800; disengaged mode works at ~5800)
* ThinkPad {{R52}}
* ThinkPad {{R50}} (highest manual level is 3; disengage mode works and reaches much higher RPM)
* ThinkPad {{R50p}} (disengaged mode works at ~5100)
* ThinkPad {{R51}} (level 0 = off, level 1-2 = ~3150, level 3-5 = ~3350, level 6 = ~3750, disengaged = ~5100)
* ThinkPad {{X30}} (level 0 = off, low = ~3900, medium = ~4200, maximum = ~4650, disengaged = ~5900)
* ThinkPad {{X31}}
* ThinkPad {{X40}}
* ThinkPad {{X41T}}
* ThinkPad {{Z60t}} (fan levels RPM: 1-2 = ~1700, 3-5 = ~2800, 6-7 = ~3500)
* ThinkPad {{Z60m}} (fan levels like Z60t)
* ThinkPad {{Z61m}}
* ThinkPad {{X60}}
* ThinkPad {{A31}} (fan levels RPM: 0 = off, 1-2 = ~3280-3380 (!), 3-5 = ~3200, 6-7 = ~3380, "disengaged" = ~4000 (see NOTE above))
Probably other models are supported too (please update this page if you confirm this).

==Models using a different interface==

The following models also work, use a different access method which supported (only) via the {{path|/proc/acpi/ibm/fan}} of [[ibm-acpi]]. No need for patching.

* ThinkPad {{600E}}, {{600X}}, {{770E}}, {{770X}} (these use a different fan control interface)

==Unsupported models==

* ThinkPad {{560}} (these models don't have a fan)

Problem with high pitch noises

2006-12-15T15:45:53Z

Theclaw: /* Turn off CPU power saving in in BIOS */

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}}, {{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).<br />Just do the following:<br />
: 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.<br />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.

Problem with high pitch noises

2006-12-15T15:45:26Z

Theclaw: it's just a fact. :(

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}}, {{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).<br />Just do the following:<br />
: 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.<br />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.

High-pitch noise from AC-Adapter

2006-12-08T00:00:15Z

Theclaw:

== High-pitch noise from AC-Adapter ==

This appears in some AC adapters shipped with some T60, T60p, Z61m (they're possibly shipped with others, too)
So far, Lenovo did not offer any feedback for this problem.

Problem with high pitch noises

2006-12-01T20:19:33Z

Theclaw: /* Affected Models */ on my z61m (9450-3hg) the problem also occurs, PLUS: the noise level varies significantly!

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
|-
| 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. Then 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}}, 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}} and {{X60s}}.)

===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).<br />Just do the following:<br />
: 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.<br />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.

Hitachi Travelstar 5K100

2006-11-16T19:30:42Z

Theclaw: /* Models shipped with this disk */ my thinkpad z61m features a hitachi drive

__TOC__

This is a family of 5400RPM 2.5" hard disks manufactured by Hitachi. They are available in various sizes, and in both PATA (ATA-6) and SATA interfaces. Only the ATA-6 disks were shipped with ThinkPads though.

{| border="1" cellspacing="0" cellpadding="2" width="50%"
|+PATA (ATA-6) interface models:
! Model !! Size
|-
|HTS541010G9AT00 || 100GB
|-
|HTS541080G9AT00 || 80GB
|-
|HTS541060G9AT00 || 60GB
|-
|HTS541040G9AT00 || 40GB
|-
|HTS541030G9AT00 || 30GB
|-
|HTS541020G9AT00 || 20GB
|}

{| border="1" cellspacing="0" cellpadding="2" width="50%"
|+SATA-I interface models:
! Model !! Size
|-
|HTS541010G9SA00 || 100GB
|-
|HTS541080G9SA00 || 80GB
|-
|HTS541060G9SA00 || 60GB
|-
|HTS541040G9SA00 || 40GB
|-
|HTS541030G9SA00 || 30GB
|-
|HTS541020G9SA00 || 20GB
|}

==Documentation==

* [http://www.hitachigst.com/hdd/support/5k100/5k100_ov.htm Overview]
* [http://www.hitachigst.com/hdd/support/5k100/5k100.htm General specifications]
* [http://www.hitachigst.com/tech/techlib.nsf/techdocs/98F75D1B2B25C42F86256EBC0065A2F9/$file/T5K100_sp.pdf Detailed specifications (ATA-6 models)]
* [http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_5K100 Technical documents]

==Models shipped with this disk==
* {{T43}}, {{T43p}}
* ThinkPad {{R52}}
* Thinkpad {{Z61m}}

==Firmware==

On some ThinkPad models, you must buy the IBM-branded version of this drive, since the Hitachi-branded version has an incompatible and unupgradable firmware (see [[Problem with non-ThinkPad hard disks]]).

==See also==
* [[Harddisk Drives]]

Ethernet Controllers

2006-11-11T17:52:09Z

Theclaw: /* Broadcom Gigabit (10/100/1000) */

== Internal Ethernet controller ==

A variety of [[Ethernet]] controllers is integrated into almost all models starting with the introduction of the A, T and X series.

The Ethernet controller is located on either a MiniPCI card, Communications Daughter Card (CDC), or integrated on the systemboard.

=== 3COM Fast Ethernet (10/100) ===
MiniPCI cards featuring this chip:
*[[3Com 10/100 Ethernet Mini-PCI Adapter with 56K Modem]]

=== Intel Fast Ethernet (10/100) ===
CDC and MiniPCI cards featuring this chip:
*[[Ethernet Daughter Card (EDC)]]
*[[Intel 10/100 Ethernet Mini-PCI Adapter with 56K Modem]]
*[[Intel PRO/100 SP Mobile Combo Adapter]]
*[[Mini-PCI Ethernet card]]
*[[Xircom 10/100 EtherJet Mini PCI Adapter with 56K Modem]]

In addition, this chip is integrated into select systemboards of the following machines:<br>
'''Intel 82550GY'''
* {{R30}}
'''Intel 82558'''
* [[SelectaBase PC Card Enabler with Advanced EtherJet]]
* [[ThinkPad Port Replicator with Advanced EtherJet]]
'''Intel 82562ET'''
* {{R31}}, {{R32}}
* {{T30}}
* {{X30}}
'''Intel 82562EZ'''
* {{R40}}, {{R50e}}, {{R50}}, {{R51}}
* {{T40}}
* {{X31}}

Driver: [[e100]] (The 'e100' driver is the suggested driver, but '[[eepro100]]' should also work.)

=== Intel Gigabit (10/100/1000) ===
Chipset: Intel PRO/1000 MT Mobile Ethernet<br />
Driver: [[e1000]]

This chip is integrated into select systemboards of the following machines:<br>
'''Intel 82540EP'''
* {{R50}}, {{R50p}}, {{R51}}
* {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}
* {{X31}}, {{X32}}
'''Intel 82541GI'''
* {{X40}}
'''Intel 82573L''' (PCI-Express)
* {{T60}}, {{T60p}}
* {{X60}}, {{X60s}}
Note: This chip supports Auto-MDIX, meaning you will never need a crossover ethernet cable.<br>
Note: The first signs of explicit support for this chip in 2.6 kernels is with 2.6.12-rc2.<br>
Note: Red Hat Enterprise Linux 3.0 (2.4 kernel based) begins 82573L support with Update 7.<br>
Note: Some users report issues: [[Problem_with_e1000:_EEPROM_Checksum_Is_Not_Valid]]<br>
Note: Some users have reported [http://forum.thinkpads.com/viewtopic.php?p=201279&sid=787564d7cf9de5d7d76b0cb312a98c61 latency problems] with e1000 driver. It seems, that [http://agenda.clustermonkey.net/index.php/Tuning_Intel_e1000_NICs switching off Interupt Throttle Rate (ITR)] helps. <br>
Note: [http://support.intel.com/support/network/sb/CS-009209.htm Additional configuration options from Intel]

For Gentoo users - compile e1000 as a kernel module and add 'options e1000 InterruptThrottleRate=0,0' to /etc/modules.d/e1000

=== Broadcom Fast Ethernet (10/100) ===
Driver: [[tg3]] or [[bcm5700]]

This chip is integrated into select systemboards of the following machines:<br>
'''Broadcom BCM5901'''
* {{G40}}, {{G41}}
* {{R40e}}
'''Broadcom BCM5751F'''
* {{R51e}}

=== Broadcom Gigabit (10/100/1000) ===
Chipset: Broadcom BCM5751M<br>
Driver: [[tg3]] or [[bcm5700]]

This chip is integrated into select systemboards of the following machines:
* {{R52}}, {{R60}}
* {{G41}}
* {{T43}}, {{T43p}}
* {{X41}}, {{X41T}}
* {{Z60m}}, {{Z60t}}
* {{Z61m}}, {{Z61p}}

Note: There are some problems with the driver since kernel 2.6.17 (at least on a Z61p, Z61m). After an ifdown && ifup it doesn't work anymore. A possible workaround is to build the tg3-driver as a module and reload it when this problem occours. Rebooting the machine would also be possible.

The T43 with a stock Linus 2.6.18.1 kernel does not have any problems.

[[Category:Components]]

Ethernet Controllers

2006-11-11T17:48:44Z

Theclaw: /* Broadcom Gigabit (10/100/1000) */

== Internal Ethernet controller ==

A variety of [[Ethernet]] controllers is integrated into almost all models starting with the introduction of the A, T and X series.

The Ethernet controller is located on either a MiniPCI card, Communications Daughter Card (CDC), or integrated on the systemboard.

=== 3COM Fast Ethernet (10/100) ===
MiniPCI cards featuring this chip:
*[[3Com 10/100 Ethernet Mini-PCI Adapter with 56K Modem]]

=== Intel Fast Ethernet (10/100) ===
CDC and MiniPCI cards featuring this chip:
*[[Ethernet Daughter Card (EDC)]]
*[[Intel 10/100 Ethernet Mini-PCI Adapter with 56K Modem]]
*[[Intel PRO/100 SP Mobile Combo Adapter]]
*[[Mini-PCI Ethernet card]]
*[[Xircom 10/100 EtherJet Mini PCI Adapter with 56K Modem]]

In addition, this chip is integrated into select systemboards of the following machines:<br>
'''Intel 82550GY'''
* {{R30}}
'''Intel 82558'''
* [[SelectaBase PC Card Enabler with Advanced EtherJet]]
* [[ThinkPad Port Replicator with Advanced EtherJet]]
'''Intel 82562ET'''
* {{R31}}, {{R32}}
* {{T30}}
* {{X30}}
'''Intel 82562EZ'''
* {{R40}}, {{R50e}}, {{R50}}, {{R51}}
* {{T40}}
* {{X31}}

Driver: [[e100]] (The 'e100' driver is the suggested driver, but '[[eepro100]]' should also work.)

=== Intel Gigabit (10/100/1000) ===
Chipset: Intel PRO/1000 MT Mobile Ethernet<br />
Driver: [[e1000]]

This chip is integrated into select systemboards of the following machines:<br>
'''Intel 82540EP'''
* {{R50}}, {{R50p}}, {{R51}}
* {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}
* {{X31}}, {{X32}}
'''Intel 82541GI'''
* {{X40}}
'''Intel 82573L''' (PCI-Express)
* {{T60}}, {{T60p}}
* {{X60}}, {{X60s}}
Note: This chip supports Auto-MDIX, meaning you will never need a crossover ethernet cable.<br>
Note: The first signs of explicit support for this chip in 2.6 kernels is with 2.6.12-rc2.<br>
Note: Red Hat Enterprise Linux 3.0 (2.4 kernel based) begins 82573L support with Update 7.<br>
Note: Some users report issues: [[Problem_with_e1000:_EEPROM_Checksum_Is_Not_Valid]]<br>
Note: Some users have reported [http://forum.thinkpads.com/viewtopic.php?p=201279&sid=787564d7cf9de5d7d76b0cb312a98c61 latency problems] with e1000 driver. It seems, that [http://agenda.clustermonkey.net/index.php/Tuning_Intel_e1000_NICs switching off Interupt Throttle Rate (ITR)] helps. <br>
Note: [http://support.intel.com/support/network/sb/CS-009209.htm Additional configuration options from Intel]

For Gentoo users - compile e1000 as a kernel module and add 'options e1000 InterruptThrottleRate=0,0' to /etc/modules.d/e1000

=== Broadcom Fast Ethernet (10/100) ===
Driver: [[tg3]] or [[bcm5700]]

This chip is integrated into select systemboards of the following machines:<br>
'''Broadcom BCM5901'''
* {{G40}}, {{G41}}
* {{R40e}}
'''Broadcom BCM5751F'''
* {{R51e}}

=== Broadcom Gigabit (10/100/1000) ===
Chipset: Broadcom BCM5751M<br>
Driver: [[tg3]] or [[bcm5700]]

This chip is integrated into select systemboards of the following machines:
* {{R52}}, {{R60}}
* {{G41}}
* {{T43}}, {{T43p}}
* {{X41}}, {{X41T}}
* {{Z60m}}, {{Z60t}}
* {{Z61m}}, {{Z61p}}

Note: There are some problems with the driver since kernel 2.6.17 (at least on a Z61p, Z61m). After an ifdown && ifup it doesn't work anymore (Reboot required). The T43 with a stock Linus 2.6.18.1 kernel does not have any problems.

[[Category:Components]]

Talk:Problems with SATA and Linux

2006-11-11T17:42:43Z

Theclaw: libata.atapi_enabled didn't work, #define ATA_ENABLE_PATA worked!

__TOC__

I'm running gentoo on my T43; I had problems with X11 (opensource radeon driver) and a SATA-patched kernel (I tried both 2.6.14 and 2.6.15-gentoo). Suspend to RAM worked nicely, but starting X freezed the machine after a short time. I tried removing radeonfb from the kernel; with vesafb, everything seems to work.

-- Stefan, 10 Jan 2006

--------
That's strange - with the libata passthrough (IDE driver not in kernel) as set up in the text, my t43p DVD drive also will not record as hinted in the wikipage... DMA works fine, so DVD playing / ripping is smooth and quick. CD record functions also are absent. I have PATA enabled, and the suspend + SMART patches applied over 2.6.14.2.
--------
I can confirm this with 2.6.14.4, however with 2.6.15/15.1 with sata_pm patch it works.

-- Rasto, 24 Jan 2006

--------
regarding the "BIOS error 2010 on user-installed hard disk":
the text says that corruption occurs if you use a harddisk without the specific ibm bios. would be interesting if it is possible to fix this problem in the kernel so that you can use any disk and the kernel doesn't use specific ATA commands which are known to cause problems.

in the tabook i didn't find any specification of the SATA bridge. it would be interesting:
1) what type it is
2) if it is fixed on the mainboard or if it is possible to solder in a new one

----

Another interesting question is whether these ThinkPads can be hacked to accept a real SATA system disk, by bypassing the SATA-to-PATA bridge (this would probably involve some soldering and cutting). If the BIOS can also handle that then it may come in handy, since some new high-capacity 2.5" disks have only SATA versions.
--[[User:Thinker|Thinker]] 02:56, 8 Oct 2005 (CEST)

----

'''Z series'''

Since the Z series uses a SATA controller and disk, without the bridge, would it be possible to make SATA ATAPI support as a module that you could load only when using the optical drive? Then, for everyday use, the experimental options of PATA and ATAPI with ata_piix would not be needed, moving you one step further in the direction of stability.

----

I have an R52 with Ubuntu Breezy and no problems with SATA (I personally asked the developers to include the needed patches).

However, I'd like to know wheter there are any advantages with this configuration. Future proof? Power saving? Speed?

Anybody cares to comment?

-- [[User:Micampe|Michele]]

Straight SATA, like in the Z60m/t, will provide better upgrade options in the long run (the hard disk industry is slowly but surely moving to SATA), and maybe a small performance increase if your drive, controller and OS support command queueing (they probably don't). However, with the hybrid ThinkPad models that use a SATA-to-PATA bridge, like your R52, you get all the drawbacks and none of the benefits; plus there's the horrible issue with [[Problem with non-ThinkPad hard disks|drive compatibility]]. My impression is that Lenovo did this just as a convenient (for them!) transition path, in order to use new chipsets without comitting to (temporarily) scarcer and more expensive drives. In any case, they didn't even have the decency to make the UltraBay Slim accept SATA drives.

--[[User:Thinker|Thinker]] 18:10, 3 Nov 2005 (CET)
----
There is a [[UltraBay Slim SATA HDD Adapter]], but only compatible with the Z series (at least for the moment).

--[[User:Tonko|Tonko]] 03:12, 4 Nov 2005 (CET)
----

Is it possible to enable AHCI on the Z60m? There doesn't seem to be an option for it in the BIOS, even after updating to the latest BIOS version (1.19). I don't think it's enabled by default since the "ata_piix" driver finds my controller and the "ahci" driver doesn't.

--[[User:Wyzard|Wyzard]] 06:06, 12 August 2006 (CEST)
----

Ok, I got it working with compatibility instead of AHCI (X60s) but I would like to know whats the difference between those two? Anybody with a quick explanation?

@Wyzard: AFAIK you have to switch it within BIOS and if you can't then you can't use ata_piix.

--[[User:elm|elm]] 16:46, 12 August 2006 (CEST)

== updated libata_passthru.patch ==

FYI: when using the Suspend-to-RAM patch from http://lkml.org/lkml/2005/9/23/97 against 2.6.14 the libata_passthru.patch from the article doesn't apply any more, so I've put up an updated version at http://linux.spiney.org/system/files?file=02_libata_passthru.fixed.patch

I give no warranties whatsoever whether it works or kills your hardware, but since I just removed duplicate parts already in the Suspend-to-RAM patch it should be ok.

--[[User:spiney|spiney]] 19:04, 4 Nov 2005 (CET)

Hi

Running 2.6.16-rc4 and I'm running into scsci errors and Input/output
errrors when resuming from suspend to ram. The suspend patch is
supposed to be in 2.6.16-rc1 and I'm booting with

title= 2.6.16-rc4
root (hd0,0)
kernel /boot/kernel-2.6.16-rc4 root=/dev/sda3 ro combined_mode=libata
libata.atapi_enabled=1 acpi_sleep=s3_bios processor.max_cstate=2
elevator=cfq ide1=noprobe

Thanks.

----

Don't know about -rc4, but -rc3 worked without problems, could you try that one instead? Maybe there was some bug introduced between these two versions. What's combined_mode=libata BTW?

--[[User:Spiney|spiney]] 08:28, 23 February 2006 (CET)

== ATA_ENABLE_PATA PCI IDs ==

Spiney, could you extend the article to explain what and why are the PCI IDs in the footnote about ATA_ENABLE_PATA?

--[[User:Thinker|Thinker]] 21:59, 4 Nov 2005 (CET)
----

Ok, done, feel free to fix the table because I'm a bit struggling with Wiki-style editing. ;) As for the why, those PCI IDs are the only ones affected by the ATA_ENABLE_PATA, as seen in {{path|drivers/scsi/ata_piix.c}} in the kernel source.

--[[User:spiney|spiney]] 11:19, 5 Nov 2005 (CET)
----

Will other cards work without ATA_ENABLE_PATA, or just fail? In the former case your instructions are right, but in the latter case we should tell the user to check the list of IDs in his ''current'' kernel and, if there's no match, to give up in the first place instead of following the rest of the instructions.

--[[User:Thinker|Thinker]] 12:48, 5 Nov 2005 (CET)
----

AFAICT if the chipset is supported by libata it will work, regardless of what low-level driver is used. Of course if there is no low-level driver for the chipset then even using the harddisk via libata will fail, but that's a different story. At least ATA_ENABLE_PATA will then make no difference since it's Intel PIIX (and compatible) only.

--[[User:spiney|spiney]] 13:24, 5 Nov 2005 (CET)
----

Not sure I got you. Is there any case where the instructions will work without ATA_ENABLE_PATA, given that all ThinkPad optical drives are PATA?

--[[User:Thinker|Thinker]] 13:41, 5 Nov 2005 (CET)
----

The instructions will work without ATA_ENABLE_PATA unless the Thinkpad uses one of the three chipsets listed in the article, as long as libata works at all, i.e. the system drive shows up as /dev/sda. The #define doesn't change the behaviour of libata for any other chipset, it's [http://linux.yyz.us/sata/sata-status.html#ich5 ata_piix] only.

Since I don't have a machine with one of the three chipsets (anyone?), I can't tell whether those work at all with libata, but I guess there's a reason why they're not enabled by default. It's just that defining ATA_ENABLE_PATA is only making sense for these three chipsets.

Any clearer now? If not, just run {{cmd|grep -r ATA_ENABLE_PATA /path/to/kernelsource|}} and see how seldom and where the #define is used.

--[[User:spiney|spiney]] 14:55, 5 Nov 2005 (CET)
----

All clear now. I thought it will work only if you have these chipsets ''and'' ATA_ENABLE_PATA=1. Thanks for the explanation!

--[[User:Thinker|Thinker]] 15:12, 5 Nov 2005 (CET)
----

Does any of the relevant ThinkPad models (listed in the article) use these chips? They look too old to be found on the SATA models.

--[[User:Thinker|Thinker]] 23:35, 9 Nov 2005 (CET)
----

I don't think so, I was about to add "in the unlikely event that you own one of these chipsets" or something.

--[[User:Spiney|spiney]] 07:56, 10 Nov 2005 (CET)
----

== DVD DMA with ide/sata as module ==

Did anyone get DVD DMA to work with either the IDE or SATA drivers compiled as modules? If so, please fill in the missing details in that section. I have it working only with both IDE and SATA built-in.

--[[User:Thinker|Thinker]] 17:58, 16 Nov 2005 (CET)
----

Basically using a Live-CD with a recent kernel (is there one with 2.6.14 already?) would be sufficient, since they usually use an initrd or something similar, don't they? I'll give the Debian distribution kernel a try when I get around to it (bit busy atm), after all there's 2.6.14 in sid.

But for people using their own kernel compiled from source I see no point in doing the module+initrd thing anyway, unless you want LVM for the root filesystem or other funky stuff.

--[[User:Spiney|spiney]] 19:22, 16 Nov 2005 (CET)
----

Hi

Can anyone tell me how those modules are called?

Thomas
--[[User:Thomas|thomas]] 19:48, 23 Jan 2006 (CET)
----

Where the hell do I find the libata module?

--[[User:squashball|squashball]] 09:09, 11 June 2006 (CET)

The relevant driver is called ata_piix. The ata_piix driver uses a chunk of shared kernel code called libata.

--[[User:Thinker|Thinker]] 09:33, 11 June 2006 (CEST)

Ok, Thanks. Nevertheless I am not able to get my drive working. It's a T60...

--[[User:squashball|squashball]] 12:29, 12 June 2006 (CET)

Your T60 uses AHCI by default. You have to change the BIOS settings to "compatibility mode" to use the HDD and DVD drive with ata_piix. Then, you're also able to hotswap your ultrabay. But for this, a patch for ibm_acpi is needed.

--[[User:Whoopie|Whoopie]] 14:57, 12 June 2006 (CEST)

Yeah, thanks, it's working now! Where was I supposed to find this info?
EDIT: But DMA is still off and can't be enabled.

--[[User:squashball|squashball]] 07:58, 13 June 2006 (CET)

DMA is enabled by default with libata. Do a "dmesg |grep DMA" and you'll see. You can't use hdparm to see the settings for your hdd. BTW, if you have more questions, you could join IRC ##ibmthinkpad.

--[[User:Whoopie|Whoopie]] 11:04, 13 June 2006 (CEST)
----

== occasional hang upon resume with various kernels ==

I keep having trouble with resume after suspend to ram. Occasionally, it takes longer to wake up and then is in a semi-hanged
state, i.e. nothing having to do with actual reading from the disk works. (what was running, as aterm
is still running, ls works, when the listing is buffered, but hangs if it is not).
Kernel is 2.6.15 with sata-pm patch. Later 2.6.15 kernels hang always and it's the same with 2.6.16.
Could perhaps somebody, for whom it works without problems post his .config somewhere?
I'm out of ideas.

--[[User:Rasto|Rasto]] 14:46, 20 March 2006 (CET)

I have the same problem with my x41 and 2.6.16 or 2.6.16-r1 running on Gentoo. Sometimes resume is ok and sometimes the disk doesn't resume. I can't see any log because the disk is unwritable after resume. The logs on F12 is full of io error.
I tested many different kernel configs, unloading modules before suspend, stopping services...
Like Rasto, I'm out of ideas...

--[[User:Pplr|Pplr]] 19:21, 8 April 2006 (CEST)

You could try http://rtr.ca/dell_i9300/kernel/kernel-2.6.16/02_libata_resume_fix.patch
This patch worked for me.

--[[User:Whoopie|Whoopie]] 21:21, 8 April 2006 (CEST)

Hello, according to the first lines of the article, resume does not work prior to kernel 2.6.16, i.e. the computer hangs up just a second after it comes back. I just switched from 2.6.15 to 2.6.16 but the problem still remains. I have a Z60M thinkpad. So this has obviously the same problem as the T60.

-- [[User:Bjoern.thalheim|BjÃ¶rn]] 14:37, 10 April 2006 (CEST)

Increasing the timeouts seems to do the trick. I applied it about two weeks ago, and it works since.

-- [[User:Rasto|Rasto]] 09:59, 11 April 2006 (CEST)

Ubuntu Dapper with 2.6.15-23 is also exhibiting this problem even though the sata_pm patch is applied. Bjorn, which timeout are you referring to?

-- [[User:nmuntz|nmuntz]] 09:08, 13 June 2006 (MDT)

== Suspend to RAM on X41 not working with Debian-packaged 2.6.16 ==

I just tried the Debian package of the Linux 2.6.16 kernel on my [[X41]] to see if suspend-to-RAM would work. Unfortunately, it didn't. The laptop suspends just fine, but when it's turned back on, the backlight remains off, there is a lot of disk activity for a while, and then the computer just shuts off. When turned on again, it boots normally. Suspend-to-disk works fine, just like before.

On a different note, CPU throttling broke on my system with the new kernel. I can no longer modprobe acpi-cpufreq. [[User:Ehn|Ehn]] 04:28, 22 March 2006 (CET)

:The latter issue was solved by using speedstep-centrino instead of acpi-cpufreq. [[User:Ehn|Ehn]] 23:25, 9 April 2006 (CEST)
----

Neither problem is related to this article, so it's unlikely to be answered here.

--[[User:Thinker|Thinker]] 17:37, 22 March 2006 (CET)
----

Hm. It seems to be a problem with sata power management for me, so I guess this could be one of the places.

[[User:Rasto|Rasto]] 17:45, 22 March 2006 (CET)
---

Ehn, by "disk activity" do you mean a constantly on HDD LED and no disk movement noises, or ''real'' disk activity with the LED flashing and disk noise? The former is likely to be the SATA problem, the latter rules out the SATA problem.

--[[User:Thinker|Thinker]] 18:44, 22 March 2006 (CET)

:The latter. There is real disk activity, indicated by LED flashing <em>and</em> disk movement noise, for about 30 seconds, before the machine gives up and shuts down. If this is not SATA-related, what might it be? [[User:Ehn|Ehn]] 23:23, 9 April 2006 (CEST)

----

Sorry, I didn't realize Ehn has two problems, and I considered your post as aimed at my and Ehn's. Never mind then.

[[User:Rasto|Rasto]] 10:47, 23 March 2006 (CET)

== Problem with 2.6.16 ==

ok, seems like we have a new problem:
After upgrading from 2.6.15 to 2.6.16 my DVD device is not recognised anymore by libsata.
The only way to get working is by using the ide layer - without DMA of course.
Can anyone confirm this?

--[[User:Defiant|Erik]] 17:49, 23 Mar 2006 (CET)
--------

Try the kernel parameter '''combined_mode=libata''', does this help? Also, have you enabled libata's ATAPI support as described in the article?

--[[User:Thinker|Thinker]] 20:31, 23 March 2006 (CET)
----

Yes, I'm using the command line parameter libata.atapi_enable=1 - up to 2.6.15 it works fine.
About the combined_mode parameter: Also tried it, though the Author of this patch mentioned that the default behavior did not changed.
I will continue hungting this problem when I find some time.

--[[User:Defiant|Erik]] 7:12, 24 Mar 2006 (CET)
-----

I can confirm Eriks problem. After updating to 2.6.16 I have it, too. libata.atapi_enable=1 is still on kernel command line. With some help of Michael Ott I figured out that this only happens if you have the current suspend2 patches applied.
Using a vanilla 2.6.16 works as expected.

--[[User:Mobst|mobst]] 14:30, 24 Mar 2006 (CET)
-----

Ahh thanks. Finding the problem in the suspend2 patch should be an easy task.
I just hope for some free time this weekend!

--[[User:Defiant|Erik]] 18:31, 24 Mar 2006 (CET)
-----

Uhm, looks like [[ZolnOtt|ZolnOtt]] was faster, he added the note to
http://thinkwiki.org/wiki/Problems_with_SATA_and_Linux#No_DMA_on_DVD_drive

--[[User:Defiant|Erik]] 20:02, 24 Mar 2006 (CET)

== Patch against SATA-resume problem with T60 ==

I only have a Fujitsu-Siemens C1320, but I had the same problem with resuming from suspend with a SATA disk and kernel 2.6.16 as mentioned for the T60. I solved the problem for me by merging several patches (patches.fixes/libata-increase-timeout-for-resume, patches.fixes/ahci-suspend, patches.fixes/ahci-atapi-sense-request, patches.drivers/libata-acpi-suspend, patches.fixes/libata-resume-drive_port-mode, patches.fixes/ahci-init-on-resume, patches.drivers/libata-device-spindown)
from the OpenSuSE kernel 2.6.16-12 to vanilla 2.6.16.5. You'll find my patch at http://www.spinnaker.de/linux/c1320/sata-resume-2.6.16.5.patch. I expect this to solve the T60 problem, so I provide the patch here, as this wiki helped me so much with my laptop.

--[[User:Rrosenfeld|Rrosenfeld]] 23:12, 16 April 2006 (CEST)

I just want to let you know that I managed to get Suspend-to-RAM working on the T60. I'm using Gentoo's suspend2-sources-2.6.16-r2 as base and applied the above patches from Rrosenfeld (thanks!) and additionally this [https://bugzilla.novell.com/attachment.cgi?id=75844&action=view one] (here the corresponding [https://bugzilla.novell.com/show_bug.cgi?id=162090 bug]).

--[[User:Sts|sts]] 22:52, 17 April 2006 (CEST)

same here. applied both patches to gentoo suspend-sources-2.6.16-r5 --- working. sweet.

--[[User:Husemann|dr who]] 21:51, 3 May 2006 (CEST)

however: powersave (powersaved) is a spoiler: it will cause the resume operation to get stuck at "reading back caches" and eventually result in a kernel panic. stopping powersaved before hibernating does not prevent it: it seems that running powersaved just once will screw things up. interesting and nasty. but not a show stopper (IMHO).

--[[User:Husemann|dr who]] 17:14, 10 May 2006 (CEST)

that's not powersaved's fault. kernel panics are always kernel (or hardware) bugs. i experienced this kind of lockups when using different cpufreq governors at once (that's probaly something one shoudln't do?). i'm now using only cpufreq_userspace and don't have any problems.

--[[User:Sts|sts]] 15:11, 11 May 2006 (CEST)

Having exactly the same SATA wakeup problem on my Z60t, using FC5. Can the patch from rosenfeld be applied also to the FC5 kernelsource?

--[[User:SzentivÃ¡nyi|szenti]] 21:29, 11 May 2006 (CEST)

Latest fedora (FC5) 2.6.17-1.2139_FC5smp kernel solved the problem on my T60p. I have successfully resumed a number of times now.

--[[User:Gfbarros|Guil]] 20:38, 27 June 2006 (CEST)

Vanilla 2.6.17.8 lets me suspend and resume on a T60p. But I had to set the SATA mode to Compatibility (ata-piix) in the BIOS. The other catch is that if you suspend from a console rather than X, you get a black screen. Fn-F7 back to X gets your display back. Of course, if you don't have X up, you're kind of stuck and the safest thing to do is to tell the machine to reboot. The keyboard still works, so you have to type blind.

--jlquinn 17 Aug 2006 (signature button didn't work properly)

jlquinn: see [[How to recover from corrupted textmode]].

--[[User:Thinker|Thinker]] 17:20, 17 August 2006 (CEST)

By giving the kernel the option acpi_sleep=s3_bios I've managed to get suspend to work from the console mode - though I still have the SATA-problem. I'm running the gentoo kernel 2.6.17-r8, and will now try the tips from jlquinn...

--[[User:Tobixen|Tobixen]] 14:15, 10 October 2006 (CEST)
----

== removal of cd/dvd problems rambling? ==

Should we remove the ramblings that are now the last section of the page? That's just generic information on how to properly use cdrecord (and it is incomplete and incorrect to add insult to injury...). If you use libata with ATAPI enabled and a new kernel, it *just works*, as the drive will look like a 100% SCSI device to cdrecord...

--[[User:Hmh|hmh]] 06:12, 4 October 2006 (CEST)

Agreed.
--[[User:Thinker|Thinker]] 14:01, 4 October 2006 (CEST)

== libata.atapi_enabled didn't work, #define ATA_ENABLE_PATA worked! ==

Hi there, I own a Thinkpad Z61m (fairly new), using a kernel which doesnt include IDE support (2.6.18.2). The libata.atapi_enabled=1 option didn't work, which means only the Hard Disk, and not the DVD-drive got recognized. However, adding ATA_ENABLE_PATA ''did'' work, now I don't need any option at all to modprobe.conf/bootloader config! lspci says: "IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)" PCIID: 8086:27df

May be useful for somebody :) Bye! --[[User:Theclaw|Theclaw]] 18:42, 11 November 2006 (CET)

Hidden Protected Area

2006-11-10T21:11:08Z

Theclaw:

{| 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:#F8F8FF; align:right;">
=== The Hidden Protected Area ===
The Hidden Protected Area (also known as the Host Protected Area and as the Predesktop Area) is a special area (usually a few gigabytes in size) located at the end of a hard disk. It is preinstalled on the harddisks of some ThinkPads. It is normally hidden to the software running on your ThinkPad. It includes all the software and data needed to recover the preloaded state of the ThinkPad. The HPA also includes some diagnostic tools and a (MS Windows only) backup tool.

The HPA was introduced with the R/T/X 40 series of ThinkPads. It is refered to as the Predesktop Area in the BIOS Setup Utility. Recent ThinkPads can have a (hidden) partition that is also called [[Predesktop Area|Predesktop Area]] in the BIOS Setup Utility. That (hidden) partition is not an HPA. More information can be found in [[Rescue and Recovery | Rescue and Recovery]],
</div>
|style="vertical-align:top;padding-right:10px;width:10px;white-space:nowrap;" | [[Image:hpa.jpg|IBM PreDesktop Area]]
|}

==General information about the HPA==
As opposed to [[Rescue and Recovery|Recovery Partitions]], Protected Service Areas (PSAs) such as the HPA are (let's say) images of partitions written to the end of a harddisk. They are only accessible through their BEER. The general idea is that, under control of the BIOS, the PSAs are totally hidden from all ordinary software, including malware (viruses, trojans, spyware). They are only accessible when permitted by the BIOS, and even then only through special HPA-aware tools. Under GNU/Linux they are only accessible with low level tools like dd.

The HPA is based on [http://www.phoenix.com/en/Products/Trusted+Applications/Phoenix+FirstWare/default.htm Phoenix FirstWare]. FirstWare is (in short) an implementation of two technologies: BEER and PARTIES. (Yes, those names are correct!) BEER (Boot Engineering Extension Record) and PARTIES (Protected Area Run Time Interface Extension Services) are described in [http://www.t13.org/project/d1367r3-PARTIES.pdf this T13 working draft]. There is a more general introduction to PARTIES on the [http://www-1.ibm.com/support/docview.wss?rs=0&uid=psg1MIGR-51248&loc=en_US IBM site]. FirstWare depends on certain [http://en.wikipedia.org/wiki/Advanced_Technology_Attachment#ATA_standards_versions.2C_transfer_rates.2C_and_features ATA-5] commands, so it won't work with lower ATA level (earlier) drives or even with all ATA-5 drives. Unfortunately, there is no public HPA compatibility tester or list of compatible drives.

Basically, what's going on is that the Phoenix BIOS commands the drive to hide the last few gigabytes of the hard disk (the HPA). The to non-HPA aware software, the drive appears to have a smaller size. Note that this is just a setting in the BIOS and can be disabled. The HPA can be accessed by pressing {{ibmkey|Access IBM|#495988}} or {{key|Enter}} at boot time. The BIOS will then parse the BEER (128 bytes, situated in the last sector of 512 bytes of the harddisk) and the "Directory of Services" (consisting of directory entries of 64 bytes each, starting in the last sector and spilling over into the previous sectors) to see what part of the HPA should be launched. In (most?) ThinkPads the BEER tells the BIOS to launch the Access IBM Predesktop Area. The system will then actually be booting into a (minimal) DOS environment which is able to launch a graphical shell (called Phoenix FirstSight). IBM has simply rebranded this graphical shell to the Access IBM Predesktop Area. From this graphical shell one can launch several tools (BIOS Setup Utility, diagnostic tools, recovery tools).

==Three BIOS options==
The BIOS has three settings for the "IBM Predesktop Area" (in the Security category):
*Secure: No user or SW-initiated changes; Contents hidden from OS
*Normal: Change allowed; Contents hidden from OS
*Disabled: Not Usable; Visible and Reclaimable

Normal is the default setting. One can boot into the Predesktop Area when either Secure or Normal is set. When Disabled is set the Predesktop Area will not boot. According to the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46023 Predesktop Area white paper] the HPA is both "locked"{{footnote|1}} and "hidden" when Secure is set and only "hidden" when normal is set. In practice the result seems to be that the HPA is totally unavailable to the Linux kernel (and therefore all applications) when Secure is set. (The HPA should be unavailable in "Secure mode" for all operating systems, MS Windows included.) One would expect the HPA to be only accessable to HPA aware tools when Normal is set. However, recent kernels disable the HPA by default when Normal is set. Note that [http://marc.theaimsgroup.com/?l=linux-ide&w=2&r=1&s=Host+protected+area&q=b recent threads on linux-ide] suggest that the ThinkPad will reenable the HPA on resume and thus causing (possibly serious) conflicts with the GNU/Linux system (that assumes the HPA is still available).

With Disabled you should be able to safely reclaim the area used by the HPA (to GNU/Linux it basically is unallocated space on the harddisk).

==Details of the HPA==
Fabrice Bellet describes a [http://bellet.info/laptop/t40.html#the_predesktop_area technique he used] to explore the HPA of his ThinkPad T40, using GNU/Linux tools. This technique is only for the more curious or more careless people. It uses "dd" to copy the sectors on the harddisk containing the HPA from "/dev/hda" to a new file: when using "dd" on "/dev/hda" you are only one small typo away from an unrecoverable disaster!

Here follows a more detailed description of the HPA on a ThinkPad T41 (60 GB harddisk) to contrast his findings.

On this ThinkPad T41 the HPA is 3,4 GB in size. It contains 8 consecutive PSAs (Protected Service Areas). Six of those start with an x86 boot sector.

* The first PSA is 3,2 GB in size. The OEM-ID of the boot sector is: "IBM 7.1". It seems to hold a copy of the preloaded OS and everything needed to generate a bootable DVD-ROM for it, even an El Torito boot image and a boot catalog: see [[Backing up the preloaded OS]].

* The second PSA is exactly 2 MB in size. According to its entry in the Directory of Service it's the "BIOSWORKAREA".

* The third PSA is only 7,4 MB in size. The OEM-ID of the boot sector is: "MSWIN4.1". It seems to be an image of a 1,44 MB bootable floppy disk (with MS DOS) and a directory containig 6 MB of FirstWare tools. It will be launched by the "Recover to factory contents" tool of the Predesktop Area. Those "factory contents" should be the data on the first PSA.

* The fourth PSA is only 1,4 MB in size. The OEM-ID of the boot sector is: "IBM 7.1". It too seems to be an image of a (sort of) 1,44 MB bootable floppy disk. It will be launched by the "Restore your backups" tool of the Predesktop Area.

* The fifth PSA is again 7,4 MB in size. The OEM-ID of the boot sector is: "IBM 7.0". It will be launched by the "Run diagnostics" tool of the Predesktop Area.

* The sixth PSA is also 7,4 MB in size and the OEM-ID of the boot sector also is: "IBM 7.0". It will be launched by the "Create diagnostic disks" tool of the Predesktop Area. It contains a copy of a (sort of) bootable 1,44 MB floppy disk, some tools and compressed copies of the diagnostic disks.

* The seventh PSA is only 1,4 MB in size. The OEM-ID of the boot sector is "PHOENIX". It seems to be a copy of a (sort of) 1.44 MB bootable floppy disk too and only contains a (minimal) DOS and the FirstSight application. Basically, this is the Access IBM Predesktop Area.

* The eigth PSA is 101 MB in size. It doesn't have a boot sector. It contains the FirstWare Reserved Area. That probably is some sort of swap space for the FirstWare system.

==Accessing the HPA from Linux==
While Fabrice Bellet's method, described in the previous section, works in many cases, it has some serious flaws. The most important one -- is that each PSA has to be formated (i.e. has to posses a filesystem), and the size this filesystem has to be equal to the size of the PSA. If the HPA has some sort of a swap partition, or the filesystem size is a few megabytes less than the PSA's size, then we will not be able to find any following PSA(s).

A more systematic approach would be just to use the BEER record to find the exact LBA addresses of all PSA(s). The idea is to use the [http://www.t13.org/project/d1367r3-PARTIES.pdf T13 working draft] of the BEER specs. There is some serious discussion on this matter going on in [[Talk:Predesktop_Area|Talk:Predesktop_Area]], but so far they didn't release any code to the public. As an interim solution, we can use a free open-source [http://colimit.googlepages.com clone of the Phoenix utility fwdir]. If we first disable the "IBM Predesktop Area" in BIOS (which, essentially, sends appropriate SETMAX command to the harddrive), then the whole harddrive will be accessible from the userspace. Now, if we run fwdir, a typical output of this utility would look like
<div>
# ID Name 1st Sector Sectors Sec Icon Flag

0 0000h FirstWare Reserved Area 234231736 204800 0 00h 03h
1 0001h CONSOLE 234170510 61226 0 FCh 01h
2 0140h Recover Pro 234088523 81987 0 00h 01h
3 0104h Factory Restore 234085638 2885 0 03h 03h
4 0120h RADA Data 234020102 65536 0 00h 02h
5 0108h Factory Data 230026502 3993600 0 00h 02h
6 0141h Recover Pro Records 229616902 409600 0 00h 02h
</div>
Once we know all the LBA addresses of the first sectors of all PSA(s) and their sizes, we can extract any particular PSA. E.g. the "Factory Data" PSA in this example can be extracted with
<div>
dd if=/dev/hda of=/tmp/FacDat.img skip=230026502 count=3993600
</div>
But if we are only interested in the contents of this PSA partition, there is no need to extract it to a file and later mount it through a loop-device. It can be done right away with
<div>
mount /dev/hda /mnt/fwdata -t vfat -o ro,offset=`expr 512 "*" 230026502`
</div>
Of course, there is no way to know in advance which particular filesystem each PSA has (if any). This still has to be found by trial and error (because "mount -t auto" does not always work). In the above example, the "CONSOLE" PSA is formated in ext2.

==How to reclaim the HPA==
After disabling the "IBM Predesktop Area" (with the BIOS option "Disabled", see above) it's possible to reclaim the area used by the HPA. Then one can include that area in a partition with standard tools (i.e. fdisk, mkfs) as it will be treated just as regular free space of the hard disk.

==Alternative uses?==
It might be possible to use the FirstWare tools included in the HPA to make the HPA more useful for GNU/Linux purposes. For instance, the copy of the preloaded OS could be replaced with an emergency backup of your GNU/Linux distribution. Maybe the Predesktop area could be even used to boot into a GNU/Linux rescue system. Whether the Phoenix proprietary tools really allow alternative uses and whether those tools do not make it too hard to accomplish those cannot yet be said. It seems realistic to assume that the benefits of those alternative uses aren't worth the effort to accomplish them. Still, it might be fun (altough possibly hazardous to your system) to try ...

==Problems caused by the HPA==
As of Linux 2.6.18, having a HPA may cause errors when resuming the laptop from suspend-to-RAM or suspend-to-disk. See the section called "SectorIdNotFound disk errors when laptop is resumed" in [[Problems with ACPI suspend-to-ram | ACPI suspend problems]].

==External Sources==
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46023 Predesktop Area white paper]
*[http://www-3.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46025 Predesktop Aministrator Utility (DOS)]
*[http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+346-2001 Protected Area Run Time Interface Extension Services (PARTIES) ANSI INCITS 346-2001 ($30)]
*[http://www.t13.org/project/d1367r3-PARTIES.pdf The latest free draft of ANSI INCITS 346-2001 (BEER specs)]
*[http://www.phoenix.com/NR/rdonlyres/7465D3CF-B0E3-4F64-9122-47D9C83028D0/0/cme_firstware_wp.pdf Phoenix FirstWare White Paper]
*[http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html Section 11 of the Large Disk HOWTO (Clipped disks)]

==Models featuring this Technology==
*ThinkPad {{R40}}, {{R40e}}, {{R50}}, {{R50e}}, {{R50p}}, {{R51}}, {{R52}}
*ThinkPad {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}
*ThinkPad {{X31}}, {{X32}}, {{X40}}, {{X41}}, {{X41T}}
*ThinkPad {{Z61m}}

{{footnotes|
# Presumably by having the BIOS use the SET MAX security extension. The BIOS seems to set a password for the HPA at boot (using the SETMAX-SET PASSWORD command) and after that use that password to issue a SETMAX-LOCK command. Since the password is unknown (and most likely changes at every Secure boot) the HPA is inaccessable to all programs running on the ThinkPad.<BR><BR>Something similar would be possible running in Normal mode. Then a program could issue the SETMAX-SET PASSWORD command. At the moment there's no program running under GNU/Linux capable of doing that. Of course this is possibly less secure: it's (theoretically) possible that other (rogue) programs get hold of that password.
}}

[[Category:Glossary]]

Rescue and Recovery

2006-11-10T21:10:41Z

Theclaw:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
===Rescue and Recovery===
Rescue and Recovery version 3.0 consists of a bootable partition containing various system recovery tools, including full recovery of the preinstalled Windows XP partition. It can be activated by pressing the {{ibmkey|ThinkPad|#494949}}, {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkVantage|#495988}} [[ThinkPad Button|Button]] during system boot. It contains a FAT filesystem (labeled "IBM_SERVICE"), and has partition type 0x12 ("Compaq diagnostics" in <tt>fdisk</tt>).

As opposed to a [[Hidden Protected Area|Hidden Protected Area]] Recovery partitions are ordinary partitions, accessible through the partition table. As they are ordinary partitions they are accessible by ordinary partitioning tools. They should be dealt carefully with.
</div>
|}
==Proper MBR==
{{WARN|Only tinker with the MBR and the Rescue and Recovery partition if you know what you're doing. Mistakes can leave the system unbootable and can make it very difficult to retrieve the data on the harddisk.}}

Consideration 6 of the Readme states:
<blockquote>"The Master Boot Record (MBR) must be configured properly for the Rescue and Recovery application to function properly. When possible, the Rescue and Recovery application attempts to ensure the proper configuration of the MBR. This can only occur if the Rescue and Recovery application is installed after other applications that requires the MBR."</blockquote>

Apparently, the MBR is not "configured properly" if LILO or GRUB have written it. The following is the case:
*the default bootloader seems to ignore the active bit and always boots the first partition instead
*the default bootloader contains code to catch a press of the appropriate button during bootup and launch the Rescue and Recovery application in that case
*before launching the Rescue and Recovery application at system boot, the default bootloader changes the partition type of the Rescue and Recovery partiton to 0x0b, otherwise it changes it to 0x12 (to hide it from Windows)
*the Rescue and Recovery application assumes that the first partition contains Windows
*the Rescue and Recovery partition needs to be of type 0x0b (FAT32) otherwise the default bootloader will not launch the Rescue and Recovery application

Since neither LILO nor GRUB catch the press of the button (an undocumented mechanism anyway) it is not possible to launch the Rescue and Recovery application by pressing the appropriate button during system boot, once LILO or GRUB have altered the MBR for their boot procedure.

IBM provides a program to manage the Rescue and Recovery bootloader. It is located in {{path|C:\Program Files\IBM ThinkVantage\Common\BMGR}} or {{path|C:\Program Files\Common Files\Lenovo\BMGR}}. It can select the partition to boot, and also allows for rewriting the MBR if it was written by another bootloader.

===MBR written by GRUB===
If the MBR was written by GRUB you can still use GRUB to launch the Rescue and Recovery application. However if you leave the type of the Rescue and Recovery partition to 0x12 (Compaq diagnostics), this will result in an error message "c000021a, Fatal System Error" if you try to launch it. To avoid that and to make sure the recovery partition always is of the right type, add a line to change the partition type to 0x0b to the Rescue and Recovery partition's entry in your {{path|/boot/grub/menu.lst}}. Assuming your Rescue and Recovery partition is the second partition, it could look like this:
title IBM Rescue and Recovery
root (hd0,1)
'''parttype (hd0,1) 0x0b'''
'''unhide (hd0,1)'''
chainloader +1

Also add an <tt>unhide</tt> line here because we are going to hide the Rescue and Recovery partition on every boot of Windows, so we need to unhide it, when the recovery partition is booted. This is because if we don't hide the partition when booting Windows, it would be visible and accessable there and that's not what we want. So, assuming that Windows is on the first partition, the Windows entry could now look like this:
title Windows
root (hd0,0)
'''hide (hd0,1)'''
chainloader +1

===GRUB in a partitions boot sector===
A way to have your Access IBM button still functional on bootup, is to create a separate {{path|/boot}} partition, install GRUB to that partition and make it active. This will leave the MBR untouched.
{{NOTE|If the above finding is true that the MBR ignores the active bit, that partition has to be the first one. In most recent Linux distributions it is not easy to create /boot as first partition and shrink the Windows partition. In that case the Windows bootloader can be used to boot Windows and Linux, also preserving the Rescue and Recovery functionality. See below.}}
*In the BIOS, set the IBM Predesktop Area to 'Secure'.
*Boot your Linux distribution's installation CD.
*Follow the instructions and go through the regular installation process.
*Create a '''primary partition''' for /boot (the other stuff can go into the extended partitions) and when the time comes to install GRUB, make sure you install it into the boot sector of the boot partition.
*Set this boot partition as active.

===Using NTLDR to boot Linux===
It is possible to configure the Windows bootloader to also boot Linux (installed on separate partition). This allows to preserve the Rescue and Recovery functionality at system boot (as MBR is not modified), Windows XP (booted via its native bootloader) and Linux (booted from its own partition by Windows XP bootloader). A quick and dirty howto, regarding applying this procedure to Ubuntu Dapper Drake installation can be found [http://gawrysiak.org/corvus/?p=4 here].

==Older versions of Rescue and Recovery==
Some Thinkpads (e.g., T23 and T30) do not come with a Recovery CD, but also do not support the [[Hidden Protected Area]]. These ThinkPads have an older version of Rescue and Recovery preloaded on the hard disk to implement the factory recovery function. Most of the comments above also apply to the older versions, with the following differences:
*The recovery partition type is 0x1c, hidden FAT32, LBA-mapped (or 0xc when unhidden).
*The boot manager program is in {{path|C:\IBMTOOLS\RECOVERY}} and only runs in a 16-bit DOS environment
{{Fixme|name of this boot manager needed}}
*The IBM Predesktop area runs atop of Windows 98 (command-line) instead of WinPE

==External Sources==
* IBM page on [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4Q2QAK ThinkVantage Rescue and Recovery].
* [ftp://ftp.software.ibm.com/pc/pccbbs/thinkvantage_en/tvtrnr3_1027en.txt Rescue and Recovery Readme]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46088 IBM page about accessing the Recovery Partition if Linux has been installed and the F11 button no longer works]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54483 IBM Rescue and Recovery repair diskette]

==Models featuring this technology==
* ThinkPad {{T23}}, {{T30}} (R&R 2.0)
* ThinkPad {{T42}}
* ThinkPad {{T43}}, {{T43p}}
* ThinkPad {{R52}}
* ThinkPad {{Z60m}}
* Thinkpad {{Z61m}}

[[Category:Glossary]]