ThinkWiki - User contributions [en]

Pentium M undervolting and underclocking

2007-11-24T05:50:24Z

Espa: /* Alternative 0: linux-phc */

== Background ==

Intel Pentium M processors from the [[Intel Pentium M (Dothan)|Dothan]] and [[Intel Pentium M (Banias)|Banias]] families can be instructed to operate at voltage and clock frequencies lower than the nominal ones recommended by Intel and used by ThinkPads by default. Experience shows that the processor may continue working correctly at lower-than-nominal voltages and frequencies, thereby reducing power consumption, heat and fan noise.

In the Pentium M, speed and voltage are controlled by software (through the MSR registers). It is up to the operating system to choose the right voltage for each frequency. Normally this is done according to tables published by Intel or according to ACPI tables. However, this can be overriden - in the case of Linux, by a kernel patch.

{{WARN|Following this instructions will operate your CPU under conditions it was not designed for. Even if your system seems stable, it may still suffer transient faults leading to arbitrary data corruption. In addition, errors in following these instructions (or changes between processor models) may operate the CPU ''above'' its nominal parameters, which, if taken too far, can cause kernel panics or even possibly hardware damage}}

For an example of what may be achieved, consider these examples: when voltages on one ThinkPad {{T43}} were reduced by 20-30%, stable CPU temperature dropped by 7-10deg under both idle and burn-in conditions. Combined with [[how to control fan speed|fan speed control]], this greatly reduced the [[Problem with fan noise|problem with fan noise]]. On one user's ThinkPad {{R51}}, an undervolt brought the full-load processor temperature down from 87 degrees to 63 degrees while maintaining full stability. The effect was, however, negligible at idle.

{{NOTE|While under''volting'' has a clear measurable effect, it's not clear if under''clocking'' really works. <tt>/proc/cpuinfo</tt> reflects the underclocked frequency, but enabling debug output on <tt>cpufreq</tt> causes it to say things like "<tt>CPU frequency out of sync: cpufreq and timing core thinks of 533000, is 800000 kHz.</tt>" where the former is the chosen underclocked frequency and the latter is the documented minimum frequency. This discrepancy also causes [[Software Suspend 2]] to oops during suspend.}}

There are several methods to control CPU voltage in Linux, and currently all of them require a patched kernel.

==Alternative 0: linux-phc==

Use the [[linux-phc]] kernel patch. '''This is the recommended method, as it is most generic and best supported.'''
* [ http://phc.athousandnights.de/linux-phc home page]

The sysfs interface of linux-phc (version 0.3.0 or newer) requires you to specify VID (Voltage ID) numbers; see the documentation in the source package. For pre-Core Intel CPUs, VID is related to voltage (in mV) as follows: <tt>VID=(voltage-700)/16</tt>.

A typical configuration command would look something like this:

{{cmdroot|echo '27 22 16 10 3' > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids}}

== Alternative 1: patch with hard-coded voltages ==
=== Instructions ===

# Determine the stable voltages for each frequency, using some overclocking/undervolting utility that has specific support for Pentium M ("Centrino") processors. It seems that no such utility exists for Linux. For windows, one good choice is [http://www.pbus-167.com/chc.htm Notebook Hardware Control (NHC)], which conveniently also includes a table of nominal frequencies and voltages (in its help file). Ascertain that at the undervolted settings the CPU actually performs correct computation ([http://www.mersenne.org/freesoft.htm Prime95] in "Tortute Test" mode seems to be a good partial test emphasizing FPU and memory access). Note that beside reducing voltages (undervolting), you can also try to add lower frequencies (underclocking). If you undervolt a particular frequency too much your machine is likely to crash, so try not to have any other programs open.
# Determine the model name string reported by the CPU, e.g., via the "<tt>Model name</tt>" line in {{path|/proc/cpuinfo}}, and likewise the <tt>cpu_family</tt>, <tt>model</tt> and <tt>stepping</tt>.
# Grab a copy of the example patch below and update it to reflect the parameters, frequencies and voltages you found.
# Apply the patch to your kernel (tested with 2.6.13.1 and 2.6.14-rc2).
# To prevent the ACPI table from overriding your table, disable the <tt>CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI</tt> kernel option.
# Compile and install the new kernel.

The changes should be active now. If you want to see debug information attesting to thus, do the following:

# Reboot in <tt>single</tt> mode.
# {{cmdroot|echo 2 > /sys/module/cpufreq/parameters/debug}}
# {{cmdroot|modprobe speedstep-centrino}}
# {{cmdroot|dmesg}} and check for the message "<tt>speedstep-centrino: found "Intel(R) Pentium(R) M processor </tt>..."

If you don't see that message, you got the <tt>cpu_id</tt> or <tt>model_name</tt> parmaeters wrong. If your system crashes, re-test the voltages and adjust accordingly.

Please report your results (including voltages)!

=== Linux kernel patch (example) ===

The following example shows how to undervolt a Pentium M 750 (1.86GHz) on a ThinkPad {{T43}}. As discussed above, the parameters are specific to this one CPU. You will need to experimentally find the correct settings for your own CPU and adjust the patch accordingly.

Note that the Pentium M 750 has a 533MHz FSB (quad-pumped 133MHz), hence the use of <tt>OP133</tt>. If you have a Pentium M with 400MHz FSB (i.e., quad-pumped 100MHz, found in [[Intel Pentium M (Banias)|Banias]] and older [[Intel Pentium M (Dothan)|Dothan]]) then in the voltage table change <tt>OP133</tt> to <tt>OP</tt>.

{{CodeRef|undervolt-pentium-m-2.6.13.1.patch}}

Don't forget to disable <tt>CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI</tt>.

==Alternative 2: patch with user-space control==

If you want to use the Ubuntu 2.6.15 Kernel, please have a look at this thread: http://ubuntuforums.org/showthread.php?t=146366

The [http://fabrice.bellamy.club.fr/bdz.undervolt.2005.10.22.a.patch bdz.undervolt.2005.10.22.a.patch] patch, written by Gentoo-Wiki user "Bdz", allows voltages to be changed without reboot.

It presents a userspace interface, as in the following example:
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table}}
:{{cmdresult|1356,1356,1356,1356,1356,1356,1356,1244,1116,988}}
:{{cmdroot|echo "1084,1084,1084,1084,1084,1084,1084,988,908,860" >/sys/devices/system/cpu/cpu0/cpufreq/voltage_table}}

The relevant [http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU page] on Gentoo-Wiki providues further information and some helpful hints and scripts for voltage adjustment.

When applying this patch be sure to keep the "ACPI tables for decoding frequency pairs" option -- this patch only allows adjustment of the voltages for the normal clock speeds as reported by the ACPI table in the BIOS. On some models (e.g., ThinkPad {{T43}}) this does not include all clock speeds supported by the processor.

=Initscript=
This is a Gentoo initscript for the patch from Gentoo-Wiki user "Bdz".

=== Configuration file ===
<bash>
# /etc/conf.d/undervoltage

# voltage table sysfs interface
VTABLE_SYSFS="/sys/devices/system/cpu/cpu0/cpufreq/voltage_table"

# switch back to DEFAULT_VTABLE if undervoltage is stopped? [yes/no]
SWITCH_BACK="no"

# pentium-m banias 1,7GHz default voltages
DEFAULT_VTABLE="1484,1308,1228,1116,1004,956"
# pentium-m banias 1,7GHz lowered voltages [ -208mV ]
MOD_VTABLE="1276,1100,1020,908,796,748"
</bash>

=== Initscript ===
<bash>
#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

sysfs_check() {

if ! [ -e ${VTABLE_SYSFS} ]; then
logger "No sysfs voltage_table present. Modifying vcore voltage failed."
eerror "It seems that the undervolting patch has not been applied to the kernel."
eerror "see http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU for further information"
return 1
fi
}

start() {
sysfs_check || return 1
ebegin "Switching to modified voltage table [${MOD_VTABLE}]"
echo ${MOD_VTABLE} > ${VTABLE_SYSFS}
eend $?
}

# I think it is not necessary to switch to the default voltage table on shutdown
stop() {
if [ $SWITCH_BACK = "yes" ]; then
ebegin "Switching back to default voltage table [${DEFAULT_VTABLE}]"
echo ${DEFAULT_VTABLE} > ${VTABLE_SYSFS}
eend $?
fi
}
</bash>

==Alternative 3: another patch with user-space control==

The [http://avkrok.net/nw8240/centrino-voltages.diff centrino-voltages.diff] patch, written by Rickard Holmberg, also provides user-space control. See [http://avkrok.net/nw8240/ here] and [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-December/030772.html here] for usage.

==Stress Testing==

This [[Undervolt Stress Testing Script|script]] illustrates a very conservative method to stress test your lowered voltage settings.

==Tested frequencies/voltages==

If you have done excessive testing with user defined frequencies (stable system for over a month).
and no lookups occur when computing primes with mprime http://mersenne.org/ (gentoo: 'emerge gimps')
you can post your frequencies here. But note that this is just a rough indication, since the stable values will differ between individual processors, even in the same model.

{| {{prettytable}}
! CPU Type !! GHz !! Frequency Steps
|-
| Pentium-M Banias || 1.6 || 1212,1084,956,860,796,748
|-
| Pentium-M Banias || 1.7 || 1276,1100,1020,908,796,748
|-
| Pentium-M Dothan || 1.4 || 924,892,860,828,796,764,732,700
|-
| Pentium-M Dothan || 1.86 || 1068,972,876,780,700
|-
| Pentium-M SL6F7 || 1.6 || 1196,1052,956,860,780,732
|-
| Pentium-M Dothan || 1.5 || 924,892,860,828,812,796,764,732,700
|-
| Pentium-M Dothan || 2.0 || 1084,940,844,764,748
|}

Following values were obtained with: (running at the same time)
<bash>
nice -n19 glxgears &
mplayer somedivx.avi &
cd /usr/src/linux && make -j2
</bash>
* note1: for pre-Core Intel CPUs, VID is related to voltage (in mV) as follows: VID=(voltage-700)/16 (or: voltage=(VID*16+700) mV)
* note2: when testing for stability you should pay attention to sound too, occasional distortions which disappear after bumping voltage a notch or two
* note3: if you use phc_vids for your script, then take only second number in each pair
{| {{prettytable}}
! Machine !! CPU Type !! GHz !! phc_controls (fid:vid)
|-
| {{X41T}} || Pentium-M Dothan LV (758) || 1.5 || 15:15 14:13 13:11 12:9 11:7 10:5 9:3 8:2 6:2
|-
| {{X32}} || Pentium-M Dothan (745) || 1.8 || 18:26 16:20 14:15 12:11 10:6 8:2 6:1
|}

[[Category:Patches]]

Talk:Patch for controlling fan speed

2006-10-07T11:38:47Z

Espa: Speed Control Patch for 2.6.18?

==Windows XP port==
How would I port this patch to Windows XP?

--Jason

You can't. But you can write a Windows device driver based on the specs and [[ibm-acpi]].

--[[User:Thinker|Thinker]] 18:54, 7 Nov 2005 (CET)

==gkrellm support==

I can confirm that it works on Thinkpad {{T43}} here. However after
applying the patch, the fan speed monitor of gkrellm 2.2.7 cannot read
value correctly. Maybe we gkrellm is reading the second line for speed
but instead find the line for level, so it got confused? Would it be possible to interchange the lines so that speed still appears in the
second line and level appears in the third instead? I'm no coder, just
a suggestion to improve the patch.

--Jiang

I'd say it's a bug in gkrellm. It should parse the line header rather than relying on line numbers. But feel free to change (and test) the patch if you wish.

--[[User:Thinker|Thinker]] 05:14, 26 Oct 2005 (CEST)

== patch to keep gkrell working against 2.6.14 ==

As in "works for me on a T43p", use with caution at your own risk. And thanks to thinker for the original patch, very nice work.

(See article for the actual patch)

--[[User:Spiney|Spiney]]

Looks excellent, why not add it to the article page? Also, care to provide a license (preferably public domain like my patch) so the kernel guys can handle it? Speaking of which, the kernel people seem to like their patches generated via "diff -up vanilla-kernel-2.6.14 patched-kernel-2.6.14".

--[[User:Thinker|Thinker]] 22:04, 1 Nov 2005 (CET)

Done, using the -p option for diff and "borrowing" your sentence for licensing purposes.

--[[User:Spiney|Spiney]]
----

== Updated script for unpatched kernels ==
Moved to the [[ACPI fan control script]] article page, after joint development by [[User:Spiney|Spiney]] and [[User:Thinker|Thinker]].

== whats the problem kernel 2.6.14 ==

hi all,

i patched the kernel with the patch for 2.6.14 with the option:
/usr/src/linux # patch -p0 -l -i ../ibm_acpi.patch (which i copy&pasted)

they dont show me errors or so. but after i reboot and load the modul ibm_acpi i cant see any /proc/acpi/ibm/fan

whats the problem? copy&past ( tab -> space?)
or is it a problem in my kernel config?

greetings and big thx from .ch,

system: ibm thinkpad t43p
kernel: 2.6.14

--[[User:62.203.29.204|62.203.29.204]] 19:22, 9 Nov 2005 (CET)kru

You need to pass the "<tt>experimental=1</tt>" module parameter to ibm-acpi:
# modprobe ibm_acpi experimental=1
--[[User:Thinker|Thinker]] 21:01, 9 Nov 2005 (CET)

big thx!!! problem solved.

--[[User:62.203.29.204|62.203.29.204]]

== Fan control does not work with Suse 10.1 ? ==

Hi,

I successfully installed and used the fan control script on my T43p with Suse 10.0.

Yesterday, I installed Suse 10.1 from scratch. Unfortunately fan control does not work with Suse 10.1:

\# echo level 2 > /proc/acpi/ibm/fan
bash: echo: write error: Invalid argument

Are there any substantial differences between Suse 10.0 and 10.1 with respect to ibm_acpi?

== Speed Control Patch for 2.6.18? ==

Hi All.
I'm trying to apply the speed control patch to vanilla 2.6.18 but it looks like it failed. Anyone who can point me to a direction for 2.6.18 patch?
Thanks

Ipw2200

2006-08-27T03:13:33Z

Espa: /* WPA support */

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

Starting with kernels 2.6.14 the driver is included in kernel.

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

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

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

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

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

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

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

Latest stable versions:
* ipw2200 driver: 1.1.0
* firmware: 2.4
* ieee80211 stack: 1.1.12

Latest development versions:
* ipw2200 driver: 1.1.3
* firmware: 3.0
* ieee80211 stack: 1.1.14

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

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

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

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

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

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

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

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

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

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

In etch the firmware can also be placed in /lib/firmware

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

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

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

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

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

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

here we might run a cmd like this

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

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

:{{cmdroot|update-modules}}

== WPA support ==

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

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

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

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

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

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

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

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

[[Category:Drivers]]

Ipw2200

2006-08-27T03:12:51Z

Espa: /* WPA support */

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

Starting with kernels 2.6.14 the driver is included in kernel.

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

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

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

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

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

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

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

Latest stable versions:
* ipw2200 driver: 1.1.0
* firmware: 2.4
* ieee80211 stack: 1.1.12

Latest development versions:
* ipw2200 driver: 1.1.3
* firmware: 3.0
* ieee80211 stack: 1.1.14

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

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

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

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

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

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

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

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

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

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

In etch the firmware can also be placed in /lib/firmware

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

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

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

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

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

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

here we might run a cmd like this

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

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

:{{cmdroot|update-modules}}

== WPA support ==

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

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

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

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

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

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

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

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

[[Category:Drivers]]

Ipw2200

2006-08-27T03:12:21Z

Espa: /* WPA support */

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

Starting with kernels 2.6.14 the driver is included in kernel.

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

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

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

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

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

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

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

Latest stable versions:
* ipw2200 driver: 1.1.0
* firmware: 2.4
* ieee80211 stack: 1.1.12

Latest development versions:
* ipw2200 driver: 1.1.3
* firmware: 3.0
* ieee80211 stack: 1.1.14

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

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

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

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

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

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

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

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

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

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

In etch the firmware can also be placed in /lib/firmware

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

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

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

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

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

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

here we might run a cmd like this

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

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

:{{cmdroot|update-modules}}

== WPA support ==

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

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

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

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

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

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

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

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

[[Category:Drivers]]

Talk:How to enable integrated fingerprint reader with BioAPI

2005-11-27T07:03:27Z

Espa:

==Changing the installation path==
By default, bioapi will install numerous files in {{path|/usr/local/<nowiki>{</nowiki>bin,lib,include<nowiki>}</nowiki>}}, including files with "self-explanatory" names such as {{path|/usr/local/bin/Sample}}. To prevent this pollution:
* Create a dedicated directory,say, {{path|/opt/bioapi}} .
* Append <tt>--prefix=/opt/bioapi</tt> to the <tt>./configure</tt> command of bioapi
* Append {{path|/opt/bioapi/bin}} to <tt>$PATH</tt> and {{path|/opt/bioapi/lib}} to <tt>$LD_LIBRARY_PATH</tt>
* Edit the install path in {{path|install.sh}} of the driver

--[[User:Thinker|Thinker]] 18:06, 30 Oct 2005 (CET)
----

== chmod 777 -R /usr/local/var/bioapi/ ==

Is the above necessary? I just made a debian package of xscreensaver with the patch applied, and when using the bioapi debian pacakge from [http://www.qrivy.net/~michael/temp/ Michael R. Crusoe's site] which has this directory put in /usr/var/bioapi I had not to change the permissions to world-writeable there. Write access to the logfile and usb device are necessary, but that directory works with 755 as well (even though it comes with 777 in Michael's package), and all files and subdirectories are 644/755 too.

--[[User:Spiney|spiney]] 00:08, 11 Nov 2005 (CET)
----

== Qt Compilation Success ==

Here it worked with qt ;)

== using absolute paths for commands ==

I don't know whether using absolute paths in the articles is a good idea, at least not for tools like {{cmd|lsusb|}} which are not established utilities (i.e. used for more than a decade or something ;)) and happen to be in different locations in different distributions. E.g. said {{cmd|lsusb|}} resides in {{path|/usr/sbin|}} on Debian systems.

--[[User:Spiney|spiney]] 16:45, 12 Nov 2005 (CET)
----

== BioAPI error #3 ==

Its kind of strage it used to work with everythig (kdm,console,lock,etc)
Now it only works with kdm. It allways gives back:

pam_bioapi[8113]: Unable to initialize Bioapi framework, BioAPI error #:3.

Even when I set the right permissions on /proc/bus/usb.

I am able to run the Sample program as normal user after setting the permissions, but when I change within a user session by su I amnot able to run the Sample program a also get an error Code #3.

From an other terminal (alt+strg+Fx) I am able to run the Sample program but at the login I still get the error #3.

I cant remember to have changed anything an d bevor I was able to login in a console with my fingerprint now only kdm is working even kde lock-session
isnt working anymore.

Any suggestions ?

==Driver Expiring!!!==
Don't anyone notice that both betas of the UPEK driver is expiring in
about a month in the new year, Jan 1st 2006? They really mean it!
I set my computer date to next year and get a message "the driver has expired" when using fingerprint reader! This is a grave threat to our computer lifestyle, i.e. for those of us who got it working and use it
daily:)
Is there any workaround other than setting the date back a year when
new year come and wait for new driver? Is there a way to figure out where exactly in the driver it checked the date and how? The must have set it
somewhere in file libtfmessbsp.so, but it is binary and I can't figure out how to Reverse Engineer it.

---Jiang

How to enable integrated fingerprint reader with BioAPI

2005-10-31T18:21:57Z

Espa: /* Troubleshooting and Hints */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page describes the process of getting the fingerprint reader to work. It is based on experiences in {{Ubuntu}} on a T43. The same works on {{Fedora}} 4.
|}

==Basic driver installation==
===Getting required libs and tools===
====Installing the bioapi source====
*Get the bioapi source:
:{{cmduser|wget http://www.qrivy.net/~michael/blua/bioapi/bioapi-1.2.2.tar.bz2}}
*I could not compile bioapi with the graphical Qt tools. To do it manually, do the following:
:{{cmduser|tar xjf bioapi-1.2.2.tar.bz2}}
:{{cmduser|cd bioapi-1.2.2}}
:{{cmduser|1=./configure --with-Qt-dir=no}}
:{{cmduser|make}}
:and then as root
:{{cmdroot|make install}}
:and if you want to compile pam_bioapi for auth later
:{{cmdroot|cp include/bioapi_util.h include/installdefs.h imports/cdsa/v2_0/inc/cssmtype.h /usr/include}}
:Be aware that checkinstall will not work!

====Installing the driver====
*Download {{path|TFMESS_BSP_LIN_1.0beta2.zip}} from http://www.qrivy.net/~michael/blua/upek-bsp.html and unzip it into a seperate folder, as it will not create one.
*Change to that folder and do as root:
:{{cmdroot|sh install.sh}}
:{{cmdroot|chmod 777 -R /usr/local/var/bioapi/}}
:Actually this depends on where you installed, if you did as suggested, it should work. Otherwise you probably know what you're doing anyways. :)
:{{cmdroot|touch /var/log/BSP.log && chmod 666 /var/log/BSP.log}}
:{{cmdroot|chmod -R a+X /proc/bus/usb}}
:{{cmdroot|chmod 666 /proc/bus/usb/`lsusb <nowiki>|</nowiki> grep "0483:2016" <nowiki>|</nowiki> sed -e "s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/"`}}
:It might be nessecary to put the above line into a startup script somewhere.

===Testing the driver===
Go to the folder where you extracted {{path|TFMESS_BSP_LIN_1.0beta2.zip}} and do:
:{{cmdroot|cd NonGUI_Sample}}
:{{cmdroot|chmod +x Sample}}
:{{cmdroot|./Sample}}
If it doesn't work, ask for help at: t43fingerprint (at) badcode.de

==GDM Login via pam_bioapi==
===Getting required libs & tools===
====Installing pam_bioapi====
*Get and compile the pam_bioapi module.
:{{cmduser|wget http://www.qrivy.net/~michael/blua/pam_bioapi/pam_bioapi-0.2.1.tar.bz2}}
:{{cmduser|tar xjf pam_bioapi-0.2.1.tar.bz2}}
:{{cmduser|cd pam_bioapi-0.2.1}}
:{{cmduser|wget http://badcode.de/downloads/fingerprint.patch}}
:{{cmduser|patch -p0 < fingerprint.patch}}
:If you want to, review the patch. In general you should review all code you download and compile, if possible. The patch comes from [http://linuxbiometrics.com/modules/newbb/viewtopic.php?viewmode=flat&topic_id=80&forum=1 this thread].
:{{cmduser|./configure && make}}
:and as root
:{{cmdroot| make install}}
:{{cmdroot| cp /usr/local/lib/security/* /lib/security/}}
*Use the sample tool from the fingerprint reader to create {{path|<username>.bir}} (<tt><username></tt> '''must''' be the username you want to login with. gdm will probably break for any login name that has no .bir file).
*As root do:
:{{cmdroot|SERIAL<nowiki>=`BioAPITest | grep -A2 Fingerprint | tail -n1 | cut -b 12- | sed -e "s/$^.\{9\}$$.\{4\}$$.\{4\}$$.\{4\}$$.*$/\1-\2-\3-\4-\5/g"` </nowiki>}}
:{{cmdroot|echo $SERIAL}} should print something like {{cmdresult|<nowiki>{5550454b-2054-464d-2f45-535320425350}</nowiki>}} now.
:If it does, do:
:{{cmdroot|mkdir -p /etc/bioapi1.10/pam/$SERIAL}}
:{{cmdroot|cp <username>.bir /etc/bioapi1.10/pam/$SERIAL}}

===Configuring pam===
The following part is distribution specific. On {{Ubuntu}} you can modify {{path|/etc/pam.d/common-auth}} (on {{Gentoo}} and {{Fedora}} it is {{path|/etc/pam.d/system-auth}}) to look like this:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
password sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
auth required pam_unix.so nullok_secure

With this modification pam immediatelly starts to use the fingerprint reader to do local authorization (e.g. sudo/gdm use the fingerprint reader).

{{NOTE|This was discovered through trial and success, if it is plain wrong, wikorrect it, please.}}

On {{Fedora}}, you may need to add {{path|/usr/local/lib}} to your LD_LIBRARY path so that the libraries referenced from <tt>pam_bioapi.so</tt> get picked up properly.

Now gdm should pop up an (ugly) image to swipe your finger and... magic - you can login without a password.

==Make xscreensaver use the scanner==
*Get the needed xscreensaver sources:
:{{cmduser|wget http://www.jwz.org/xscreensaver/xscreensaver-4.23.tar.gz}}
:{{cmduser|tar xzf xscreensaver-4.23.tar.gz}}
:{{cmduser|cd xscreensaver-4.23}}
:{{cmduser|wget http://nax.hn.org/pub/bioapi/xscreensaver-4.22_alternativeAuth.diff}}
*After reviewing the patch (it's small and straightforward), do
:{{cmduser|patch -p1 < xscreensaver-4.22_alternativeAuth.diff}} The patch prevents xscreensaver from opening an authentification window and dispatches the authentification request to another program, in our case <tt>pam</tt> and <tt>pam_bioapi</tt>. It should apply with some offset, don't mind that. If it says something about rejected though, then there's a problem.
*Compile with
:{{cmduser|./configure --with-pam && make}} and then install as root with
:{{cmduser|su -c make install}} .
*Make sure that the newly compiled xscreensaver is used:
:{{cmduser|which xscreensaver}} should return
:{{cmdresult|/usr/local/bin/xscreensaver}} .
:*In case it doesn't, try
::{{cmduser|1=export PATH=/usr/local/bin:$PATH}} and retry.
*Kill the running instance of xscreensaver:
:{{cmduser|xscreensaver-command -exit}}
*Make sure you have the following line in your {{path|~/.xscreensaver}}:
alternativeAuth: True
*Now edit {{path|/etc/pam.d/xscreensaver}} to include the following line (If you're on {{Ubuntu}} Breezy and you already changed {{path|/etc/pam.d/common-auth}} you should not need to do this.):
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
*Start the new xscreensaver
:{{cmduser|xscreensaver}} There should be a splash screen with version 4.23.
*Now try:
:{{cmduser|xscreensaver-command -lock}}

If you have questions or problems with this procedure, ask: t43fingerprint (at) badcode.de .

==Troubleshooting and Hints==
# After installing the driver, don't forget to reboot!
## This might not be necessary. it worked here without having to reboot.
# To see if the fingerprint device is know on the USB bus do:
:{{cmdroot|lsusb}}
:as root and you should see a line like:
:{{cmdresult|Bus 003 Device 004: ID 0483:2016 SGS Thomson Microelectronics}}
:The bus and device number can be different. This should work without the driver installed. If the device does not show up, you have a hardware problem/quirk, Rebooting might fix this.
# For some installation, after installing the driver as in section [[#Installing the driver|Installing the driver]] and makingÂ´sure the device is recognized, try to test it by going to {{path|NonGUI_Sample}} directory and run {{cmdroot|./Sample}}, one get segmentation fault. In this case, try getting the Beta1 instead of Beta2 of the driver and installing it
# There was some confusion about the /etc/bioapi1.10/pam{5550454b-2054-464d-2f45-535320425350} path, this has been fixed in the howto, if you have problems, check the section again, the path needs to have the '-' in them
# When something goes wrong look at the tail of {{path|/var/log/auth.log}}. Specifically if you see an entry saying something like
pam_bioapi[10480]: Unable to load BioAPI BSP with UUID of {5550454b-2054-464d-2f45-535320425350}, BioAPI error <nowiki>#</nowiki>194d.
Check whether your {{path|/proc/bus/usb}} directory permissions are set up as in the
section [[#Installing the driver|Installing the driver]].
# To get the xscreensaver compiled you might need a bunch of header files, in my case I need the following:
#*python-gtk2-dev
#*libgstreamer0.8-dev
#*xlibs-dev
# Sometimes {{path|$HOME/.xscreensaver}} got overwritten, try changing it to read-only.
# If after suspending to RAM and resume, lsusb no longer have "SGS Thomson Microelectronics" entry, try adding a line
:{{cmdroot|/etc/init.d/hotplug restart}}
to your {{path|/etc/acpi/resume.sh}} file
#If after resume lsusb shows the device but xscreensaver does not ask for fingerprint for login, you might want to check the permission of the usb bus in the appropriate {{path|/proc/bus/usb/}} entry. If necessesary you might need to add a line to {{path|/etc/acpi/resume.sh}} as in section [[#Installing the driver|Installing the driver]] to set the permission right.

How to enable integrated fingerprint reader with BioAPI

2005-10-31T18:19:12Z

Espa: /* Troubleshooting and Hints */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page describes the process of getting the fingerprint reader to work. It is based on experiences in {{Ubuntu}} on a T43. The same works on {{Fedora}} 4.
|}

==Basic driver installation==
===Getting required libs and tools===
====Installing the bioapi source====
*Get the bioapi source:
:{{cmduser|wget http://www.qrivy.net/~michael/blua/bioapi/bioapi-1.2.2.tar.bz2}}
*I could not compile bioapi with the graphical Qt tools. To do it manually, do the following:
:{{cmduser|tar xjf bioapi-1.2.2.tar.bz2}}
:{{cmduser|cd bioapi-1.2.2}}
:{{cmduser|1=./configure --with-Qt-dir=no}}
:{{cmduser|make}}
:and then as root
:{{cmdroot|make install}}
:and if you want to compile pam_bioapi for auth later
:{{cmdroot|cp include/bioapi_util.h include/installdefs.h imports/cdsa/v2_0/inc/cssmtype.h /usr/include}}
:Be aware that checkinstall will not work!

====Installing the driver====
*Download {{path|TFMESS_BSP_LIN_1.0beta2.zip}} from http://www.qrivy.net/~michael/blua/upek-bsp.html and unzip it into a seperate folder, as it will not create one.
*Change to that folder and do as root:
:{{cmdroot|sh install.sh}}
:{{cmdroot|chmod 777 -R /usr/local/var/bioapi/}}
:Actually this depends on where you installed, if you did as suggested, it should work. Otherwise you probably know what you're doing anyways. :)
:{{cmdroot|touch /var/log/BSP.log && chmod 666 /var/log/BSP.log}}
:{{cmdroot|chmod -R a+X /proc/bus/usb}}
:{{cmdroot|chmod 666 /proc/bus/usb/`lsusb <nowiki>|</nowiki> grep "0483:2016" <nowiki>|</nowiki> sed -e "s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/"`}}
:It might be nessecary to put the above line into a startup script somewhere.

===Testing the driver===
Go to the folder where you extracted {{path|TFMESS_BSP_LIN_1.0beta2.zip}} and do:
:{{cmdroot|cd NonGUI_Sample}}
:{{cmdroot|chmod +x Sample}}
:{{cmdroot|./Sample}}
If it doesn't work, ask for help at: t43fingerprint (at) badcode.de

==GDM Login via pam_bioapi==
===Getting required libs & tools===
====Installing pam_bioapi====
*Get and compile the pam_bioapi module.
:{{cmduser|wget http://www.qrivy.net/~michael/blua/pam_bioapi/pam_bioapi-0.2.1.tar.bz2}}
:{{cmduser|tar xjf pam_bioapi-0.2.1.tar.bz2}}
:{{cmduser|cd pam_bioapi-0.2.1}}
:{{cmduser|wget http://badcode.de/downloads/fingerprint.patch}}
:{{cmduser|patch -p0 < fingerprint.patch}}
:If you want to, review the patch. In general you should review all code you download and compile, if possible. The patch comes from [http://linuxbiometrics.com/modules/newbb/viewtopic.php?viewmode=flat&topic_id=80&forum=1 this thread].
:{{cmduser|./configure && make}}
:and as root
:{{cmdroot| make install}}
:{{cmdroot| cp /usr/local/lib/security/* /lib/security/}}
*Use the sample tool from the fingerprint reader to create {{path|<username>.bir}} (<tt><username></tt> '''must''' be the username you want to login with. gdm will probably break for any login name that has no .bir file).
*As root do:
:{{cmdroot|SERIAL<nowiki>=`BioAPITest | grep -A2 Fingerprint | tail -n1 | cut -b 12- | sed -e "s/$^.\{9\}$$.\{4\}$$.\{4\}$$.\{4\}$$.*$/\1-\2-\3-\4-\5/g"` </nowiki>}}
:{{cmdroot|echo $SERIAL}} should print something like {{cmdresult|<nowiki>{5550454b-2054-464d-2f45-535320425350}</nowiki>}} now.
:If it does, do:
:{{cmdroot|mkdir -p /etc/bioapi1.10/pam/$SERIAL}}
:{{cmdroot|cp <username>.bir /etc/bioapi1.10/pam/$SERIAL}}

===Configuring pam===
The following part is distribution specific. On {{Ubuntu}} you can modify {{path|/etc/pam.d/common-auth}} (on {{Gentoo}} and {{Fedora}} it is {{path|/etc/pam.d/system-auth}}) to look like this:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
password sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
auth required pam_unix.so nullok_secure

With this modification pam immediatelly starts to use the fingerprint reader to do local authorization (e.g. sudo/gdm use the fingerprint reader).

{{NOTE|This was discovered through trial and success, if it is plain wrong, wikorrect it, please.}}

On {{Fedora}}, you may need to add {{path|/usr/local/lib}} to your LD_LIBRARY path so that the libraries referenced from <tt>pam_bioapi.so</tt> get picked up properly.

Now gdm should pop up an (ugly) image to swipe your finger and... magic - you can login without a password.

==Make xscreensaver use the scanner==
*Get the needed xscreensaver sources:
:{{cmduser|wget http://www.jwz.org/xscreensaver/xscreensaver-4.23.tar.gz}}
:{{cmduser|tar xzf xscreensaver-4.23.tar.gz}}
:{{cmduser|cd xscreensaver-4.23}}
:{{cmduser|wget http://nax.hn.org/pub/bioapi/xscreensaver-4.22_alternativeAuth.diff}}
*After reviewing the patch (it's small and straightforward), do
:{{cmduser|patch -p1 < xscreensaver-4.22_alternativeAuth.diff}} The patch prevents xscreensaver from opening an authentification window and dispatches the authentification request to another program, in our case <tt>pam</tt> and <tt>pam_bioapi</tt>. It should apply with some offset, don't mind that. If it says something about rejected though, then there's a problem.
*Compile with
:{{cmduser|./configure --with-pam && make}} and then install as root with
:{{cmduser|su -c make install}} .
*Make sure that the newly compiled xscreensaver is used:
:{{cmduser|which xscreensaver}} should return
:{{cmdresult|/usr/local/bin/xscreensaver}} .
:*In case it doesn't, try
::{{cmduser|1=export PATH=/usr/local/bin:$PATH}} and retry.
*Kill the running instance of xscreensaver:
:{{cmduser|xscreensaver-command -exit}}
*Make sure you have the following line in your {{path|~/.xscreensaver}}:
alternativeAuth: True
*Now edit {{path|/etc/pam.d/xscreensaver}} to include the following line (If you're on {{Ubuntu}} Breezy and you already changed {{path|/etc/pam.d/common-auth}} you should not need to do this.):
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
*Start the new xscreensaver
:{{cmduser|xscreensaver}} There should be a splash screen with version 4.23.
*Now try:
:{{cmduser|xscreensaver-command -lock}}

If you have questions or problems with this procedure, ask: t43fingerprint (at) badcode.de .

==Troubleshooting and Hints==
# After installing the driver, don't forget to reboot!
## This might not be necessary. it worked here without having to reboot.
# To see if the fingerprint device is know on the USB bus do:
:{{cmdroot|lsusb}}
:as root and you should see a line like:
:{{cmdresult|Bus 003 Device 004: ID 0483:2016 SGS Thomson Microelectronics}}
:The bus and device number can be different. This should work without the driver installed. If the device does not show up, you have a hardware problem/quirk, Rebooting might fix this.
# For some installation, after installing the driver as in section [[#Installing the driver|Installing the driver]] and makingÂ´sure the device is recognized, try to test it by going to {{path|NonGUI_Sample}} directory and run {{cmdroot|./Sample}}, one get segmentation fault. In this case, try getting the Beta1 instead of Beta2 of the driver and installing it
# There was some confusion about the /etc/bioapi1.10/pam{5550454b-2054-464d-2f45-535320425350} path, this has been fixed in the howto, if you have problems, check the section again, the path needs to have the '-' in them
# When something goes wrong look at the tail of {{path|/var/log/auth.log}}. Specifically if you see an entry saying something like
pam_bioapi[10480]: Unable to load BioAPI BSP with UUID of {5550454b-2054-464d-2f45-535320425350}, BioAPI error <nowiki>#</nowiki>194d.
Check whether your {{path|/proc/bus/usb}} directory permissions are set up as in the
section [[#Installing the driver|Installing the driver]].
# To get the xscreensaver compiled you might need a bunch of header files, in my case I need the following:
#*python-gtk2-dev
#*libgstreamer0.8-dev
#*xlibs-dev
# Sometimes {{path|$HOME/.xscreensaver}} got overwritten, try changing it to read-only.
# If after suspending to RAM and resume, lsusb no longer have "SGS Thomson Microelectronics" entry, try adding a line
:{{cmdroot|/etc/init.d/hotplug restart}}
to your /etc/acpi/resume.sh file
#If after resume lsusb shows the device but xscreensaver does not ask for fingerprint for login, you might want to check the permission of the usb bus in the appropriate /proc/bus/usb/ entry. If necessesary you might need to add a line to /etc/acpi/resume.sh as in section [[#Installing the driver|Installing the driver]] to set the permission right.

Patch for controlling fan speed

2005-10-25T23:45:10Z

Espa: /* Models on which this patch works */

==Overview==

This patch extends the <tt>ibm-acpi</tt> Linux kernel module to control fan speed. It can be used to reduce [[Problem with fan noise|fan noise]] and power consumption.

When this patch is applied and the <tt>ibm-acpi</tt> module is loaded with the <tt>experimental=1</tt> module parameter, the following new capabilities are added to {{path|/proc/acpi/ibm/fan}}:
* {{cmdroot|echo LEVEL > /proc/acpi/ibm/fan}} sets a fan speed level between 0 and 7, where <tt>LEVEL</TT>=0 means fan off and <tt>LEVEL</tt>=7 is the fastest speed.
* {{cmdroot|echo auto > /proc/acpi/ibm/fan}} tells the embedded controller to set the fan speed automatically according to system temperatures (this is the default).
* {{cmdroot|cat /proc/acpi/ibm/fan}} shows the current fan level (in addition to the fan speed in RPM).

This patch is best used with a program that monitors system temperature and sets the fan speed accordingly. The [[ACPI fan control script|current scripts for fan control]] could serve as the basis of such program.

{{WARN|Overriding the system's automatic temperature control may cause permanent hardware damage. Even when using temperature monitoring software, it is not clear whether the software can access all temperature sensor accessible to the embedded controller and understand them correctly. Moreover, this patch relies on an undocumented hardware interface, and may thus have arbitrary effects (especially on models it wasn't tested on).}}

==Models on which this patch works==

* ThinkPad {{T43}}, {{T43p}} (levels 1-2 = ~3300RPM, level 3-5 = ~4100RPM, level 6-7 = ~4700 RPM)

Probably many other models; please update this page with your results.

I can confirm that it works on Thinkpad {{T43}} here. However after
applying the patch, the fan speed monitor of gkrellm 2.2.7 cannot read
value correctly. Maybe we gkrellm is reading the second line for speed
but instead find the line for level, so it got confused? Would it be possible to interchange the lines so that speed still appears in the
second line and level appears in the third instead? I'm no coder, just
a suggestion to improve the patch.
--Jiang

==Models on which this patch doesn't work==

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

==The patch==

This also includes a minor fix (rename of <tt>device_add</tt>) to make ibm-acpi 0.11 compile on kernel 2.6.13.

<pre>
--- ibm-acpi-0.11-orig/ibm_acpi.c 2005-03-17 12:06:16.000000000 +0200
+++ ibm-acpi-0.11/ibm_acpi.c 2005-10-24 12:56:44.000000000 +0200
@@ -1488,11 +1488,16 @@ static int fan_read(char *p)
} else {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_read(fan_status_offset, &status))
len += sprintf(p + len, "status:\t\tunreadable\n");
- else
+ else {
len += sprintf(p + len, "status:\t\t%s\n",
- enabled(status, 7));
+ status ? "enabled" : "disabled");
+ if (status & 0x80)
+ len += sprintf(p + len, "level:\t\tauto\n");
+ else
+ len += sprintf(p + len, "level:\t\t%d\n", status);
+ }

if (!acpi_ec_read(fan_rpm_offset, &lo) ||
!acpi_ec_read(fan_rpm_offset + 1, &hi))
len += sprintf(p + len, "speed:\t\tunreadable\n");
@@ -1506,9 +1511,10 @@ static int fan_read(char *p)
len += sprintf(p + len, "commands:\tlevel <level>"
" (<level> is 0-7)\n");
if (!gfan_handle)
/* all except 570, 600e/x, 770e, 770x */
- len += sprintf(p + len, "commands:\tenable, disable\n");
+ len += sprintf(p + len, "commands:\tenable, disable, level <level>\n"
+ " \t(<level> is 0-7 or auto)\n");
if (fans_handle)
/* X31, X40 */
len += sprintf(p + len, "commands:\tspeed <speed>"
" (<speed> is 0-65535)\n");
@@ -1528,17 +1534,24 @@ static int fan_write(char *buf)
/* 570, 770x-JL */
if (!acpi_evalf(sfan_handle, NULL, NULL, "vd", level))
return -EIO;
} else if (!gfan_handle &&
- strlencmp(cmd, "enable") == 0) {
+ ( (strlencmp(cmd, "enable") == 0) ||
+ (strlencmp(cmd, "level auto") == 0) ) ) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x80))
return -EIO;
} else if (!gfan_handle &&
strlencmp(cmd, "disable") == 0) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x00))
return -EIO;
+ } else if (!gfan_handle &&
+ sscanf(cmd, "level %d", &level) == 1 &&
+ level >=0 && level <= 7) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, level))
+ return -EIO;
} else if (fans_handle &&
sscanf(cmd, "speed %d", &speed) == 1 &&
speed >= 0 && speed <= 65535) {
/* X31, X40 */
@@ -1751,9 +1764,9 @@ static int __init setup_notify(struct ib

return 0;
}

-static int device_add(struct acpi_device *device)
+static int ibmacpi_device_add(struct acpi_device *device)
{
return 0;
}

@@ -1769,9 +1782,9 @@ static int __init register_driver(struct

memset(ibm->driver, 0, sizeof(struct acpi_driver));
sprintf(ibm->driver->name, "%s/%s", IBM_NAME, ibm->name);
ibm->driver->ids = ibm->hid;
- ibm->driver->ops.add = &device_add;
+ ibm->driver->ops.add = &ibmacpi_device_add;

ret = acpi_bus_register_driver(ibm->driver);
if (ret < 0) {
printk(IBM_ERR "acpi_bus_register_driver(%s) failed: %d\n",
</pre>

==Hardware spec==

The patch relies on the following hardware behavior, discovered experimentally on a ThinkPad {{T43}}.

ACPI DSDT register _SB.PCI0.LPC.EC.HFSP (8 bits, offset 0x2F in the EmbeddedController address space):

7 6 5 4 3 2 1 0
| ? ? | \___/
| | |
| | +------ manual fan speed level (0=disable, 1=min, ..., 7=max)
| \------------ no effect
\------------------ automatic fan speed control (1=enable, overrides manual)

[[Category:Patches]]

Patch for controlling fan speed

2005-10-25T23:44:43Z

Espa: /* Models on which this patch works */

==Overview==

This patch extends the <tt>ibm-acpi</tt> Linux kernel module to control fan speed. It can be used to reduce [[Problem with fan noise|fan noise]] and power consumption.

When this patch is applied and the <tt>ibm-acpi</tt> module is loaded with the <tt>experimental=1</tt> module parameter, the following new capabilities are added to {{path|/proc/acpi/ibm/fan}}:
* {{cmdroot|echo LEVEL > /proc/acpi/ibm/fan}} sets a fan speed level between 0 and 7, where <tt>LEVEL</TT>=0 means fan off and <tt>LEVEL</tt>=7 is the fastest speed.
* {{cmdroot|echo auto > /proc/acpi/ibm/fan}} tells the embedded controller to set the fan speed automatically according to system temperatures (this is the default).
* {{cmdroot|cat /proc/acpi/ibm/fan}} shows the current fan level (in addition to the fan speed in RPM).

This patch is best used with a program that monitors system temperature and sets the fan speed accordingly. The [[ACPI fan control script|current scripts for fan control]] could serve as the basis of such program.

{{WARN|Overriding the system's automatic temperature control may cause permanent hardware damage. Even when using temperature monitoring software, it is not clear whether the software can access all temperature sensor accessible to the embedded controller and understand them correctly. Moreover, this patch relies on an undocumented hardware interface, and may thus have arbitrary effects (especially on models it wasn't tested on).}}

==Models on which this patch works==

* ThinkPad {{T43}}, {{T43p}} (levels 1-2 = ~3300RPM, level 3-5 = ~4100RPM, level 6-7 = ~4700 RPM)

Probably many other models; please update this page with your results.

I can confirm that it works on Thinkpad {{T43}} here. However after
applying the patch, the fan speed monitor of gkrellm 2.2.7 cannot read
value correctly. Maybe we gkrellm is reading the second line for speed
but instead find the line for level, so it got confused? Would it be possible to interchange the lines so that speed still appears in the
second line and level appears in the third instead? I'm no coder, just
a suggestion to improve the patch.

==Models on which this patch doesn't work==

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

==The patch==

This also includes a minor fix (rename of <tt>device_add</tt>) to make ibm-acpi 0.11 compile on kernel 2.6.13.

<pre>
--- ibm-acpi-0.11-orig/ibm_acpi.c 2005-03-17 12:06:16.000000000 +0200
+++ ibm-acpi-0.11/ibm_acpi.c 2005-10-24 12:56:44.000000000 +0200
@@ -1488,11 +1488,16 @@ static int fan_read(char *p)
} else {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_read(fan_status_offset, &status))
len += sprintf(p + len, "status:\t\tunreadable\n");
- else
+ else {
len += sprintf(p + len, "status:\t\t%s\n",
- enabled(status, 7));
+ status ? "enabled" : "disabled");
+ if (status & 0x80)
+ len += sprintf(p + len, "level:\t\tauto\n");
+ else
+ len += sprintf(p + len, "level:\t\t%d\n", status);
+ }

if (!acpi_ec_read(fan_rpm_offset, &lo) ||
!acpi_ec_read(fan_rpm_offset + 1, &hi))
len += sprintf(p + len, "speed:\t\tunreadable\n");
@@ -1506,9 +1511,10 @@ static int fan_read(char *p)
len += sprintf(p + len, "commands:\tlevel <level>"
" (<level> is 0-7)\n");
if (!gfan_handle)
/* all except 570, 600e/x, 770e, 770x */
- len += sprintf(p + len, "commands:\tenable, disable\n");
+ len += sprintf(p + len, "commands:\tenable, disable, level <level>\n"
+ " \t(<level> is 0-7 or auto)\n");
if (fans_handle)
/* X31, X40 */
len += sprintf(p + len, "commands:\tspeed <speed>"
" (<speed> is 0-65535)\n");
@@ -1528,17 +1534,24 @@ static int fan_write(char *buf)
/* 570, 770x-JL */
if (!acpi_evalf(sfan_handle, NULL, NULL, "vd", level))
return -EIO;
} else if (!gfan_handle &&
- strlencmp(cmd, "enable") == 0) {
+ ( (strlencmp(cmd, "enable") == 0) ||
+ (strlencmp(cmd, "level auto") == 0) ) ) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x80))
return -EIO;
} else if (!gfan_handle &&
strlencmp(cmd, "disable") == 0) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x00))
return -EIO;
+ } else if (!gfan_handle &&
+ sscanf(cmd, "level %d", &level) == 1 &&
+ level >=0 && level <= 7) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, level))
+ return -EIO;
} else if (fans_handle &&
sscanf(cmd, "speed %d", &speed) == 1 &&
speed >= 0 && speed <= 65535) {
/* X31, X40 */
@@ -1751,9 +1764,9 @@ static int __init setup_notify(struct ib

return 0;
}

-static int device_add(struct acpi_device *device)
+static int ibmacpi_device_add(struct acpi_device *device)
{
return 0;
}

@@ -1769,9 +1782,9 @@ static int __init register_driver(struct

memset(ibm->driver, 0, sizeof(struct acpi_driver));
sprintf(ibm->driver->name, "%s/%s", IBM_NAME, ibm->name);
ibm->driver->ids = ibm->hid;
- ibm->driver->ops.add = &device_add;
+ ibm->driver->ops.add = &ibmacpi_device_add;

ret = acpi_bus_register_driver(ibm->driver);
if (ret < 0) {
printk(IBM_ERR "acpi_bus_register_driver(%s) failed: %d\n",
</pre>

==Hardware spec==

The patch relies on the following hardware behavior, discovered experimentally on a ThinkPad {{T43}}.

ACPI DSDT register _SB.PCI0.LPC.EC.HFSP (8 bits, offset 0x2F in the EmbeddedController address space):

7 6 5 4 3 2 1 0
| ? ? | \___/
| | |
| | +------ manual fan speed level (0=disable, 1=min, ..., 7=max)
| \------------ no effect
\------------------ automatic fan speed control (1=enable, overrides manual)

[[Category:Patches]]

Problems with SATA and Linux

2005-09-27T03:38:58Z

Espa: /* No SMART support */

Some ThinkPad models, use a SATA controller for the system hard disk (the hard disk itself is PATA, but is accessed through a SATA-to-PATA bridge). This causes several complications for Linux installation. The following lists these problems and some workarounds.

=Models using a SATA disk interface=
'''SATA controller with IDE disk (PATA passthrough)''' 
ThinkPad {{T43}}, {{T43p}}, {{R52}}, {{X41}}, {{X41T}} 
'''SATA controller with SATA disk''' 
ThinkPad {{Z60t}}, {{Z60m}}.

=SATA-related problems under Linux=
The following is a list of SATA-related issues one may encounter when runing Linux on these ThinkPad models. Note that the details are often version- and distribution-specific.

==Hang on resume from suspend to RAM==

Linux kernels (as of 2.6.14-rc2) do not support suspend and resume for SATA devices. As a result, the machine hangs upon the first disk access after resume. A kernel patch is available (see [[How to make ACPI work]] under "Suspend to RAM").

Some distributions already include this patch (e.g., Ubuntu), but some don't (e.g., Fedora Core 4).

==Failed resume from suspend to disk==

Suspend to disk (using swsusp or swsusp2) needs to load the memory image from the SATA disk. For this to work, you either need an initrd with all the necessary SATA modules, or the SATA drivers compiled into the kernel.

==DVD drive not recognized==

The ata_piix SATA driver grabs ownership over the IDE ports when it is loaded, but (by default) does not support PATA ATAPI devices such as the Ultrabay optical drives. Thus, if IDE support is compiled as a module and loaded after ata_piix, the DVD drive will not be recognized by either driver.

The following configurations do work:
* Compile IDE into the kernel (non-module)
* Compile both IDE and SATA as modules and make sure IDE is loaded first
* Enable PATA ATAPI support in the SATA system (experimental; see below).

Note that the optical drive must be in the Ultrabay during system boot (Ultrabay device swapping is currently unsupported).

==No DMA on DVD drive==

Using the IDE driver, DMA support cannot be enabled on an Ultrabay optical drive:

# hdparm -d1 /dev/hdc

/dev/hdc:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

As a result, the optical drive is slow, and in particular, too slow to play video DVDs.

One workaround is to use employ the SATA driver (instead of the IDE driver) for the optical drive. This requires enabling two featues of the SATA driver, namely ATAPI support and PATA support, which are both in active development and far from stable. Using this will probably devour all your data and go on to eat all the food in your fridge. But if you have full backups and an empty fridge, do the following:

* Grab the latest kernel, since these feature are under active development (these instructions where tested with 2.6.14-rc2).
* Configure the IDE system as modules, to get it out of the way (maybe it can be completely removed).
* Configure the SATA system (and in particular the ata_piix driver) as built-in.
* In {{path|include/linux/libata.h}}, set
#define ATA_ENABLE_PATA
* In {{path|drivers/scsi/libata-core.c}}, set
int atapi_enabled = 1
(An untested alternative to the last step is to compile the SATA system as modules, make sure it is loaded before the IDE modules, and pass the "atapi_enabled=1" module parameter.)

There have been reports that DVD burning doesn't work under this configuration, but it seems to work with kernel 2.6.14-rc2 (tested on a ThinkPad {{T43}} with a [[UltraBay Slim DVD Multi-Burner Plus]]).

{{NOTE|If you are aware of a more reliable solution to this issue, please update this page.}}

==No SMART support==

The Linux SATA system currently does not support SMART commands (e.g., via smartctl). This is under development.

A Patch that works on my T43 with 2.6.12-4 kernel can be found at
http://rtr.ca/dell_i9300/kernel/kernel-2.6.12/03_libata_passthru.patch
or for 2.6.13 kernel
http://rtr.ca/dell_i9300/kernel/kernel-2.6.13/03_libata_passthru.patch

==No disk power management==

The Linux SATA system currently does not support power management commands. This is under development.

==BIOS error 2010 on user-installed hard disk==

While not a Linux issue, note that there is an issue with installing alternative PATA (IDE) hard disks as the system drive. Unless the disk is one of the few approved disks listed inside the BIOS, you will get an BIOS error 2010 during system boot, and the disk may operate unreliably. This seems to be enforced due to limitations (bugs?) of the SATA-to-PATA bridge, and currently the only reliably way to avoid it seems to be to use only drives sold by IBM specifically for use in these ThinkPad models.

There is no such limitations for disks used in the UltraBay Slim 2nd Hard Drive Adapter.

Problems with SATA and Linux

2005-09-27T03:38:34Z

Espa: /* No SMART support */

Some ThinkPad models, use a SATA controller for the system hard disk (the hard disk itself is PATA, but is accessed through a SATA-to-PATA bridge). This causes several complications for Linux installation. The following lists these problems and some workarounds.

=Models using a SATA disk interface=
'''SATA controller with IDE disk (PATA passthrough)''' 
ThinkPad {{T43}}, {{T43p}}, {{R52}}, {{X41}}, {{X41T}} 
'''SATA controller with SATA disk''' 
ThinkPad {{Z60t}}, {{Z60m}}.

=SATA-related problems under Linux=
The following is a list of SATA-related issues one may encounter when runing Linux on these ThinkPad models. Note that the details are often version- and distribution-specific.

==Hang on resume from suspend to RAM==

Linux kernels (as of 2.6.14-rc2) do not support suspend and resume for SATA devices. As a result, the machine hangs upon the first disk access after resume. A kernel patch is available (see [[How to make ACPI work]] under "Suspend to RAM").

Some distributions already include this patch (e.g., Ubuntu), but some don't (e.g., Fedora Core 4).

==Failed resume from suspend to disk==

Suspend to disk (using swsusp or swsusp2) needs to load the memory image from the SATA disk. For this to work, you either need an initrd with all the necessary SATA modules, or the SATA drivers compiled into the kernel.

==DVD drive not recognized==

The ata_piix SATA driver grabs ownership over the IDE ports when it is loaded, but (by default) does not support PATA ATAPI devices such as the Ultrabay optical drives. Thus, if IDE support is compiled as a module and loaded after ata_piix, the DVD drive will not be recognized by either driver.

The following configurations do work:
* Compile IDE into the kernel (non-module)
* Compile both IDE and SATA as modules and make sure IDE is loaded first
* Enable PATA ATAPI support in the SATA system (experimental; see below).

Note that the optical drive must be in the Ultrabay during system boot (Ultrabay device swapping is currently unsupported).

==No DMA on DVD drive==

Using the IDE driver, DMA support cannot be enabled on an Ultrabay optical drive:

# hdparm -d1 /dev/hdc

/dev/hdc:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

As a result, the optical drive is slow, and in particular, too slow to play video DVDs.

One workaround is to use employ the SATA driver (instead of the IDE driver) for the optical drive. This requires enabling two featues of the SATA driver, namely ATAPI support and PATA support, which are both in active development and far from stable. Using this will probably devour all your data and go on to eat all the food in your fridge. But if you have full backups and an empty fridge, do the following:

* Grab the latest kernel, since these feature are under active development (these instructions where tested with 2.6.14-rc2).
* Configure the IDE system as modules, to get it out of the way (maybe it can be completely removed).
* Configure the SATA system (and in particular the ata_piix driver) as built-in.
* In {{path|include/linux/libata.h}}, set
#define ATA_ENABLE_PATA
* In {{path|drivers/scsi/libata-core.c}}, set
int atapi_enabled = 1
(An untested alternative to the last step is to compile the SATA system as modules, make sure it is loaded before the IDE modules, and pass the "atapi_enabled=1" module parameter.)

There have been reports that DVD burning doesn't work under this configuration, but it seems to work with kernel 2.6.14-rc2 (tested on a ThinkPad {{T43}} with a [[UltraBay Slim DVD Multi-Burner Plus]]).

{{NOTE|If you are aware of a more reliable solution to this issue, please update this page.}}

==No SMART support==

The Linux SATA system currently does not support SMART commands (e.g., via smartctl). This is under development.
A Patch that works on my T43 with 2.6.12-4 kernel can be found at
http://rtr.ca/dell_i9300/kernel/kernel-2.6.12/03_libata_passthru.patch
or for 2.6.13 kernel
http://rtr.ca/dell_i9300/kernel/kernel-2.6.13/03_libata_passthru.patch

==No disk power management==

The Linux SATA system currently does not support power management commands. This is under development.

==BIOS error 2010 on user-installed hard disk==

While not a Linux issue, note that there is an issue with installing alternative PATA (IDE) hard disks as the system drive. Unless the disk is one of the few approved disks listed inside the BIOS, you will get an BIOS error 2010 during system boot, and the disk may operate unreliably. This seems to be enforced due to limitations (bugs?) of the SATA-to-PATA bridge, and currently the only reliably way to avoid it seems to be to use only drives sold by IBM specifically for use in these ThinkPad models.

There is no such limitations for disks used in the UltraBay Slim 2nd Hard Drive Adapter.