Linux on Thinkpad T41

Ian Hutchinson

Abstract

Linux Fedora Core 1 works well with the IBM Thinkpad T41. The built-in Centrino wireless hardware can be made to work with windows drivers using ndiswrapper, but XFree86 crashes periodically under load after a suspend resume, therefore a replacement such as the Xi Graphics Summit X-server is needed. The Fedora scripts are poorly designed for roaming wireless connection. Some improvements are provided.

1 Machine Hardware
2 Things to consider BEFORE first boot-up
    2.1 IBM factory defaults area
    2.2 File system type conversion
3 How not to repartition
    3.1 Knoppix boots like a charm
    3.2 Parted can't do anything with the Windows partition
    3.3 Knoppix hangs the machine on shutdown
    3.4 Windows boots ... and converts the file system
    3.5 Factory Defaults does not save the partition size.
4 A successful repartitioning
5 Mandrake 9.2 Working but Crashing
    5.1 Suspend
    5.2 Hibernate
    5.3 Hibernate Update 5 Dec 2005. Memory upgrade requires FAT32.
    5.4 Crashes when left for a long time
6 Fedora Core 1
    6.1 Linuxant Wireless Driver Loader for Fedora
    6.2 Ndiswrapper v0.7. Update 2 May 2004
    6.3 Fedora Network Scripts Broken
    6.4 Mouse 3rd Button
    6.5 USB Works out of the box
    6.6 IRDA: only SIR works with Fedora 1 stock kernel
    6.7 IR remote control with lirc. 19 Apr 2004
        6.7.1 Automatic module loading etc.
    6.8 USB Wireless Keyspan Presentation Remote; 18 July 2004
    6.9 Modem not interesting to me
    6.10 CDRW/DVD
    6.11 Sound works out of the box
    6.12 Speed-Stepping works with cpufreqd
    6.13 Disk Spin-down Settings
7 Summary
A Unstable XFree86 after suspend

1 Machine Hardware

My new thinkpad is a T41 2378DHU. Having

1.4GHz Intel Centrino CPU (Pentium M)
40GB Hard disk (but you only get less than 35GB useful)
256 Mb memory
Radeon 7500 display 1024x768
CD-RW/DVD combined.
Ethernet Intel e1000
Wireless Intel Pro 2100 built-in
2 USB ports
IRDA

2 Things to consider BEFORE first boot-up

Naturally, since I was forced to accept and pay for Windows XP professional operating system, I wanted to retain that OS for occasional use. I mostly use it for testing software that is intended for folks bound to windows.

There are several very helpful pages concerning linux installation on recent thinkpads. For the initial steps I used mostly Klaus Weidner's information http://www.w-m-p.com/linux-on-t40.html.

2.1 IBM factory defaults area

Since I was starting with a virgin machine. I could afford to be quite cavalier and try a few different possibilities. My objective was to shrink the windows partition to take up no more than 1/3 of the disk, and then to install linux on the rest.

Actually, not entirely the rest, because at the end of the disk is the factory default reinstallation area which one definitely wants to retain if windows is of any interest. On my disk the windows partition started as cylinders 1-4713 of the 5168 cylinders total that my disk had. Those "free" cylinders (3359MB) are the factory defaults area. Not to be interfered with at any cost.

2.2 File system type conversion

Another important issue is that the first time windows boots it converts the filesystem from FAT32 to NTFS. Information that Weidner had gleaned said that this could be prevented by making a certain windows file inaccessible. So I did not immediately boot to windows. Instead, I went into the setup (via the Access IBM) key during initiation, and disabled the hard disk as a boot device, enabled the cdrom, and made it before the hard disk so that I could later boot the hard disk.

3 How not to repartition

If you just want to hear about successes, skip to the first paragraph of section 4. If you only want to hear about the Fedora install, skip to section 6. If you want more information about things that (contrary to web information) don't work, read on.

3.1 Knoppix boots like a charm

Then I put Knoppix 3.3 in the cdrom drive and let the boot continue. Knoppix booted amazingly well, and I was up and running a linux distribution in 5 minutes. Wow! Knoppix autodetected sound, video, network, and everything you might want for setup. You become root in Knoppix by going su with no password. That seems horribly insecure if you are on the network, but anyway. I mounted the /dev/hda1 windows system (still FAT32 at this stage), and carried out the surgery that was said to stop the file system conversion

mv /mnt/hda1/windows/system32/convert.exe \
 /mnt/hda1/windows/system32/convert_.ex_

I also, set out straight away to resize the windows partition. Here was my first problem.

3.2 Parted can't do anything with the Windows partition

Knoppix 3.3 does not come with the command line parted, it comes with nparted, which runs and qtparted, which did not run for me. Unfortunately, nparted seemed to be unable to do anything with the windows partition, giving error messages about partition alignment. So right at the first, I was stymied. Thinking this was perhaps a bug in the latest parted, as was implied by some messages I googled up, I tried to install an older version of the command-line parted. That failed because the needed libuuid is not on the knoppix system and you can't just install new files into the system because it is a CD of course.

I could not figure out how to use fips, since I don't have a floppy disk. Well I thought maybe the problem is that I haven't run windows yet so it is in some strange startup state that parted can't manage. So I decided to let windows boot.

3.3 Knoppix hangs the machine on shutdown

Knoppix has the sorts of facilities one might expect. It shuts down from the keyboard or from the start menu. However, as it does so, it reaches the end of its activities and ejects the disk, telling you to remove it, shut the CD drive and hit return. You do that and the screen goes blank, but the inverted Z icon on the thinkpad next to the hard disk light remains on. And the computer then responds to no buttons except the CD open or close. The CD light itself remains on, and you can't restart by hitting the on-off button. The only way to restart I found was to take the power cord out and remove the battery. That's annoying. [Days later I found out that if you hold the power key for more than 4 seconds, this forces a power-off. This is the right way to do it, but I wish I had known earlier.]

Another problem with knoppix is that if left alone for a while it does something that seems to crash it. I don't know what it is, but it thrashes the CD drive for a while and then eventually freezes. So while I give knoppix top marks for a totally trouble-free boot, it still has significant problems with this laptop.

3.4 Windows boots ... and converts the file system

So what does windows do the first thing on boot-up? It converts the file system to NTFS. So much for the surgery that was supposed to stop it. Someone has that advice wrong. And now I have a NTFS file system filling my useful disk. I think Theodore T'so http://thunk.org/tytso/linux/t40.html is one of the original sources of that surgery on convert.exe

Since windows was up, I fiddled with it for half an hour confirming that simple things like networks etc were really working. Seems quite nice. I've never substantially used XP.

Back to knoppix anyway to try to shrink the NTFS partition. Knoppix has ntfsresize. You can run it with the -n switch to see what it will do.

ntfsresize -n -s 9G /dev/hda1

Unfortunately it reported that the end of my filesystem was fragmented, and had files there. So back to windows (pull out the battery) and run the defragmenter. It tells me the file system is not fragmented, but I defragment anyway. It takes probably ten minutes and its graphical display shows that it leaves files in the middle of the disk, who knows why?

Back to knoppix, use ntfsresize. It tells that we can shrink the ntfs down to 17GB. So do it, and follow with the fdisk repartitioning (which is the dangerous part). Finally, we have some space on the disk, but only half of it, for linux.

I thought maybe if one went through the same process again, one might be able to halve the size of the NTFS again, which would be enough. But no. The windows defragmenter leaves trash at the end of the file system when run on the 17GB size system. Bottom line is that I can at maximum get only half my disk available for linux. That does not satisfy my requirement.

3.5 Factory Defaults does not save the partition size.

I had read somewhere on the web that if you make a smaller FAT32 file system and then run the factory defaults reinstall, that it respects that size and you get what you want. So I made a 9GB FAT32 partition having removed my NTFS partition entirely, so I just had this one partition on the disk. Then ran the install factory defaults from the access ibm BIOS section. It took 55 minutes to complete, but without needing any intervention.

Disappointment: the disk was back to having a FAT32 system filling all the available area. The advice on the web was wrong (again). I was back to square one. With just what I started with (plus a little extra knowledge). Perhaps if one had made a linux partition filling the area that the factory defaults was forbidden to use, it would have worked. But I did not fancy another hour of waiting for the reinstall program to finish.

4 A successful repartitioning

Boot Mandrake Linux 9.2 install disk. Click through till you get to repartitioning. Choose custom. One sees that this partitioner is smart enough to stop at cylinder 4712 before the factory defaults area. Choose to resize the windows partition. Add some linux partitions with autoload in the rest of the disk. Then we have a suitable solution. Continue.

Presumably it would all have been just this easy if nparted had worked in the first place, but it didn't. Mandrake has its own repartitioning tool that seems to work.

One problem that I encountered was that I could not figure out a way to stop the install process. I wanted to because I wanted to boot windows and make sure I still had a viable system before I installed the rest of linux. Since I could not figure it out, I just crashed the install with the power switch. That hung the computer with the CD lights on like Knoppix. Time to pull the battery again.

On reboot, Windows started went into the middle of factory reinstall, rebooted itself 2 more times (I was worried by then), but eventually entered the filesystem conversion and windows first time sequence. I had a working windows XP in 9Gb, at last.

Thereafter Windows runs fine. (But has various applications such as troubleshooter in its system that periodically crash. Situation normal.)

5 Mandrake 9.2 Working but Crashing

The Mandrake install went essentially without a hitch.

5.1 Suspend

To get suspend working you need to edit /etc/sysconfig/suspend to say

Restart pcmcia="yes"
restore_sound="yes"

5.2 Hibernate

Since I had done this before, I knew what was needed.

Use or make the first FAT16 partition. (Done during Mandrake install. 500M size.)
Make the file system on it: mkdosfs /dev/hda2
Mount it: mount -t vfat ...
Get Andrew Tridgel's little program tphdisk from http://samba.anu.edu.au/junkcode/#tphdisk
Compile it. (Problematic on gcc 3.2 because of line ends in a long character constant. I cheated and did it on my old linux system.)
tphdisk 480 > /mnt/hda2/save2dsk
Reboot

Then it works e.g. from Fn-F12.

5.3 Hibernate Update 5 Dec 2004. Memory upgrade requires FAT32.

After using this machine for a year, I began to feel the need for more memory to bring back the snappy feeling. So I installed 512M in addition to the standard 256M. A reboot found all in order and 768M. However, when my machine automatically hibernated after 90 minutes in suspend, it hung. Of course! The hibernate file was too small for the new memory. No problem, thought I, go through the above again with larger file. Actually there is more to it than that, because I had first to shrink the Windows partition to make enough room. Fortunately ntfsresize worked flawlessly to do that. What a difference a year makes to linux tools! The best instructions I found for that were at http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html. Unfortunately however, simply repeating the above, but with a larger file size on the larger partition did not work. I simply got a low beep from Fn-F12, and the error message 0x91 "system is invalid" from tpctl -H. Tried lots of different things, including different partition types [e.g. Hidden Fat16 (16), Thinkpad hibernate (a0), Fat16 LBA, ...]. Finally, after much googling, I found in http://www.thinkwiki.org/APM_setup_on_a_type_2379_Thinkpad_T40 the comment that "I did have to use a FAT32 volume - using a file on a FAT16 volume is no longer an option with today's large RAM installations, since neither tphdisk nor IBM's utility could create working 512MB SAVE2DSK.BIN files in a FAT16 filesystem." So I tried a FAT32 (c) type partition and it worked! I believe that this observation explains a lot of oblique references on the web. The standard advice to use a FAT16 partition is WRONG. A FAT16 partition cannot support a hibernation file greater than (about) 512M. But a FAT32 partition can. Took a few hours to discover this! Well done thinkwiki. Those guys are on the ball.

5.4 Crashes when left for a long time

I got wireless networking going using the Linuxant driver loader (more later). But when left for periods of time more than an hour or so the machine would mysteriously crash. Completely hung and needing a power reboot. I never did figure out why. Because having fiddled with Mandrake for a while to see what it is like, I decided it was time to install Fedora Core 1.

6 Fedora Core 1

The Fedora core install went smoothly, like Mandrake. However, when finished, it was running X at 800x600, which is ugly on the 1024x768 screen. I had to go into /etc/X11/XFree86Config and add the line I needed for 1024x768 resolution.

Edited /etc/sysconfig/apmd to make pcmciarestart="yes" Then suspend and resume work (in X). By the way, many web pages I see talk about big problems with thinkpad linux suspension. I believe that this setting is the one that makes all the difference.

The NTFS filesystem is not supported in the Fedora stock kernel. So I can't mount the WinXP partition without a kernel compile. How clever is that?

Update 5 Apr 2004. Suspend resume leaves XFree86 unstable See below, section A for details of this subtle problem.

Update 7 Apr 2004. AcceleratedX (Xig Summit LX Server) Stable I downloaded Xig's commercial Xserver demo and found that it could be suspended and resumed without any instability. What is more it draws Xlib/Xt applications (i.e. 2D) approximately 3 times faster than XFree86, and 3D (e.g. glxgears) about 2 times faster. Its only obvious drawback is that it does not seem able to support simultaneous operation of trackpoint and touchpad through gpm. I was not convinced that that was a win anyway, so I am comfortable just turning off the touchpad in BIOS. At $129, the full-scale server is not cheap but I bought it anyway since I can't really afford any more time on XFree86.

Update 19 Apr 2004. How to use gpm repeater with Summit I now have the trackpoint and touchpad working simultaneously through the gpm repeater process for Summit X-server See update 6.4 below.

6.1 Linuxant Wireless Driver Loader for Fedora

Since the Centrino (Intell 2100) wireless built into the T41 is not directly supported by linux yet, the only option seems to be to use a clever loader that serves as an interface between linux and the Windows driver. There is an open source project called ndiswrapper, that I was not able to get going, although I admit I did not try very hard. After the first kernel oops, I lost interest. (Even the later 0.4 version does not work, although at least it doesn't crash the kernel.) There is a commercial product from a new company called Linuxant

I installed the linuxant driverloader evaluation copy, for Fedora Core, following their instructions. It works, but is a bit flaky. Basically the module quite easily gets into a state where it is giving error messages (which can be seen using dmesg) and can't seem to reset. The install process adds an alias to your /etc/modules.conf file: alias eth1 driverloader.

Another problem with Fedora setup for networking is that the tools are all intended for a static configuration, but when both the ethernet (e1000 works out of the box) and the wireless (driverloader) are modules, it is possible for either one to end up on either eth0 or eth1. That screws the graphical script setup. This problem does not seem to be easily fixable except by forcing the e1000 module to be permanently loaded. To do this for good, one can put the following line into /etc/rc.d/rc.local:

/sbin/insmod e1000

Then eth0 will always be the e1000 and eth1 the wireless.

One way or another, then, your configuration file, /etc/sysconfig/network-scripts/ifcfg-eth1, for the wireless should look like:

# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
ONBOOT=no
USERCTL=yes
PEERDNS=yes
GATEWAY=
TYPE=Wireless
DHCP_HOSTNAME=
IPADDR=
DEVICE=eth1
HWADDR=
BOOTPROTO=dhcp
DOMAIN=
NETMASK=
ESSID=
CHANNEL=1
MODE=Managed
#RATE=11Mb/s
KEY=1234567890

The rate command may not be supported, so I commented it out. You may well be on a wireless access point for which there is no WEP. If so, then KEY should be blank.

Provided one is starting with the driverloader module out. This configuration should just work. You ought to be able to just give the command /sbin/ifup eth1 (as root). However, if driverloader is in, then it may be hung, and nothing good will happen. If that is the case, you need to /sbin/ifdown eth1, and /sbin/modprobe -r driverloader. Then try again. One really needs a way to ensure that driverloader is always removed from the kernel every time eth1 is brought down. There is a clean way to do that. Create the file /sbin/ifdown-local containing

#!/bin/bash
modprobe -r driverloader

and make it executable. The ifdown script will execute it after everything else, every time for you.

This should be sufficient to make the system tolerably robust for wireless networking. If the wireless hangs, all you need to do is ifdown eth1 and ifup eth1 again. You should ensure that your /etc/sysconfig/apmd file configuration says

NET_RESTART=yes

which will cause the networking to be brought down and brought back up again when suspending or hibernating.

[Update 19 Apr 2004. Fedora's newest kernel 2174 and Driverloader. One advantage of driverloader is that it is easy to upgrade and the suppliers seem to be tracking Fedora kernel updates. The new kernel and module seem somewhat more stable than the earlier one. Unfortunately, however, when driverloader hangs, which it still does occasionally, attempting to remove the module crashes the entire kernel. Ugh!]

Driverloader 1.66. Update 25 Apr 2004 Since driverloader was still not robust I did some more experiments. Driverloader comes either as a generic source module you compile yourself or an rpm. I have found that the latest generic driverloader 1.66 appears to be improved with respect to the rpm distribution 1.65_k2.4.22_1.2174.nptl-1fdr. However, it is not perfect.

I tried out the source 1.66 driverloader version with a plain 2.4.26 linux kernel. It behaves AFAIK the same with the 2.4.26 as it does if I use the generic source 1.66 version with the 2.4.22-1.2174 kernel.

Both of them seem to show fewer of the errors that lead to hangs of of the wireless itself.

The driverloader module seems to be able to be modprobe and modprobe -r inserted and removed without crashing PROVIDED that the thinkpad is not suspended (using apm) while the driverloader module is installed. However, if the machine is suspended with the driverloader module installed, then any subsequent attempt to modprobe -r remove it, causes a kernel crash.

Therefore the driverloader module is still buggy, but at least now I can avoid the bugs by ensuring that the module is removed prior to each suspend. That is what I originally set up as described above, and in the next section.

6.2 Ndiswrapper v0.7. Update 2 May 2004

It looks as if at least as much work is going into Ndiswrapper, the open source code for using windows drivers, as into driverloader. The latest version has made significant strides. It now works with centrino! In fact it seems to work more robustly than driverloader in that it does not hang the kernel when a reset error occurs with the windows driver/hardware. The compilation and installation is remarkably smooth. But it does not quite work with the usual settings. It turns out that it uses "restricted" rather than "open" WEP by default; so the wireless password has to be specified as 1234567890 open with the extra directive. Another thing I noticed is that although the module loads automatically, it seems to respond best if the essid is set, then the other parameters, then the essid is set again. Otherwise it may not connect properly.

If the hang reset problem occurs (and it sometimes does). Then the whole machine becomes rather unresponsive. Perhaps interrupts are being only poorly served because of attempting something with the driver. To get out of that, you have to down the interface and remove the ndiswrapper module. As I mentioned above, that is handled automatically for me by /sbin/ifdown-local containing the line modprobe -r ndiswrapper. Since ndiswrapper is set up to be device wlan0, and driverloader to be eth1, I can use either of them. (But not at the same time as the other!)

I am currently using ndiswrapper routinely.

6.3 Fedora Network Scripts Broken

Since this is a laptop, I naturally need a variety of different settings for my network to connect in different places. Some places the wireless is open with no WEP, other places have other keys.

Obviously one would like to set this up so it is automatic, or at least simple. The redhat-network-config is the default way to set up the network. You can make many different virtual devices for a particular actual device (e.g. eth1, the wireless). These are referred to by "nicknames", and can be individually selected, and have different WEP keys for example. So far so good.

But now the problem is that the files that the gui writes in /etc/sysconfig/network-scripts are ifcfg-nickname, not ifcfg-device. That's confusing to anyone that knows how to bring up and down interfaces, by ifup eth1 etc. But worse than that, it totally confuses the system scripts. In particular, the apmscript that brings up and down the network on suspend/resume assumes that the configuration files have names like ifcfg-eth1 not ifcfg-afoolishnickname. If your configuration file is of the second type then doing ifdown or ifup eth1 won't work. As far as I can see this is just a major bug in the system scripts. I believe that the fault really is in the redhat-network-config approach. It ought to write its files into the sysconfig/network-scripts directory using the standard device names. The nicknames should be reserved for the places the gui stores its stuff. However, the gui is not a script so it can't easily be hacked. Therefore I hacked the apmscript to grep the ifcfg files for the devices that it is looking for and then call the ifup/down commands appropriately.

By the way, the apmscript doesn't ifdown the devices before suspend. They definitely should do, so I corrected that too. In summary, the Fedora apmscript is badly broken in respect of networking. The only safe thing you can do unless you correct it is to bring up and down the network connections by hand when suspending. Alternatively, here's the patch which seems to make things work.


--- apmscript.orig      2004-01-19 23:19:48.000000000 -0500
+++ apmscript   2004-01-23 19:31:54.000000000 -0500
@@ -108,7 +108,15 @@
                NETDEVICES=`LC_ALL=C /etc/init.d/network status | LC_ALL=C grep -A1 "Currently active devices" |tail -n1`
                if [ "$?" = "0" ]; then
                        for i in $NETDEVICES; do
-                               echo "/sbin/ifup $i" >>/var/run/apm-resume-post
+#                              echo "/sbin/ifup $i" >>/var/run/apm-resume-post
+#IHH patch to work properly with gui scripts. Not yet fully tested.
+                           IHT=`fgrep -l =$i /etc/sysconfig/network-scripts/ifcfg-*`
+                           NETIFCFG=${IHT##*/etc/sysconfig/network-scripts/}
+                           if [ $NETIFCFG. != . ]; then
+                               echo $NETIFCFG network service shutdown/restart
+                               /sbin/ifdown $NETIFCFG
+                               echo "/sbin/ifup $NETIFCFG" >>/var/run/apm-resume-post
+                           fi
                        done
                        echo "touch /var/lock/subsys/network" >>/var/run/apm-resume-post
                fi

This won't work fully if you suspend in one location and move to another. Because it will naturally try to bring up the wrong virtual device.

In my view Fedora needs to get serious about supporting wireless networking and use scripts that use iwconfig etc to figure out automatically what access point they are on and find the corresponding key needed.

Update 3 Apr 2004. I have created a couple of scripts with a complete installation package that implements a far more rational way of handling the wireless network than the standard Fedora scripts. It makes minimal changes to the existing approach. Feel free to download it here.

6.4 Mouse 3rd Button

The thinkpad trackpoint mouse and the touchpad work simulaneously with the standard install. However, the middle mouse button does not work. There is a solution that is spelt out in detail at http://bellet.info/~bellet/laptop/t40.html#touchpad_support. It uses gpm with a powerful but patched version of the synaptics driver to recognize the buttons and pass commands on to X. The files that need to be modified are /etc/X11/XFree86Config (see the URL above), /etc/sysconfig/mouse to contain

MOUSETYPE="synps2 -R"

and /etc/sysconfig/gpm to contain

DEVICE="/dev/psaux"

Together these last two configurations make the built-in gpm command generated from /etc/init.d/gpm into gpm -m /dev/psaux -t synps2 -R.

To make the mouse recover from a suspend or hibernate, you need to add gpm to the restore services list in /etc/sysconfig/apdm:

RESTORESERVICES="named amd gpm"

Update 19 April 2004. Getting the mouse working with Summit X-server. Two improvements on the above are possible. The first is to route all mouse events through gpm, by using

MOUSETYPE="synps2 -Rimps2 -M -m /dev/input/mice -t imps2"

Several points: the -Rimps2 says to make the repeater an intellimouse ps/2 type. This is the only type that I can get to work with the Summit X-server, which is what was hard to discover. I got -Rms3 to work with XFree86. Then of course one has to tell the X-server setup the same thing. In /etc/Xaccel.ini, the configuration file for the XI Graphics Summit server, the first mouse section has to be

[MOUSE]
	Protocol = "msi.dcf";
	Device = "/dev/gpmdata";
	Mode = POINTER;

Of course this can be constructed using the Xsetup utility. This device, gpmdata, is where gpm puts out the mouse signals it is repeating. The mousetype section that starts -M says that multiple inputs should be managed, the first of which is from /dev/input/mice of type imps2.

6.5 USB Works out of the box

Plugging stuff into the USB port generally leads to its becoming a scsi disk equivalent, e.g. sda1, or sdb1. You can tell which it is by looking at dmesg. I seem to have to mount the device by hand. But I am comfortable with that.

6.6 IRDA: only SIR works with Fedora 1 stock kernel

The infrared, which I use for syncing my Palm, seems to be the same as the old one that I had on my T20, and which I had working with both fast and slow (FIR and SIR) drivers. My confidence was probably my downfall - and the reason it took me ages to sort this out. My conclusion is that with the stock Fedora kernel, which has serial drivers built in, you can't use the FIR driver (nsc-ircc). I believe this is because the port gets grabbed at startup by the serial driver and a subsequent setserial /dev/ttyS1 uart none is insufficient to free it up. Instead

Make sure in your BIOS setup that the IR port is enabled.
Add nothing to your modules.conf file.
Do /usr/sbin/irattach /dev/ttyS1
You should be in business. Try pilot-xfer -p /dev/ircomm0 -l and hit the hotsync button on your palm.

To execute the irattach command at startup automatically, add irda to the startup scripts using System Settings > Server Settings > Services. And ensure that the file /etc/sysconfig/irda contains the commands

DEVICE=/dev/ttyS1
ENABLE=yes

Incidentally I played with the FIR so long, when it all seemed to be ok but it could not see the palm, that I began to think that the hardware was broken. One can test it in Windows by hitting the palm hotsync button and holding it up to the IR port. Then in windows the IR device button pops up to say that there is a device out there somewhere. That convinced me the hardware was working!

6.7 IR remote control with lirc. 19 Apr 2004

I use my laptop for electronic presentations - NOT Powerpoint, of course - typically I use acroread with PDF files I make using TeX. They are just as good as (actually in many ways better than) Powerpoint, for almost everything except embedded animations and movies. Anyway, I occasionally wish I had a way to control the laptop remotely. This can be desirable when the room configuration does not provide a long enough cable to put your laptop at the front where you are, and the LCD projector further back to give decent sized screen image.

Well my laptop has IR built in, right? So can one use it? Answer yes, using the package LIRC which stands for Linux Infra Red Control. Downloading the distribution, I made and installed it without problems, once I had copied a kernel configuration file to .config in /usr/src/linux/. The lirc_sir module is the one I want (since my serial is built into the kernel). To get it to load, all the irda stuff (irattach, irtty, irda) that I use for my palm pilot first has to be removed, and then setserial /dev/ttyS1 uart none should allow the module to load. I had considerable trouble getting proper operation at first. I don't know what the problem was, but the test program mode2 was giving values occasionally that had overflowed negative. Although I hacked around in the LIRC code for a while, I don't think that was what fixed it in the end. But my problem was initially that I did not even recognize that the strange values were incorrect. Anyway, once the hardware and kernel modules were working ok, I successfully configured the system to recognize my remote, using the irrecord program that is distributed with LIRC. Impressive. I am using a $14 universal (TV VCR DVD CBL RCVR) remote Sony RM-V302, but the software seems capable of recognizing pretty much anything.

So now I can program my system using the (supplied) irxevent code to send X-events to acroread. The critical ones are page up, page down, and Ctrl-L (toggle full-screen), which I attach to my CH+, CH-, and DISPLAY buttons. The range is decent, probably 3 to 4 meters. But you have to have a direct line of sight to the IR port on the front of the machine, so it is not quite so facile as an RF USB mouse in that respect. It is more facile for acroread, than just using a mouse, though. That is because AFAIK there is no way to program a mouse button for page up in acroread. You can have advance on every click, but that does not let you go backwards or forwards. LIRC's irxevent does.

The LIRC package comes with a daemon to emulate a mouse. When in place it grabs incoming keys from /def/lirc which is where the main lircd puts them after it has interpreted the codes. The lircmd puts out mouse signals at /dev/lircm. Both of these pipes have to have their permissions set to read and write chmod 666 /dev/lirc[m]. Also there's a configuration file for lircmd that needs to contain PROTOCOL IMPS/2. That determines the protocol that lircmd emulates on its pipe. It is the only protocol that I find the Summit X-server to be able to read from these pipes. Then you make an additional mouse input configuration file for Summit, to use the intellimouse ps/2 protocol:

[MOUSE]
	Protocol = "msi.dcf";
	Device = "/dev/lircm";
	Mode = POINTER;

This is in addition to the gpm mouse setup given in 6.4. Then the server will accept events from either the mouse or the IR.

6.7.1 Automatic module loading etc.

Since irda and lirc have to share the IR hardware, I want them to play nicely together. My approach is to add to the /etc/modules.conf file the following

alias char-major-61 lirc_sir
# The following help to make irda and lirc share the ir properly.
# irda is started via irattach. Mods to /etc/sysconfig/irda were needed.
# Also an explicit kill of irattach was needed, for some reason.
pre-install lirc_sir /usr/bin/killall irattach ; /etc/init.d/irda stop; \
 /sbin/modprobe -r irtty ; /bin/setserial /dev/ttyS1 uart none
post-install lirc_sir /usr/local/sbin/lircd ; /usr/local/sbin/lircmd
pre-install irtty killall lircd ; /sbin/modprobe -r lirc_sir ; \
 /bin/setserial /dev/ttyS1 uart 16550A

The effect of these is to make lirc_sir load when the device is accessed (e.g. by one of the programs mentioned above). Before it loads, all the irda stuff is appropriately removed. Afterwards, the daemons are started. Conversely, if the irtty module is called for, which it is for irattach, then the lirc stuff is killed and removed before irtty is loaded. The setserial commands are also important. I added the following section to the end of /etc/sysconfig/irda:

case "$1" in
  start|restart|reload)
# Shut down lirc daemons.
        killall lircd
# unload the lirc module
        /sbin/modprobe -r lirc_sir
        /bin/setserial $DEVICE uart 16550A
        ;;
  *)
esac

This seems to duplicate some of the stuff above, but gives some additional safety in the principle that we always remove the competing modules before loading the ones we are after. The need for this second section seems to arise because of the way that irattach is used to start up irtty etc.

6.8 USB Wireless Keyspan Presentation Remote; 18 July 2004

The problem with the IR remote control is range and the need for line-of-site. It simply can't be made foolproof enough for the flawless performance one really needs for a good presentation. There's nothing that ruins a presentation easier than technical glitches.

So I got an RF remote, which comes in two parts, a USB plug-in that is about the size of a car key, and a control that fits in your hand. The model I got for $69 was by Keyspan, and works as a complete 2-button mouse, plus an up or down key on the side, and a built-in laser pointer. It claims to work up to 40 ft away from the receiver. I have not proved that.

I plugged it in with some trepidation, wondering if it would work with linux. But lo and behold, it works straight away with my gpm mouse setup without any adjustments: truly just plug and play. Great!

[There's also a "media control" mode that does not seem to do anything with linux and acroread. It is apparently supposed to be for the windows XP media player.]

6.9 Modem not interesting to me

I had the winmodem on my old T20 working. I hardly use a modem any more. I got the T41 internal modem going with the slmodem driver. It can be started by service slmodemd start. I verified that I can connect to it with minicom. But I haven't actually dialed with it.

6.10 CDRW/DVD

Did I mention that the CD worked from the start without a hitch? Well I also downloaded MPlayer and demonstrated playback of a DVD from it. CD writing is also fine. See for example http://www.newt.com/debian/thinkpad-t40p.

6.11 Sound works out of the box

Never messed with it. It just worked. Probably best to say yes to restart sound in /etc/sysconfig/apmd.

6.12 Speed-Stepping works with cpufreqd

There are a couple of modules with the Fedora Core installation to do with cpu frequency sensing and control. I don't know many details about this, but I installed the module speedstep-centrino. Then the info file /proc/cpufreq gives a sensible range of frequencies. It seems one just sets the minimum and maximum, but I don't know if the cpu manages to adjust itself between those two limits according to load.

Then it is nice if there is some kind of automatic control of the speed. I grabbed an RPM for Fedora for the program cpufreqd. It installed silently and then ran. After that, when I took the machine on and off ac power the min and max frequencies changed in /proc/cpufreq. Also, by running a cpu-intensive task, I could see the max freq take an uptick. Seems as if the automatic control is working. Its configuration file is using the apm interface which is already there.

The install automatically put cpufreqd into the rc.d scripts. So I just needed to ensure that the module is loaded. I did that in rc.local.

6.13 Disk Spin-down Settings

There is advice out there for tweaking the disk settings to make the disk spin down. The main thing is /sbin/hdparm -S 4 /dev/hda, which tells it to spin down after 4*5=20 seconds. But with standard setup you will almost certainly not see it spin down. That is not because of system settings, but because various daemons are accessing the disk, so it is never quiet. Therefore while the advice on the kernel and bdflush settings is fine, it is useless without fixing the daemons. Moreover, if you do nothing at all to the system apart from the hdparm -S command you will get good spin-down behaviour provided you stop those troublesome devils.

My troublemakers were autorun and cupsd, the printing daemon. If the light on your hard disk flashes regularly every second, then probably autorun is running. I don't know how to stop it accessing the hard disks, which are irrelevant for autorunning. Just doing as root

killall autorun

gets rid of it. But it will probably come back when you reboot or renter X unless you go into your .kde/Autostart directory and remove the autorun.desktop file.

The cupsd problem is actually not cupsd itself but the print monitor that is on your desktop panel. That is polling cupsd by default every 5 seconds, and cupsd is logging a message to its log files, saying that it was polled. Very silly. You can turn it off by going into the kde print manager by clicking on the panel button, and setting the refresh interval to "disabled". Of course, then you aren't automatically monitoring the print system.

Probably the above is KDE-specific. With Gnome, there are probably other issues. Other possible troublemakers are atd, which I get rid of from the services setup, and crond, which I don't because I want it to run.

7 Summary

Don't try to use Knoppix 3.3 to shrink the Windows partition. It won't. This problem was the biggest time consumer in the whole process. Knoppix crashes mysteriously when left alone.

Mandrake installer worked well to repartition and detect hardware. But it remained with mysterious crashes which I did not get round to fixing.

Fedora Core 1 installs fine but not quite as smoothly at Mandrake 9.2. However, it works very well and seems highly robust. Therefore it is my operating system of choice for now.

All the hardware is working under linux (except that I have not bothered to get the modem going but it is reported by T'so and elsewhere to work). Moreover, suspend, hibernate, resume and so on work without a glitch [except the subtly unstable X, see A].

The only extra commercial software I need is Linuxant's DriverLoader. The license is $20: one third of the cost of the carrying case I had to get. I paid it. However, it was also time consuming to figure out how to make their driver useful by forcing it to be removed after every ifdown. However, in view of the subtle instability of XFree86, I am actually using the Xi Graphics Summit X-server. It is faster and has TV out, but costs $129 for the full functionality.

IRDA works with the stock kernel only in SIR mode. This was the third most time consuming problem, probably because I was over-confident.

All in all, linux is ready for the Thinkpad T41, even though it contains all the latest hardware innovations. This shows that Open Source can just about keep up with the hardware, despite the woeful lack of delivered linux support for users from hardware vendors such as Intel and IBM. However, linux distributions are not idiot proof on this bleeding-edge hardware.

More information about linux on thinkpads and other laptops can be found at TuxMobil - Linux on laptops, PDAs and mobile phones.

A Unstable XFree86 after suspend

X (XFree86 4.3.0-55) crashes under load on my Thinkpad T41 (2378DHU) which has a Radeon mobility 7500 display (1024x768). But only after a suspend and resume. I am using a fully updated Fedora Core 1 stock kernel 2.4.22-1.2174.nptl, with APM. (It was present too on the earlier kernel and XFree86 versions from Fedora). Suspension and resume appear to work fine, but leave this instability.

The problem is subtle. Initially I just experienced a very occasional crash, which brought down the whole machine (as well as keyboard and mouse). Annoying. But I recently found certain graphics-intensive applications that would routinely crash the machine within a few minutes (but seemingly not always at exactly the same time). In some cases I have been able to ssh into the machine from the network and run top. It shows X using over 90% of the cycles. If X is forcibly killed (kill -9) the whole machine crashes and one needs the power switch. No crash has occurred unless the computer has been suspended and resumed. After a suspend resume (or hibernate resume) it happens within minutes for these (totally different) applications.

I have done extensive testing to prove that this is the core XFree86 code. It still occurs if all modules except type1 and truetype fonts are turned off in the XF86Config, proving that it is not the DRI, and glx etc, module extensions. I have removed all sorts of additional kernel modules from my system to eliminate their effect.

I have demonstrated that it does not happen if one restarts the X server (by ctrl-alt-backspace) after a suspend resume.

Moreover, I have demonstrated that it only happens in depth 24 display, I have never seen it in depth 16. (But why would I want always to run 16 depth on this display? Also it might just be that on the depth 16 display my tests just don't thrash the server hard enough.) I have also not been able to crash the system even in 24 depth when using the Option "NoAccel" "true" (suggested by Volker Braun).

I have furthermore discovered that the demo version of XIG's Summit AcceleratedX server does not crash. That might cause me to buy it in preference to XFree86, even though I don't seem to be able to get both the touchpad and the stick working simultaneously with AcceleratedX.

I have tested my memory with the memtest86 program, in case the problem was hardware. That test reveals no errors with my 256M IBM-supplied memory. I have moved the irqs around in the BIOS so that the video moves to a different irq. No difference.

QUESTION: has anyone got information on this bug, especially how it can be fixed? I have spent a lot of time on it, and I expect it is not unique to me, but I can't find any reports of this particular problem on the net.

Insights and experience would be greatly appreciated.

I am posting my log and config files, for the cognoscenti at http://silas.psfc.mit.edu/XFree86.0.log,

http://silas.psfc.mit.edu/XF86Config

File translated from T_EX by T_THgold, version 3.71.
On 27 Dec 2005, 21:21.