Difference between revisions of "Template:T23"

From ThinkWiki
Jump to: navigation, search
(T23 and ACPI and Suspend to RAM)
 
Line 1: Line 1:
 
[[:Category:T23|T23]][[Category:T23]]
 
[[:Category:T23|T23]][[Category:T23]]
== T23 and ACPI and Suspend to RAM ==
 
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 mess 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.
 
Tying Fn-f4 to "echo -n 3 >/proc/acpi/sleep" suspended the system, but
 
nothing would bring it back.  Fortunately the Power Off button was still
 
functional.
 
 
Digging around, it looked as if there were only three keys which ACPI
 
handled by default - the Power Off key, the Suspend key (Fn-F4) 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.  Fn-Home (LED brighter), Fn-End (LED dimmer), Fn-PgUp
 
(Screen light), kept on working anyway.  Fn-F3 (Screen blank), didn't
 
work and nor (fortunately) did Fn-F12, Suspend to disk; Fn-F7, 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 Fn-F4 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,
 
Fn-PgUp) 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.
 

Latest revision as of 08:04, 15 November 2005