The basic idea of this page is to help other customers to invest their money better. Tell the companies that you want Linux hardware. Share the word - report incompatibilities and problems on the Internet.
This page shall give some hints and impressions of what works and what doesn't work on the IBM ThinkPad R31 (2656) using Linux. The ThinkPad R31 is a low budget notebook with a 13.3 or 14.1 inch TFT display. In my opinion IBM did a good job with this thing if you're willing to ignore the problems with the APM BIOS (see list below).
Please note that the most important statement for ThinkPad users may be my 'solution' for the TrackPoint / mouse problem with the jumping / skipping cursor (see in the APM section).
An overview of problems/bugs is enlisted here:
I really encourage you to make use of your customer rights and contact IBM support for help with these problems! On the one side, computers are the most complicated things mankind has ever built. On the other side, no one should sell something that doesn't work correctly.
There's a page with a tool called ThinkPad configuration tools for Linux which I didn't try yet. But you're welcome to share your experiences with me.
This is what lspci reports on the PCI bus:
00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 04) 00:02.0 VGA compatible controller: Intel Corp. 82830 CGC [Chipset Graphics Controller] (rev 04) 00:02.1 Display controller: Intel Corp. 82830 CGC [Chipset Graphics Controller] 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) 00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02) 01:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) Chipset Ethernet Controller (rev 42) 01:09.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
First of all, you have to get rid of the preinstalled Windows. Even Windows XP likes to crash. I don't want to waste my battery time rebooting the OS because some settings changed or something crashed.
I think its the best choice to leave the crap on a small partition for test purposes. Furthermore, if you read on, you'll see that not all hardware is supported under Linux. So you may wish to switch back to Windows to use this hardware, i.e. download mail via modem that is not fully supported under Linux.
Note: IBM does not provide recovery CDs with the ThinkPad. Instead they allocated a hidden Fat32 partition on the harddisk. On this partition there seems to be a full base XP installation. What a waste of space! But as we all know, Windows must be reinstalled completely from time to time because the registry gets corrupted, so better don't touch this thing, or you will never be able to play Solitaire again ;). The recovery partition is used by the BIOS to recover Windows, so in my view this is a god-given plague you can't and shouldn't change. Without this partition the BIOS could be very unhappy ;).
In the past I thought it is a good idea to install a journaling filesystem. This was a mistake. I experienced that journaling filesystems access the hard disk approximately all 5 seconds. So spinning down the disk is impossible when using journaling file systems (seen this for reiserfs, and someone reported this to be similar for ext3).
On my desktop machine I've got reiserfs. All hard drives except the one containing the root partition spin down. My advice: Use ext2 and wait for the journaling file systems to become notebook compatible!
The R31 has no floppy disk. That's ok for me. You can boot your Linux installation media from the builtin CDROM (or DVD), though. I used SUSE 8.0 which seemed to be a good choice.
Most hardware is autodetected, and you have to do very little to make things working.
One thing is to setup apmd which didn't get
setup by default on my system.
Another good idea is to compile your own Linux kernel. With all the settings and stuff you need for your notebook. This kernel will have nothing superfluous like the fully featured kernels from the Linux distributions.
A normal LILO boot loader in the Master Boot Record (MBR) works on the R31 since there was nothing important in the boot block.
The heart of the R31 is a mobile IntelTM CeleronTM
CPU at a clock of 1133 MHz.
/proc/cpuinfo says this:
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 11 model name : Intel(R) Celeron(TM) CPU 1133MHz stepping : 1 cpu MHz : 1133.227 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 2260.99
And on bootup, you'll see this:
Initializing CPU#0 Detected 1133.227 MHz processor. CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000 CPU: Common caps: 0383f9ff 00000000 00000000 00000000 CPU: Intel(R) Celeron(TM) CPU 1133MHz stepping 01
Some people reported CPU is said to support the SpeedStep technology. Actually even Intel marketing documents showed that only full Pentium processors support this. There's a kernel patch called Linux CPUFreq that enables you to manually speedstep the CPU. It says this on bootup:
cpufreq: Intel(R) SpeedStep(TM) support $Revision: 1.32 $ Intel(R) SpeedStep(TM) for this processor not (yet) available.
So I think there's no hope for SpeedStep.
The IDE motherboard circuit is supported (Intel PIIX4) and
seems to work with DMA. This is true for the
harddisk (/dev/hda) and the CDROM
(/dev/hdc).
Spinning down the disk after a while of inactivity is a good power saver. In the best case, the system can run with the buffered disk data without ever accessing the disk. In theory!
There are some things you should know about file systems and hard disks:
hdparm can be used to
control the auto spindown feature of
your IDE drives. The hard drive spins down
after a fixed interval of inactivity.
This inactivity interval is the origin
for the following techniques to reduce
hard disk activity.
A little introduction about tuning your hard disk and getting speedups is given here.
You can actively spin down your hard disk with Riko Jacob's xspdwn, a small X11 program.
kupdated.
Read access can be served from buffered blocks.
kupdated writes out its dirty
blocks in more or less fixed intervals. One
solution is to tune the interval time.
Tuning can be done by writing stuff into the
virtual file /proc/sys/vm/bdflush.
A problem with tuned long intervals: If
you tune your kupdated to always
flush the blocks every 30 minutes and your
computer crashes, you will lose all work
from the last 30 minutes in the worst case! If you have
a stable system, you can probably live with this.
Also note that your system may begin to flush
buffers if dirty buffers fill all of your memory.
There's a nice daemon called
noflushd
which tries to queue all writes to a hard disk until
an unbuffered read is performed. Unfortunately
this program has problems with journaling file systems,
especially reiserfs (version from 30 Aug 2002).
My experience with a ext2 hard disk is very positive.
It performs much better than just setting a timeout
with hdparm because it operates on
operating system level.
There's a little bigger risk losing unflushed data
on a system crash, but if your system works
stable there's nothing to worry about. Manually
executing sync still works if you
want to ensure your data saved.
But please keep in mind that the mechanics of the
hard drive will suffer if the spindle motor is spinned up
and down too often.
atime,
or access time. On most Linux file systems there is a
time field for each file that tells us when the file
was last accessed besides the well known
field that tells us when the file was last modified.
This access time field is even updated when a
file is read. This means: You read a file, and
something gets written as an effect.
Not very
good if you want your drives to spin down.
You can suppress this behaviour by mounting a
partition with the noatime mount
option.
in /etc/fstab, this would look like this:
/dev/hda6 / ext2 defaults,noatime 0 0
There may be applications / daemons out there which rely on the access time to be updated on read access, but I had no problems so far.
The machine comes with the Intel 830 MG chipset which seems to be quite ok. It uses main memory as so-called shared memory for the graphics, so don't expect rough performance like you know it from your desktop! This is no GameboyTM, but a test installation of Quake 3 under Windows showed that the 3D performance is quite ok.
The chipset is auto detected by SUSE's SAX program as a i810 chipset. The i810 chipset is compatible to the i830 chipset concerning to Intel. Intel's advice on how setting up even 3D acceleration (OpenGL) under XFree86 4.2 can be found here. I didn't manage to get it to work using Intels advices.
I managed to get it to work using XFree v4.3 in conjunction with i830-20030517-linux.i386.tar.bz2 kernel and userland drivers.
Note that you need to have a GLX enabled libGL.so. You can get
it from XF86 directly (maybe you need to compile it), or from your distribution.
You can get some
information about the GLX method used on your system
using the command glinfo.
Furthermore take a look at the /var/log/XFree86.0.log
and see whether opening /dev/dri/card0 succeeds.
The latter is the kernel side of the story.
I can give you no special hints or a step-by-step-sollution because most of the stuff is really heavily distribution dependant. One final note: make sure everything got compiled with the same compiler version. If you're curious, you can take a look at my XF86Config.
Sound is implemented in the i830 chipset also. There seems to be no
native kernel driver working, but ALSA does the job quite well.
ALSA stands for Advanced Linux Sound Architecture and
is a kernel module with additional drivers not found in the
standard kernel.
The project homepage can be found at
http://www.alsa-project.org/.
If your distribution doesn't include ALSA, install it and
call alsaconf as the super user. After that,
you need to install the user space part, and that's it.
ALSA recognizes the sound system as snd-intel8x0
which looks (and sounds) quite ok.
The R31 has a builtin 10/100 MBit ethernet controller. It is recognized as an Intel EtherExpress pro, and it is natively supported by the kernel and works well.
The modem is a WinModem which means that it is a silly sound circuit that doesn't understand Hayes commands. Modems never needed drivers until WinModems and modem cards emerged.
Fortunately I've found a driver for this modem under Linux! The fine people at SmartLink have done it: A Linux driver for HAMR5600 based AMR/CNR/MDC/ACR modem cards. Thank you, guys at SmartLink!
I tried this driver on Linux kernel v2.4.19 with slmdm-2.7.8_debug and
it connected with only 28k baud (I expected 56k baud). I'm currently
investigating the reason for this.
Unfortunately the driver is NOT open source.
If you're looking for the driver on SmartLink, go through the download section and agree to the license, then choose Linux and then 'make and go'! The driver is available as a kernel module and therefore you don't have to recompile the whole kernel.
Another place to get (a possibly newer version of the driver) is the linmodem resources page. Note that the ftp server of SmartLink used to contain a newer version, but it isn't there anymore.
If you are looking for the AT commands and S register configurations, simply click for 'Support' on the web site!
The keyboard has all standard keys, except the windows keys of the desktop machines that are really useful like a pile of dirt.
The quality of the keyboard is only moderate. The keys sometimes hang when typing. But I think there must be a reason for the good price.
As far as I can judge the beloved CTRL-ALT-DEL keyboard shortcut doesn't work on the ThinkPad. It's really a missing feature regarding the preinstalled OS!! I was lucky to find out that the power switch located at the top of the keyboard also acts as an off-switch if you push it for 5 seconds. I didn't see this somewhere documented.
The keyboard has a kind of numerical block that is
overlayed with some keys in the normal keyboard area.
It has got to be accessed with the
keyboard modifiers Fn and Shift
at once. Caps Lock instead of Shift
doesn't work.
The keyboard has some non-standard keys like the ThinkPadTM key, volume keys, and a mute key. They are said to be supported under Linux if you're using special keyboard mappings, but I didn't take a closer look at it. Muting the audio signal works using the mute key, and unmuting it works using the volume up key (not the mute key again!).
The most important key on the keyboard is the
Fn key that is used to access
special ThinkPad functions. In combination
with other keys on the keyboard you can
switch between internal and external display,
put the computer into suspend mode, change the
intensity of the display, toggle the
ThinkLight, and so on.
IBM notebooks usually don't come with a trackpad, they come
with a so called TrackPointTM. The TrackPoint is
a little stick located between the g, h and
b keys on the
keyboard. It can be pushed in horizontal and vertical
direction to move the mouse pointer, and it even can
detect the pressure of your pushing onto it.
This information can be processed with special utilities
(take a look at
Linux TrackPoint Utilities).
The TrackPoint has three buttons below the keyboard that are supported and work well.
SAX autodetected the TrackPoint as a normal
PS/2 device which is quite correct. The TrackPoint works
well, but from time to time it jumps to the upper right
edge of the screen and has some random mouse button hits.
For more on this problem, see the APM section.
There's also a IBM site that is dedicated to the TrackPoint: The TrackPoint support page. Beware, prehistoric DOSTM crap, but also some documents there!
The TrackPointTM is a little different to control compared to a trackpad or a mouse. And it has a little problem ... sometimes, after releasing the TrackPoint, it continues to think that the user is moving it and the mouse cursor wanders. But after a time it notices that it is doing wrong and it stops.
There are two power management systems, the older and simpler
APM and the more modern and complex ACPI. APM is quite good
supported, and ACPI is still in an experimental state under
Linux. While booting, my kernel has a deep
insight: IBM machine detected. Enabling interrupts during APM calls.
This probably means that APM interrupts cause other interrupts to
be rised which must be processed. This is a kernel
option in APM.
Since you only can use one power management system at the time, I chose the stable APM and left the experimental ACPI alone. Tests with ACPI showed that it is good for making the machine crash in serveral beautiful ways, but it really doesn't work yet (with kernel 2.4.19 or 2.5.31). New ACPI versions cause the system to hang on boot time. I think it's a combination of bugs in Linux ACPI support and IBM's ACPI BIOS.
I got a mail about patching the ACPI BIOS. I didn't try it yet. The author of this page reports that patching the BIOS will resolve most ACPI problems. There still persists a problem that the network adapter (using the eepro100 driver, see below) doesn't wake up after a suspend. People, be aware that you can destroy your R31 if you play with your BIOS!
One further note for people wanting to play with ACPI: Certain kernel versions (new ones) get stuck when starting with ACPI activated. I was pointed to the problem that there's a conflict in IRQ assignment, and using this kernel modification will help. Using the Intel e100 driver instead of the kernel's built-in eepro100 driver was reported to fix the network adapter wakeup problem, try it yourself! The background light of the TFT display still is lit in ACPI sleep, but it gets automatically turned off when closing the lid.
If you made experiences with these modifications, you're welcome to share them with me! I'm still using APM.
The APM thing works - almost.
Broken BIOS: The TrackPoint works well, but from time to time it jumps to the upper right edge of the screen and has some random mouse button hits. Even the ESCAPE key on the keyboard seems to be triggered by this problem. Under Windows there was never such a problem, but I can't tell you for sure because I never used it for a longer period. I've been told in newsgroups that this problem stems from the buggy APM BIOS. The BIOS has problems when querying the battery status. You can verify this problem by starting this in the shell (bash):
while true; do cat /proc/apm; done
Without battery everything will be fine, but as soon as the battery is inserted the cursor and keyboard begin to go mad.
From my point of view, you've got five options:
apm=no -
not a good choice in my opinion.
i8042.nomux=1 in the kernel command line.
This unfortunately doesn't solve all problems.
apm=broken_psr (which means something like
BIOS has broken PowerStatus call).
You don't have to live without battery status ... there's
still the little LED that will shine amber if the system
is running out of battery energy and needs a recharge
(the computer will auto-suspend if he enters the
low battery state with apm activated, even if apm=broken_psr
was set).
This is the solution I prefer.
But why does it work under Windows?? I expect Windows to use ACPI, not the older APM standard.
Ignoring the above problems, with activated APM (without battery status stuff)
I can make the computer suspend by closing the
screen panel, by hitting Fn F4, and by entering
apm -s at the command line. Suspend means that
the computer remembers its
state in RAM, and simply switches most of its circuits off
(hard disk, display, cpu, ...).
After hitting Fn or opening the screen panel,
the computer starts from the state where it slept away.
A computer can sleep multiple days like that when on battery - the only
thing consuming battery power is the main memory and some
motherboard circuits.
The ThinkLight, Ethernet card and the fan still
run in suspended mode, but I think this can be seen as a
feature.
The fan is temperature controlled and it switches off
if the temperature has fallen.
The ethernet card
has to stay online for wake-on-LAN. And the ThinkLight ... it has
to stay on for you to find your ThinkPad in the dark again!
When the machine is running low on battery, it automatically
suspends itself. You won't end up with a crashed
hard disk ;).
The LED for a fixed power connection
seems to be lit even if operating on battery. Also
the APM system (in /proc/apm) thinks
the machine is connected to the
power line. Will running out of battery make the system
crash down in this situation? No. The system will
auto-suspend if it is running low on battery.
There's also an APM thing called hibernation (really APM?).
This is even more power saving than suspend because the
memory contents are dumped to disk, and there's no
need to supply memory with power. In fact, the computer
can be turned completely off, and then retrieve its
state from this disk file afterwards. This is what
the so-called swsusp kernel module does.
I'm using it and it works quite well.
To start hibernation, simply issue the command
echo "disk" > /sys/power/state as root.
If a suspended machine can stay suspended for days, a hibernating machine can stay hibernated for years (some day the magnetic state of your hard disk will get changed by earth/cosmic radiation, the earth magnetic field, etc. ;).
You can turn the screen off (and let the computer
running) by pushing a keyboard shortcut (Fn F3).
I also noticed that APM or X managed to turn
off the display after a while of inactivity!
Turning the screen off and on using the keyboard shortcut
resulted in a frozen mouse and keyboard which could
be unfrozen by closing and reopening the
display panel (suspend and wakeup). Not a nice solution,
but also not a pain since suspend works and the
display gets blanked automatically.
The display intensity can be controlled by a Fn
combination also, but the lowest intensity is still
very intense in my opinion.
The kernel APM kernel (my kernel: 2.4.19) options (general setup category) I used are as follows:
<*> Advanced Power Management BIOS support [ ] Ignore USER SUSPEND [*] Enable PM at boot time [*] Make CPU Idle calls when idle [ ] RTC stores time in GMTg using APM [*] Allow interrupts during APM BIOS calls [ ] Use real mode APM BIOS call to power off
In my point of view the option Make CPU Idle calls when idle really keeps the system cooler, so it is a good idea to set it. Another important option is Allow interrupts during APM BIOS calls as I said somewhere before, IBM ThinkPads like to call/rise other interrupts from BIOS calls.
There's also a nice little white LED attached to the
upper edge of the display that is called
ThinkLightTM. The light is thought to
support illuminating the keyboard if you're in a
dark room, or even somewhere outside in a dark park
(better watch out for ThinkPad thieves!).
It can be toggled on and
off by pressing Fn PageUP.
A thing that is missing in APM is SpeedStepTM.
SpeedStep is an IntelTM technology that switches
between two processor frequencies without resetting
the processor core (it has to temporarily fall into a sleep state, though).
One frequency is power intensive
and fast, and one that is power conservative and a little slower.
SpeedStep is a technology supported by the motherboard,
operating system and CPU. According to Intel's web sites
all CPUs start in power saving mode, but since my
/proc/cpuinfo reports 1133 MHz i believe the
BIOS switches to full speed.
I read somewhere that SpeedStep is an issue of ACPI (which is not finished yet in Linux).
There's a kernel patch called Linux CPUFreq which doesn't work currently for the Celeron Processor (22 Oct 2002).
There's a package out there called lmsensors that can be used to read the temperature and fan rotation sensors on the motherboard. I use it on my desktop and like it.
Better don't use it on your ThinkPad! I've seen reports about people who used the auto detection routine of lmsensors and ended up with a corrupted BIOS! The people didn't use R31 series ThinkPads, but I think it is still possible.
The most important thing about a notebook is its battery. For many notebooks this is also the most valuable spare part. The longer the battery lasts, the more you can work without the need for a power plug.
The duration of battery work depends on many factors. First of all, the components of the system make a big difference. There are some notebooks out there which have desktop CPU's. Desktop CPU's are much cheaper than notebook/mobile CPU's, but they are real hogs in wasting battery power. If the CPU fan never stops in your system, you're likely to have a desktop CPU.
Another big power consumer is the display. AppleTM manuals remarked that it consumes 30% of the power in a notebook. I don't know if this estimation is still correct.
Now let's take a look at the R31. Without any efforts for saving power the battery only lasts 1.5 hours. This sucks! I only played NetHack in this time to ensure that the display doesn't turn off. You must see that an estimation of battery time is always unprecise. The average user will only run a text editor the whole time which doesn't require much of the computation power (and thus battery power) the notebook provides. AppleTM iBooksTM can run up to 5 hours with their batteries. Please don't think PCs are the best systems for all jobs - they aren't.
I also did an estimation of the battery time with noflushd running. For a little discussion of noflushd, take a look at the IDE section. The effect of noflushd is really amazing. The machine ran for 2.5 hours. In my opinion the system had a little more work in the first test than in this test.
Conclusion: Don't go out for too long.
Worked fine with the Xircom RM56G modem. Plug and play the way I mean it!
Works. There are some minor changes necessary
to the
nsc-ircc kernel driver.
After that, you have to activate IrDA in the BIOS and assign it to
an ioport address, for example io=0x03f8 irq=4 dma=3.
Proceed with declaring the io parameters in your /etc/modules.conf
file by adding lines (matching your BIOS IrDA parameters) like
options nsc-ircc irq=4 dma=3 io=0x03f8 dongle_id=0x09 alias irda0 nsc-ircc pre-install nsc-ircc modprobe irda
Then your IrDA stuff (in this case the communications port) can be started with this sequence
setserial /dev/ttyS0 uart none port 0 irq 0 modprobe nsc-ircc modprobe ircomm modprobe ircomm-tty irattach irda0 -s 1
Note that the setserial command is necessary
because at startup the kernel thinks that your IrDA device
is a dumb serial port. It then assigns your precious IrDA
io-port to the serial driver, and the nsc-ircc driver
can't access it. By issuing the setserial command above
the assignment gets removed and the io-port is free again
for the nsc-ircc driver. The ttySX device can change
as you modify the io-port of your IrDA in the BIOS.
The communication was successful in combination with minicom and /dev/ircomm0 as well as with the tool for Nokia handies gnokii.
Tim Sutton reported to me that he has USB running on Debian Woody, and it works great.
Here you'll find a list of useful things related to Linux and the Thinkpad and/or other notebooks. The author of this page can't be held liable for external content. Please report any non-working links to the author of this page.