ThinkWiki - User contributions [en]

TCPA/TCG - Trusted or Treacherous

2007-06-01T08:55:51Z

Jenda:

{| width="100%"
|style="vertical-align:top;padding-right:20px;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 Members of the Trusted Computing Group (TCG), formerly the Trusted Computing Platform Allience (TCPA), are working on a paradigm shift in information technology, which could become the biggest change of the information landscape since decades.

This article tries to gather information about the implications of the TCPA and TCG effords. To many users these implications seem rather treacherous than trustworthy. This article tries to give a short summarized overview over the facts from a rather neutral point of view.

We will start with a quote:

''"It is clear that trusted computing hardware provides security benefits, if software is prepared to take advantage of it. But trusted computing has been received skeptically and remains controversial. Some of the controversy is based on misconceptions, but much of it is appropriate, since trusted computing systems fundamentally alter trust relationships. Legitimate concerns about trusted computing are not limited to one area, such as consumer privacy or copyright issues.'' <br />
''We have at least two serious concerns about trusted computing. First, existing designs are fundamentally flawed because they expose the public to new risks of anti-competitive and anti-consumer behavior. Second, manufacturers of particular "trusted" computers and components may secretly implement them incorrectly."'' <br />
''Source: [http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php Electronic Frontier Foundation]''</div>
|}

==TC – Trusted Computing==
Recently, the number of known security incidents has been dramatically increasing. Thus, security issues in computer industry have been pushed forward. So far, digital content on computers couldn't be efficiently protected since every security mechanism accessible by software could always be circumvented by software.

The idea of Trusted Computing is to provide a hardware chip (TPM) that assists software in:
* secure storage of security related data like keys, certificates, data and checksums
* encryption and decryption
* validation of certificates
* (Remote) Platform Attestation (''meaning that somebody can check the state of your personal computer over the internet'')
* Sealing (''meaning encrypting data in a state where a specific platform or application may be required to decrypt it'')

Although a TPM will assist in the above operations, software support is required to enable any enforcement of a security policy on a platform with a TPM. A TPM in and of itself cannot disable any part of your computer.

==A short history of TCPA, TCG, Palladium and NSCB:==
* 1999: The Trusted Computing Platform Alliance (TCPA) is founded by Intel, Microsoft, HP, Compaq and IBM.
* February 2002: The TCPA Main Specification Version 1.1b is being published.
* Early 2003: The name of Microsofts own TC-Projekt "Palladium" is changed to "next-generation secure computing base" (NGSCB).
* April 2003: The Trusted Computing Group (TCG) is founded by AMD, HP, IBM, Intel and Microsoft.
* Summer 2004: Microsoft seems to have stopped their "NGSCB"-effort.

==The TCPA==
Founded 1999 by Compaq, HP, IBM, Intel and Microsoft, the TCPA counts around 200 members by now, among them Adobe, AMD, Fujitsu-Siemens, Gateway, Motorola, Samsung, Toshiba and many others.

==The TCG==
As successor of the TCPA, the TCG was founded by AMD, HP, IBM, Intel and Microsoft in April 2003.

==TCG Hardware Architecture==
The Trusted Platform Module (TPM) (a.k.a. "Fritz"-Chip) is the central element of the TCG architecture. Imagine a hardwired smart card for a abstract picture of this architecture.

The integration of the whole functionality into the CPU is also discussed, which would increase resistance against tampering attacks (see also Intel "LaGrande").

Regarding the hardware security of the "Trusted Platform Modules (TPM)", there were two important critiques:
*The first one has been the insuficient security certification against hardware attacks. In TCG 1.2 this critique has been addressed by an improvement of the hardware requirements. It has to be seen how strong the resistance against sophisticated attacks at intensively daily usage will be.
*The second one addreses the 'black box'-characterisitcs and risk 'hidden channels' in the TCG-Hardware, which can be easily implemented and used to send secret information to third parties.

==TC – Treacherous Computing?==
Generally, there are good arguments that these features can be used to improve the security of computer systems. Trusted Computing offers a lot of features which can be used to protect the personal computer against malicious software and users.

But according to a lot of technical analysis, most researchers have fundamental critics on the main design considerations. The new infrastructure will offer '''only minor protection against worms and viruses''', although TCG is telling something completely different. Furthermore, some of these features can already be established by todays smart card supported systems, so where is the need for TCG 1.1?

''We recognize that hardware enhancements might be one way to improve computer security. But treating computer owners as adversaries is not progress in computer security. '''The interoperability, competition, owner control, and similar problems inherent in the TCG and NCSCB approach are serious enough that we recommend against adoption of these trusted computing technologies until these problems have been addressed. Fortunately, we believe these problems are not insurmountable''', and we look forward to working with the industry to resolve them."'' <br />
Source: [http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php Electronic Frontier Foundation], bold emphasis by [[User:Pitsche|Pitsche]]

There are a lot of drawbacks to this kind of security implementation:
*The concept prevents even the device owner from certain operations.
*Remote Attestation is a good feature to remotely detect tampering of the computer, as long as this 'somebody' is the owner of the platform. But if this Remote Attestation is used by third parties, serious privacy and market domination issues arise.
*There are certainly legitimate reasons for Sealing. But the main use case seems to be consumer-unfriendly new 'business cases' for content dealers which involve locking down content to a single platform, based on connecting content to a specific device without any migration options.

Additionally, the market domination of Microsoft, obscurities regarding the needed trust infrastructure and a heap of patents have lead to critical evaluations from cryptographers, privacy organizations and European institutions. <br />
Because of this pressure the Trusted Computing Group has modifed its proposal. The recent specification is "TCG 1.2".

=== DRM – Digital Rights Management ===
The philosophy behind Remote Platform Attestation and Sealing seems to be a protection of the computer system like a ThinkPad or electronic device like a MP3-Player ''against'' its user and owner.

What will do this to the use of digital media content on computers or other electronic devices? The answer of the IT- and the Entertainment-Industry is "Digital Rights Management" or just shortly "DRM".

''The DRM component takes control over the rest of the user's device which they rightfully own (e.g. MP3-Player'' '''or a ThinkPad)''' ''and restricts how it may act, regardless of the user's wishes (e.g. preventing the user from copying a song). All forms of DRM depend on the device imposing restrictions that cannot be legally disabled or modified by the user. In other words, the user has no choice.'' Bold emphasised by [[User:Pitsche]].

So a new 'name' for DRM came up: '''Digital Restrictions Management''' instead of Digital Rights Management.

Read more at [[Wikipedia:Digital rights management]].

Keep in mind that neither enabling your TPM or installing [http://trousers.sourceforge.net TrouSerS] will implement any DRM features on your ThinkPad. Other software packages that implement DRM on Linux should be posted here.

=== Censorship and Avoiding Whistle Blowers ===
The Siamese twin of Digital Restriction Management is censorship. '''The same techniques which avoid copying music songs can be used to limit the access to all kinds of documents'''. The combination of DRM and observation hardware like TCG leads to very dangerous implications.

Giving a real world example, the Chinese government could easily block the use of all documents containing the words "Dalai Lama" on 'trusted' computer systems.

Another application is the fight against whistle blowers. E.g. government documents about the deportation of own citizens to countries with a doubtful law system or about supporting illegal wars could be made readable for government computers only and combined with a expiration date. This might make it very dificult for the society or following generations to disclose these breaches of humanity.

=== Summary ===
There are still a lot of critical questions, even though TCG 1.2 contains many steps into the right direction.

== Thinkpads with and without TCPA/TCG ==

If you want to know, which ThinkPads are equipped with TCPA Technology like IBM Embedded Security Subsystem or IBM Embedded Security Subsystem 2.0 and which of them are TCPA/TCG clean models, please [[Embedded Security Subsystem#Models featuring this Technology|see the complete list of models]] at the article about [[Embedded Security Subsystem]].

== OpenSource Software and TCG ==
The TrouSerS project aims at implementing each TSS (Trusted computing Software Stack) specification as it is released. TrouSerS is now part of the [http://packages.gentoo.org/packages/?category=app-crypt;name=trousers Gentoo] distribution.

There are many misconceptions surrounding open-source software and trusted computing. Please see the [http://trousers.sf.net/faq.html TrouSerS FAQ] for answers to some common questions.

== Related Links ==
*[http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html 'Trusted Computing' Frequently Asked Questions] - Anti-TC FAQ by Cambridge University security director and professor [[Ross Anderson]].
*[http://www.againsttcpa.com/ Against-TCPA]
*[http://invisiblog.com/1c801df4aee49232/article/0df117d5d9b32aea8bc23194ecc270ec Interesting Uses of Trusted Computing]
*[http://www.gnu.org/philosophy/can-you-trust.html Can you trust your computer?] essay by the FSF
*[http://www.protectprivacy.org/topic--lang-en.html The civil rights organisation Protect Privacy]
*[http://trousers.sourceforge.net/faq.html The TrouSerS FAQ.]

*[http://www.lafkon.net/tc/ Animation in three different qualities about Trusted Computing]

== Read more at Wikipedia, the free encyclopedia: ==
*[http://en.wikipedia.org/wiki/Trusted_computing Trusted Computing]
*[http://en.wikipedia.org/wiki/Trusted_Computing_Platform_Alliance Trusted Computing Group (formerly known as TCPA)]
*[http://en.wikipedia.org/wiki/Fritz-chip Fritz-Chip]
*[http://en.wikipedia.org/wiki/Palladium_operating_system Palladium]
*[http://en.wikipedia.org/wiki/Category:Cryptography Wikipedia-Category: Cryptography]
*[http://en.wikipedia.org/wiki/Category:Copyright_law Wikipedia-Category: Copyright Law]
*[http://en.wikipedia.org/wiki/Category:Digital_rights_management Wikipedia-Category: Digital Rights Management]


[[Category:Glossary]]
[[Category:Trusted Computing]]

How to make ACPI work

2007-05-24T19:13:36Z

Jenda: /* ThinkPads on which it is recommended to use ACPI */

==General==
===Kernel configuration===
First of all you'll have to enable ACPI support in your kernel (if your distro doesn't already have an ACPI enabled kernel).
To do this open your kernel config and enable ACPI Power Management:
:{{kernelconf|CONFIG_PM|<*>|Power Management support|Power management options|||}}
:{{kernelconf|CONFIG_ACPI_SLEEP|<*>|ACPI|Power management options|||}}

You'd most likely want to enable the following ACPI options:
:{{kernelconf|CONFIG_ACPI_SLEEP|<*>|Sleep States|ACPI|Power management options||}}
:{{kernelconf|CONFIG_ACPI_AC|<*>|AC Adapter|ACPI|Power management options||}}
:{{kernelconf|CONFIG_ACPI_BATTERY|<*>|Battery|ACPI|Power management options||}}
:{{kernelconf|CONFIG_ACPI_FAN|<*>|Fan|ACPI|Power management options||}}
:{{kernelconf|CONFIG_ACPI_PROCESSOR|<*>|Processor|ACPI|Power management options||}}
:{{kernelconf|CONFIG_ACPI_THERMAL|<*>|Thermal Zone|ACPI|Power management options||}}

If you prefer editing your {{path|.config}} file directly, you should set at least the following variables:
CONFIG_PM=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y

Then recompile your kernel.

{{HINT| ACPI SLEEP States option did only show up for me after patching [[Software Suspend 2]] into the kernel. With a vanilla 2.6.17 kernel, one must enable CONFIG_SMP and CONFIG_HOTPLUG_CPU for the option to appear, cf. [http://bugs.debian.org/383059 Debian bug #383059] .}}

===Kernel boot parameters===
Many ThinkPads have been hit by a recent (kernel 2.6.16) change to ACPI4Linux that changed the default means of accessing the ACPI Embedded Controller as a way to shake out underlying bugs in the EC access code. If your ThinkPad fails to resume properly (a blinking Sleep light on resume that doesn't go away, or a hang when trying to suspend/standby a second time), adding {{bootparm|ec_intr|0}} to your kernel command line may help.

===IBM specific ACPI driver===
Unfortunately, special drivers for ACPI on ThinkPads were not included with kernels prior 2.6.10. So you'll have to compile one yourself or get it as precompiled module for your kernel.

You have the choice between [[thinkpad-acpi]] and [[ibm-acpi]], with the latter being the recommended one.

If you use a post-2.6.10 kernel and you want to use [[ibm-acpi]], it is recommended to look on its projects page for a possibly newer version.

{{HINT|Generally it is a good idea to read the README included with the driver.}}

===ACPI daemon===
Also you'll need to install [[acpid]], if it isn't present on your system. [[acpid]] is a daemon that handles the ACPI events generated by the system. Read [[How to configure acpid]].

==Screen blanking (Standby)==
Make sure you have
Option "DPMS"
in the Monitor section of your {{path|/etc/X11/XF86Config}} or {{path|/etc/X11/xorg.conf}}.

Running {{cmduser|xset +dpms}} and then {{cmduser|xset dpms force off}} will turn off the backlight on a laptop screen.<br />

Note that this may not work in combination with {{cmduser|echo -n "mem" > /sys/power/state}} because switching to console causes the backlight to come back on before sleeping.

==Suspend to RAM (Sleep)==
ACPI Sleep/suspend-to-ram with recent 2.6.x kernels usually works fine. Have a look at the [[How to configure acpid|acpid configuration HOWTO]]. It includes a specific example for going to sleep on lid close.

For Troubleshooting, look at the [[Problems with ACPI suspend-to-ram|Problems with ACPI suspend-to-ram page]].

==Suspend to disk (Hibernate)==
There are two drivers for this available:
* [[swsusp]], which is in the kernel and
* [[Software Suspend 2]] which is more feature rich, but not yet in the kernel, so you have to patch it in yourself.

Both are reported to work fine as long as you use open-source graphic drivers. A comparison of the features can be found on [http://softwaresuspend.berlios.de/features.html this page].

Just in case you are in doubt...yes, it is safe in both cases to use the same swap partition as active swap and as suspend partition.

See the according drivers page for instructions.

==ThinkPads on which it is recommended to use ACPI==
*ThinkPad {{770X}}, {{770Z}}
*ThinkPad {{A20m}}, {{A20p}}, {{A20m}}, {{A20p}}, {{A21e}}, {{A21m}}, {{A21p}}, {{A22e}}, {{A22m}}, {{A22p}}, {{A30}}, {{A30p}}, {{A31}}, {{A31p}}
*ThinkPad {{G40}}, {{G41}}
*ThinkPad {{R30}}, {{R31}}, {{R32}}, {{R40}}, {{R40e}}, {{R50}}, {{R50e}}, {{R50p}}, {{R51}}, {{R52}}, {{R60}}
*ThinkPad {{T22}}, {{T23}}, {{T30}}, {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}
*ThinkPad {{X20}}, {{X21}}, {{X22}}, {{X23}}, {{X24}}, {{X30}}, {{X31}}, {{X32}}, {{X40}}, {{X41}}, {{X41T}}
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}
*ThinkPad {{X60s}}
*ThinkPad {{TransNote}}
*ThinkPad {{T20}} and {{T21}} have old ACPI implementations, but there have been some reports of using ACPI successfully on these models with Ubuntu and Mandriva in particular. Check the related pages about installing Linux on these models for details.

How to control fan speed

2007-05-24T05:45:56Z

Jenda: /* 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 or [http://ibm-acpi.sourceforge.net ibm-acpi.sf.net] releases}}
{{NOTE|Advanced fan control through ibm-acpi has been merged in Linux 2.6.20-rc2 mainline, so users of 2.6.20 won't need to patch their kernels to get the '''fan level''' functionality anymore}}

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 used 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 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)

Changing modes may not be immediate on all ThinkPads. Later ThinkPad models seem to take at least 5s to start responding to a fan mode change, for example.

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

=== Fan Tachometer ===

The embedded controller registers 0x84 (LSB), 0x85 (MSB) are the main fan tachometer, and report fan speed in RPM in everything since the {{A31}} and maybe a little earlier. Not much is know about the tachometer in earlier models, or even whether they had one or not.

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

Note that the ACPI DSDT may supplement this in some models. The {{X40}}, for example, changes the profile of speeds the automatic mode should use depending on battery status.

=== Manual mode ===

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.

=== Disengaged (full-speed) mode ===

In ''disengaged'' mode, the embedded controller does not monitor the fan speed. It "disengages" the closed-loop control function that keeps track of fan speed, and uses an open-loop control function that ramps up the fan to its maximum speed (100% duty-cycle). The end speed is not stable, but it is often much faster than the maximum speed manual and automatic modes would set the fan to.

Most newer ThinkPads take quite a while (in excess of one minute) to fully enter disengaged mode. Exiting it is much faster. The {{A31}} acts differently, and switches to disengaged mode as fast as it switches to other modes.

For some reason, the embedded controller may stop updating the tachometer registers while entering or exiting disengaged mode in some ThinkPad firmware versions (hence the EC tachometer registers will not be updated on these models while entering/exiting disengaged mode). Once it arrives at maximum speed, or once it gets back at closed-loop cruise speed, the embedded controller starts updating the tachometer registers again. Later T models such as the {{T43}} have this problem, while the {{A31}} does not.

{{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 {{T60}} (fan levels RPM: 1-2 = 3000-3100, 3-5 = ~3600, 6-7 = ~4500; disengaged mode works at ~5500)
* ThinkPad {{T43}}, {{T43p}} (fan levels RPM: 1-2 = ~3300, 3-5 = ~4100, 6-7 = ~4700; disengaged mode works at ~6450)
* 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 {{R51e}} (level 0 = off, level 1-2 = ~3300, level 3-5 = ~3800, level 6 = ~4150, disengaged = ~5100)
* ThinkPad {{R60}}
* 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 {{Z61p}} (fan levels 0-7, auto, disengaged; enable, disable; watchdog (untested))
* 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 display remaining black after resume

2007-05-09T13:30:41Z

Jenda: /* Solution for ThinkPads with ATI graphic chips and Intel 915/945GM */

There has been a problem encountered where the display stays black on resuming from suspend.

The symptom might have you think first that your system hang up, but you will realize that your ThinkPad works and you can even reset it via {{key|Ctrl}}{{key|Alt}}{{key|Del}}.

==Affected Models==
*ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}
*Thinkpad {{T23}}
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}}
*ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}
*ThinkPad {{A30p}}
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on)
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}
*ThinkPad {{X60s}}, {{X60}}

==Affected Operating Systems==
*Linux (it's a kernel issue)
*FreeBSD (6.x at least)

==Solutions==
===Semi-Solution for ThinkPad X60 with damaged system after s2ram usage===
It happend when restarting a s2ram-session.

'''Symptom:''' Black screen with blinking "_" sign remaind. (without the ")

'''System status:''' HDD idle, fan running, everything else looks to wait for something to happen.

'''Semi-Solution:''' Booting with DVD-ROM and going through the installations menu,
where you choose "other" and "boot a installed system" (something like that). Gladly it works,
and OpenSuSE 10.1 comes up with 50% "failed" messages! I than shutdown properly, rebooted again
and had 100% "done" again, with no other things affected.

'''Further:''' Repairing with the DVD-ROM crashed massivly(!), so I selected "boot a installed system" as final
solution and it worked!

'''Unknown:''' Maybe the Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM will help,
because X60s and X60 are very familiar. (Not tested so far.)

(If this Problem is not right here, please edit and move.)

===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM ===
see [[1400x1050 on Intel 915GM]].
===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM ===

Affected models include {{X60s}} and {{R60}}.

This soluton also applies to T42 with Intel 855 and ATI 9600 M10.

One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line.

For grub this would look like this:

title Linux, kernel 2.6.11-1-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1-686 root=/dev/hda1 ro acpi_sleep=s3_bios
initrd /boot/initrd.img-2.6.11-1-686
savedefault
boot

For lilo it would look like this:

image=/boot/vmlinuz
append="acpi_sleep=s3_bios"

The actual process of going to sleep is then managed through a sleep script; as a start, see the {{path|sleep.sh}} script in the Extreme Graphics 2 section below, but note the following comments:

In [[:Category:OpenSUSE|OpenSUSE]] 10.1 (at least on a T43p), it's necessary to override the default options for s2ram if you're using the newer ATI driver. This can be done putting {{bootparm|SUSPEND2RAM_FORCE|"yes"}} and {{bootparm|SUSPEND2RAM_ACPI_SLEEP|"3"}} in {{path|/etc/powersave/sleep}}.

In {{Ubuntu}} or {{Kubuntu}}, it may be necessary to modify {{path|/etc/default/acpi-support}}. In that file, make sure that {{path|ACPI_SLEEP}} is uncommented and set to true. With ATI chips, also make sure that {{path|SAVE_VBE_STATE}} is uncommented and set to true; with Intel chips, on the other hand, ensure that nothing is done with respect to VBE--no reposts, no state saves.

In {{Fedora}}, it may be necessary with the Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}} to comment out the VBE post and restore. (As of FC6 these seem to be pre-commented out.) Also, the laptop, after waking up, may go back to sleep immediately or whenever the AC adapter is disconnected. When this happens, it's caused by a bug in the HAL daemon that incorrectly reports certain ACPI events. This is a known problem and a simple workaround is described [http://live.gnome.org/GnomePowerManager/Faq#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb here].

{{NOTE|It is possible this method will not work if the laptop is docked. It is also possible that the cited workaround for the HAL daemon bug will not work on some machines. A kludgier workaround in this event is to kill the HAL daemon on suspend. This necessitates the resuscitation of GPM upon resume.}}

Another solution is to use vbetool. If you are using {{Debian}} with the hibernate package, uncomment "EnableVbetool yes" in {{path|/etc/hibernate/hibernate.conf}} (or {{path|/etc/hibernate/ram.conf}}).

===Solution for ThinkPads with Intel Extreme Graphics 2===
{{NOTE|
On [[:Category:X40|X40]]s/[[:Category:X41|X41]]s - even with Intel Extreme Graphics - and for [[:Category:R52|R52]]s with Intel Graphics Media Accelerator 900 the [[Problem with display remaining black after resume#Solution for ThinkPads with ATI graphic chips|solution for ATI graphics chips]] above is reported to work. In this case, make sure no changes to VBE are made, especially no state saves and no reposts.}}

The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
*First of all, '''do not''' use the {{bootparm|acpi_sleep|s3_bios}} kernel parameter.
*Second, completely remove framebuffer support from your kernel. If it's built as modules, it is important that they do not get loaded at all.
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}.
*On resume, restore the video state with {{cmdroot|cat /tmp/video_state > /proc/bus/pci/00/02.0}} and change back to X.
*For Debian Etch 4.0 on R50e just make following changes to /etc/default/acpi-support:
#SAVE_VBE_STATE=true
#VBESTATE=/var/lib/acpi-support/vbestate
#POST_VIDEO=true
SAVE_VIDEO_PCI_STATE=true

*For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding
Option "VBERestore" "yes"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}, and the example script below.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

# change to console 1
FGCONSOLE=`fgconsole`
chvt 6

# safe video state
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# go to sleep
echo -n 3 > /proc/acpi/sleep

# waking up
# restore system clock
hwclock --hctosys

# restore video state
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# clean up behind us
rm /tmp/video_state

With Ubuntu 6.10 on a [[:Category:R51|R51 (2887-32G)]] I ''just'' (as none of the other tricks above) had to add {{bootparm|fb|false}} to the kernel line in {{path|/etc/grub/menu.lst}} and edit {{path|/etc/defaults/acpi-support}} this way:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false

===Solution for ThinkPads with Intel I830 Chipset===
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16.
*this works with vesafb and also with intelfb frambuffer support.
The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

FGCONSOLE=`fgconsole`
chvt 8
sync
hwclock --systohc

echo -n "mem" > /sys/power/state

hwclock --hctosys
vbetool post

if [ "$FGCONSOLE" -ge "7" ] ; then
chvt $FGCONSOLE
else
chvt 7
chvt $FGCONSOLE
fi
===Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD===

The FreeBSD acpi(4) manpage mentions a tunable parameter, "hw.acpi.reset_video":

hw.acpi.reset_video
Reset the video adapter from real mode during the resume path.
Some systems need this help, others have display problems if it
is enabled. Default is 0 (disabled).

This tunable can be set by adding the following line to your FreeBSD machine's /boot/loader.conf file:

hw.acpi.reset_video="1"

And rebooting your machine. Hopefully, the next time you resume from a suspend, you'll see your video again. This solution doesn't appear to be specific to ATI hardware in any way, so I presume it would be helpful for video chipsets other than ATI, as well.

If this entry doesn't help you, you might consider searching in the [http://lists.freebsd.org/pipermail/freebsd-mobile/ FreeBSD-Mobile email-list archive] for more insight.

{{footnotes|
#If you have this problem with R50e and the above solution doesn't work, try switching to console first. An example sleep script can be found [[How to configure acpid|here]].
}}

Problem with display remaining black after resume

2007-05-09T13:29:10Z

Jenda: /* Affected Models */

There has been a problem encountered where the display stays black on resuming from suspend.

The symptom might have you think first that your system hang up, but you will realize that your ThinkPad works and you can even reset it via {{key|Ctrl}}{{key|Alt}}{{key|Del}}.

==Affected Models==
*ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}
*Thinkpad {{T23}}
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}}
*ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}
*ThinkPad {{A30p}}
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on)
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}
*ThinkPad {{X60s}}, {{X60}}

==Affected Operating Systems==
*Linux (it's a kernel issue)
*FreeBSD (6.x at least)

==Solutions==
===Semi-Solution for ThinkPad X60 with damaged system after s2ram usage===
It happend when restarting a s2ram-session.

'''Symptom:''' Black screen with blinking "_" sign remaind. (without the ")

'''System status:''' HDD idle, fan running, everything else looks to wait for something to happen.

'''Semi-Solution:''' Booting with DVD-ROM and going through the installations menu,
where you choose "other" and "boot a installed system" (something like that). Gladly it works,
and OpenSuSE 10.1 comes up with 50% "failed" messages! I than shutdown properly, rebooted again
and had 100% "done" again, with no other things affected.

'''Further:''' Repairing with the DVD-ROM crashed massivly(!), so I selected "boot a installed system" as final
solution and it worked!

'''Unknown:''' Maybe the Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM will help,
because X60s and X60 are very familiar. (Not tested so far.)

(If this Problem is not right here, please edit and move.)

===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM ===
see [[1400x1050 on Intel 915GM]].
===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM ===

Affected models include {{X60s}}.

This soluton also applies to T42 with Intel 855 and ATI 9600 M10.

One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line.

For grub this would look like this:

title Linux, kernel 2.6.11-1-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1-686 root=/dev/hda1 ro acpi_sleep=s3_bios
initrd /boot/initrd.img-2.6.11-1-686
savedefault
boot

For lilo it would look like this:

image=/boot/vmlinuz
append="acpi_sleep=s3_bios"

The actual process of going to sleep is then managed through a sleep script; as a start, see the {{path|sleep.sh}} script in the Extreme Graphics 2 section below, but note the following comments:

In [[:Category:OpenSUSE|OpenSUSE]] 10.1 (at least on a T43p), it's necessary to override the default options for s2ram if you're using the newer ATI driver. This can be done putting {{bootparm|SUSPEND2RAM_FORCE|"yes"}} and {{bootparm|SUSPEND2RAM_ACPI_SLEEP|"3"}} in {{path|/etc/powersave/sleep}}.

In {{Ubuntu}} or {{Kubuntu}}, it may be necessary to modify {{path|/etc/default/acpi-support}}. In that file, make sure that {{path|ACPI_SLEEP}} is uncommented and set to true. With ATI chips, also make sure that {{path|SAVE_VBE_STATE}} is uncommented and set to true; with Intel chips, on the other hand, ensure that nothing is done with respect to VBE--no reposts, no state saves.

In {{Fedora}}, it may be necessary with the Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}} to comment out the VBE post and restore. (As of FC6 these seem to be pre-commented out.) Also, the laptop, after waking up, may go back to sleep immediately or whenever the AC adapter is disconnected. When this happens, it's caused by a bug in the HAL daemon that incorrectly reports certain ACPI events. This is a known problem and a simple workaround is described [http://live.gnome.org/GnomePowerManager/Faq#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb here].

{{NOTE|It is possible this method will not work if the laptop is docked. It is also possible that the cited workaround for the HAL daemon bug will not work on some machines. A kludgier workaround in this event is to kill the HAL daemon on suspend. This necessitates the resuscitation of GPM upon resume.}}

Another solution is to use vbetool. If you are using {{Debian}} with the hibernate package, uncomment "EnableVbetool yes" in {{path|/etc/hibernate/hibernate.conf}} (or {{path|/etc/hibernate/ram.conf}}).

===Solution for ThinkPads with Intel Extreme Graphics 2===
{{NOTE|
On [[:Category:X40|X40]]s/[[:Category:X41|X41]]s - even with Intel Extreme Graphics - and for [[:Category:R52|R52]]s with Intel Graphics Media Accelerator 900 the [[Problem with display remaining black after resume#Solution for ThinkPads with ATI graphic chips|solution for ATI graphics chips]] above is reported to work. In this case, make sure no changes to VBE are made, especially no state saves and no reposts.}}

The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
*First of all, '''do not''' use the {{bootparm|acpi_sleep|s3_bios}} kernel parameter.
*Second, completely remove framebuffer support from your kernel. If it's built as modules, it is important that they do not get loaded at all.
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}.
*On resume, restore the video state with {{cmdroot|cat /tmp/video_state > /proc/bus/pci/00/02.0}} and change back to X.
*For Debian Etch 4.0 on R50e just make following changes to /etc/default/acpi-support:
#SAVE_VBE_STATE=true
#VBESTATE=/var/lib/acpi-support/vbestate
#POST_VIDEO=true
SAVE_VIDEO_PCI_STATE=true

*For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding
Option "VBERestore" "yes"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}, and the example script below.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

# change to console 1
FGCONSOLE=`fgconsole`
chvt 6

# safe video state
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# go to sleep
echo -n 3 > /proc/acpi/sleep

# waking up
# restore system clock
hwclock --hctosys

# restore video state
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# clean up behind us
rm /tmp/video_state

With Ubuntu 6.10 on a [[:Category:R51|R51 (2887-32G)]] I ''just'' (as none of the other tricks above) had to add {{bootparm|fb|false}} to the kernel line in {{path|/etc/grub/menu.lst}} and edit {{path|/etc/defaults/acpi-support}} this way:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false

===Solution for ThinkPads with Intel I830 Chipset===
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16.
*this works with vesafb and also with intelfb frambuffer support.
The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

FGCONSOLE=`fgconsole`
chvt 8
sync
hwclock --systohc

echo -n "mem" > /sys/power/state

hwclock --hctosys
vbetool post

if [ "$FGCONSOLE" -ge "7" ] ; then
chvt $FGCONSOLE
else
chvt 7
chvt $FGCONSOLE
fi
===Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD===

The FreeBSD acpi(4) manpage mentions a tunable parameter, "hw.acpi.reset_video":

hw.acpi.reset_video
Reset the video adapter from real mode during the resume path.
Some systems need this help, others have display problems if it
is enabled. Default is 0 (disabled).

This tunable can be set by adding the following line to your FreeBSD machine's /boot/loader.conf file:

hw.acpi.reset_video="1"

And rebooting your machine. Hopefully, the next time you resume from a suspend, you'll see your video again. This solution doesn't appear to be specific to ATI hardware in any way, so I presume it would be helpful for video chipsets other than ATI, as well.

If this entry doesn't help you, you might consider searching in the [http://lists.freebsd.org/pipermail/freebsd-mobile/ FreeBSD-Mobile email-list archive] for more insight.

{{footnotes|
#If you have this problem with R50e and the above solution doesn't work, try switching to console first. An example sleep script can be found [[How to configure acpid|here]].
}}