Talk:How to make ACPI work on a ThinkPad T23

From ThinkWiki
Jump to: navigation, search

Most of the original page content, as a backup:


I recently bought a second-hand ThinkPad T23, Model 2647-4MG, and decided to run Gentoo Linux 2.6.12-r6 on it; this is the 2005.1 release on a DVD, since I have limited internet access.

The default kernel booted OK, and recognised all the devices (tho' I haven't tested the modem, and I've run X-windows only briefly.) However, I wanted software suspend, and I couldn't get that to work at all.

The first complaint from dmesg was that ACPI wasn't enabled in the BIOS; the T23 BIOS has no mention of ACPI, so I added lapic to the kernel arguments and that went away. The next problem was a large number of ACPI error messages, generally of the form AE_NOT_EXIST, so I got the Intel iasl compiler source from their site and compiled it. It compiled cleanly, and de-compiling and re-compiling the DSDT gave one Error and one Remark. I fixed them as best I could, and loaded the new DSDT on boot with the kernel's "Custom DSDT" option; this worked correctly, but dmesg still showed a lot of ACPI error messages, including two which said "Found ECDT" and "Could not use ECDT".

Rather than messing with the ECDT straightaway, I decided to upgrade to the latest BIOS and Embedded Controller BIOS. The system came with (the original) versions 1.12 and 1.04, so I downloaded versions 1.18 and 1.06a from the IBM Website. The installers come in floppy disk and Windows-based versions, and I used them under Windows 2000. Mercifully the re-flash worked as advertised, tho' interestingly the F12 "Select Boot Device" menu changed slightly, and at first it appeared to have lost the "Boot from USB" option, although that was enabled in the BIOS. Apparently the menu now simply calls a USB memory stick a hard drive. Anyway, boot from USB still works.

Booting into Linux then gave me no error messages, and dmesg showed that the ACPI had found the ECDT and enabled the interpreter. There was also a full set of ACPI entries under /proc. Although the DSDT had changed, de-compiling and re-compiling with iasl showed that the error that had originally bothered me was still there, so I let it be. I then loaded acpid, which handles the ACPI buttons through scripts in /etc/acpi. Trying FnF4 to # echo -n 3 >/proc/acpi/sleep suspended the system, but nothing would bring it back. Fortunately the Power Off button was still functional.

NOTE: On newer kernels ( > 2.6.13) /proc/acpi/sleep has been superceaded by /sys/power/state, where state can be either mem or standby (other options are available depending on system in question). so to syspend to ram you would type "echo mem > /sys/poewr/state", and for standby you woudl type "echo standby > /sys/power/state".

Digging around, it looked as if there were only three keys which ACPI handled by default - the Power Off key, the Suspend key (FnF4) and the Lid key. I found that I had to provide a handler for the Suspend key, but for simplicity I left the other two alone, and most other special purpose keys, eg. FnHome (LED brighter), FnEnd (LED dimmer), FnPgUp (Screen light), kept on working anyway. FnF3 (Screen blank), didn't work and nor (fortunately) did FnF12, Suspend to disk; FnF7, Switch to video, seemed to - at least, it blanked the LCD. I then tried unloading suspicious drivers such as USB, but could still only enter Suspend mode and not recover; finally I built a kernel with no loadable modules except networking, and the minimum of options - no USB, no PCMCIA, nothing that wasn't actually present when the machine booted. That finally worked, and I could suspend to disk with FnF4 and recover by pressing Fn (but no other key - I seem to recall that any keypress would work with the original BIOS).

When the machine is running, the Lid switch blanks the screen when pressed and restores on release, but if the machine is suspended pressing the switch does nothing and releasing it brings the machine out of suspend mode. That seems reasonable. Commands echoed to eg: /proc/acpi/ibm/light can be mixed with the appropriate keypresses (here, FnPgUp) without problems.

I started re-enabling the various bits of hardware I needed one by one, but when I re-enabled the Savage S3 framebuffer support the machine would enter suspend, but would hang partway through re-emergence.

I then disabled the S3 stuff and enabled the Intel 830M framebuffer code (I don't know how this relates to the S3 driver, but the T23 apparently has both chips) and the suspend worked again. The S3 driver is handy in text mode, since it gives more lines per screen (and a nice penguin logo on boot-up) but the system still runs eg: X windows reasonably well.

Suspending and re-emerging with USB support and a USB memory key plugged in, and with X windows running, then worked fine; at the moment I don't have the hardware to test anything more. Some things are still odd - the CPU (Pentium IIIM) has power management but not throttling, and doesn't at the moment change speed automatically. There must be a way around this, but since the CPU has only two speeds it's easier to use a shell script to flip between the performance and powersave kernel governors; everything needed can be found in the /sys/devices/system/cpu/cpu0/cpufreq directory.

The Bay LED wrongly stays lit even when in suspend mode on battery (unlike the Power LED), but the most recent (1.1) ibm_acpi module provides an ACPI LED device which controls most of the LEDs (the Bay LED is 4), and when my configuration has stabilised I'll set the LED up via the suspend script. With the CPU on low speed (if it matters) and the LED off the power consumption in Suspend mode is around 580mW.

I hope this helps someone else with their T23, because they are very nice machines, and quite versatile; this one seems to be able to deal with most forms of networking and mass storage pretty much out of the box. It looks as if the software to control full ACPI functionality has only stabilised within the last few months (ie: mid-2005), so if you have problems, try upgrading to IBM's latest BIOS and EBIOS, and a kernel >=2.12. With luck, the next version or so of the S3 driver will be free of its hang problem.