Howto use Debian GNU/Linux on a Thinkpad T42p

Last updated on 2019-03-24 10 min read

Howto use Debian GNU/Linux on a Thinkpad T42p

Many of the hints on this page have actually been collected from similar pages scattered over the web; the Thinkpad series of notebooks already has strong support for running Linux on them and a wealth of information is available. Thanks to all other web authors who provided their experiences that helped me in setting up my machine as it is now. However, a few bits and pieces in here are mine, so it might be helpful to others if I share them. Of course, good things are probably from others, but all blame goes to me for the things I have messed up.

With the following settings, I am able to use every piece of hardware that is in my trusted Thinkpad T42p under Debian/GNU Linux (testing/sid at the time of this writing). This includes wireless networks, OpenGL acceleration, DVI and VGA out, suspend-to-RAM, and even the on-board accelerometers (and of course all the standard stuff like LAN, WLAN, sound, special keys, CD/DVD burning etc. that can be expected to work out-of-the-box with most recent Linux distributions).

I ordered my T42p specifically with the “Thinkpad WLAN 802.11a/b/g” mini-PCI module because it is based on the Atheros WLAN chipset instead of the Intel IPW2100/2200 that is used in most Thinkpads. The advantage of this choice is that it not only supports 802.11a in addition to 802.11b/g, but that there are high-quality open source drivers called “madwifi”. They work a lot better than the Intel IPW drivers at the time of this writing and even support nifty features like a nice monitoring mode that does not disturb normal operation and a hostap (i.e. emulating an access point) mode.

A stock Debian 3.1 installation will already use most of the hardware out of the box and the first section shortly lists which drivers are necessary for these standard hardware components. ACPI will work as expected, although it might not be configured perfectly for a laptop (see the sections below for details on my ACPI configuration). There are only a few things which need to be configured especially, and I am trying to cover in more detail what I did for those. All of this certainly includes personal preference, so take with a grain of salt.

Standard stuff

Most of the components “just work” when being used with the correct driver. My current setup at the time of this writing uses a kernel 2.6.15 with only minor patches and this config. As you can see, my kernels are usually heavily modularized and optimized for their task; this one is intended for a desktop system, so I use the appropriate preemtible kernel options. These components did not need any special treatment for me:

  • audio: This is rather simple with ALSA, as the snd-intel8x0 module will work out of the box. With alsaconf, you can easily select the “intel8x0” option, which will create the file /etc/modprobe.d/sound. Since the Intel 810 chipset does not have built-in hardware mixing capabilities for playing multiple audio streams at once, I use the ALSA dmix plugin to allow multiple applications at the same time. Setting it up as the default for all applications using ALSA directly is not too difficult, and a lot of examples can be found on the net on how to do it. A I use Skype, I needed duplex capabilities (i.e. also allowing multiple applications to access to microphone). My /etc/asound.conf file works for the T42p in duplex mode. Please note that the onboard audio chipset uses a sample rate of 44100Hz, and not 48000Hz as many examples for using the dmix plugin suggest. By setting the dmix plugin to 48000Hz, I assume that ALSA-capable applications will just be resampled (thus loosing quality and causing CPU overhead), but OSS applications didn’t work at all for me. Just set it to 44100Hz and everything works.

    It is also possible to use OSS-only applications (like Skype) with dmix, but - at least for me - it turned out to be astonishingly tricky. The reason was that the kernel-level OSS emulation does not support using dmix! Instead, the applications need to be started with the aoss wrapper shipped in the alsa-oss Debian package, e.g. with “aoss skype”. Once that is done, it simply works.

  • USB: Both the USB 1.1 and the 2.0 modes work out of the box with the uhci_hcd and ehci_hcd modules. Just load them and use USB, most probably with a combination of udev and hotplug. For a small howto about using USB mass storage devices, look here.

  • Bluetooth: The internal Bluetooth dongle is attached to USB and implements the HCI standard, so it can be used with the standard hci_usb module available in all sufficiently recent standard kernels. For reference, here is my /etc/bluetooth/hcid.conf file, which uses the kbluepin helper from the kdebluetooth package for entering PINs and defines a device class that should be accepted my most Bluetooth headsets, so that I can use such a headset e.g. with Skype.

  • IrDA: I do not really use IrDA, but since it’s a piece of hardware that is available, it should also be configured properly (in case sometime, somebody wants to beam me a vcard via infrared, e.g.). The IrDA hardware is supported by the nsc-ircc module when used with the parameter dongle_id=9. Additionally, the port /dev/ttyS1 needs to be set up without uart. There are two ways to do that: either configure the setserial package manually (dpkg-reconfigure setserial, set to “autoconfigure once”, cp /var/lib/setserial/autoserial.conf /etc/serial.conf, dpkg-reconfigure setserial, set to “manual”, change /etc/serial.conf), or execute the setserial command when the module is loaded. I chose to use the latter option, because then it will work independently of the startup order (i.e. also when the module is loaded before the setserial init script had been executed). I put the necessary options in /etc/modprobe.d/local. Don’t forget to run update-modules after changing files in /etc/modprobe.d/.

  • Touchpad: using the synaptics driver - see xorg.conf

  • LAN:

  • WLAN:

  • Modem:

  • PCMCIA:

  • DVD multi format burner:

  • hard disk: hdparm for better speed

  • second HDD in ultrabay:

  • primary and secondary battery:

  • port extender:

  • battery: tp_smapi

Video

Getting X-Windows running smoothly on the machine certainly took most of the time of setting it up. It is finally up to the level where I want it to be, as OpenGL acceleration is now working in a stable way. That is, I get over 1800 FPS with glxgears (it’s not a benchmark, but gives numbers…), can suspend-to-RAM, and use external devices like projectors. This is currently achieved with the ATI binary driver fglrx version 8.23.7. I would rather like to use the open source driver radeon, but it doesn’t reliable support OpenGL acceleration for me, at least at the moment. If that support improves, I will try to switch, but for the time being I am quite happy with my current setup (which I just got working on 2006-03-27).

If you don’t need OpenGL, then the radeon driver shipped with recent X.org packages works very well. As I found out by (a lot of) trial and error, the most stable combination for my T42p is to use the xserver-xorg package 6.8.2 with all other necessary xorg packages of version 6.9.0. The reason why I keep the xerver-xorg package itself at 6.8.2 is because the 6.9.0 comes with an updated radeon/r300 driver that includes experimental support for OpenGL acceleration and manages to hard-lock my machine irregularly. With the 6.8.2 version, I never get any lockups. Another option might be not to install the xlibmesa-dri package, which installs the actual r300 DRM driver that I suspect to be the culprit.

If, however, OpenGL is needed/wanted, then it’s tricky to get the fglrx driver to work. Starting from driver version 8.22, the previous problems with resume from suspend-to-RAM modes were finally fixed, so that suspend-to-RAM can now suspend (and indeed wake up) the machine when fglrx is loaded and active. This driver update was the reason that brought me back to giving it another try after having used the radeon driver with great success for over 6 months. Since a few weeks, the driver is available in Debian sid/unstable (the non-free section of course) in form of the fglrx-driver and fglrx-kernel-src packages. The former installs the X.org driver (my xserver-xorg package is now at version 6.9.0.dfsg.1-4), the latter version allows to semi-automatically compile kernel modules (my kernel at the time of this writing is a slightly patched 2.6.15.6) using the make-kpkg command. See below for the compiled kernel packages I use. However, with the new 8.23.7 driver (and even quite a couple of versions before that), there is a documented bug that can lead to a hard-lock of the machine upon logout. Of course, this bug was triggered on my machine, starting a long debugging session. There are a few things mentioned on the debugging page, none of which helped in my case: to load the chipset-specific AGP driver before the fglrx module (for the T42p, this is the intel_agp module), to compile it into the kernel instead of as a module, to use the ATI driver installer to overwrite the packaged driver files, and to set “TerminateServer=true” in kdmrc (here is my file as an example). Only the latter helper for me, although after fixing the initial hard-lock problem. Setting this KDM option makes login work again after logout, but the hard-lock can also occur without KDM or GDM, simply by starting an X session from the command line and killing it with Ctrl-Alt-Backspace. For me, the culprit was the radeonfb framebuffer module. fglrx seems to hard-lock the machine upon termination of the X server when this framebuffer module is loaded. I had this module compile into the kernel to get a nice, high-resolution and fast Linux console. Either disabling it completely or compiling it as a module and not loading it (as I am doing in my kernel config) solves the hard-lock problem. It should be noted that I am using the vesafb framebuffer module successfully to still get a high-resolution Linux console, albeit a lot slower - see again my kernel config and my grub menu.lst for details.

For both variants, i.e. with either fglrx or radeon, it is advisable to set the “pci=noacpi acpi_sleep=s3_bios” kernel boot options to make suspend-to-RAM work.

My xorg.conf defines different setups for the different ways in which I use it:

Setup 1: Internal display + independent external VGA monitor/projector via VGA

Setup 2: Internal display + cloned to external TFT display via DVI

Setup 3: Internal display + Xinerama external TFT display via VGA

The above xorg.conf file also includes configuration blocks for both the fglrx and the radeon driver, and some comments on which options need to be enabled/disabled. I regularly switch between the two drivers whenever I gave fglrx another try, so both variants should work similar and pretty much out of the box.

ACPI

Using the ACPI events correctly makes it much more enjoyable to use the machine.

Suspend-to-RAM

Semi-automatic network roaming

Miscellaneous

Bluetooth headset

Accelerometers

Hard disk encryption

Files

Here is only a short list of the most important config files and packages that I use (at the time of this writing, that is). It might not be complete, please see the above sections for details, they might list additional config files that are not in this short list here. Warning: these files are commented, but the comments might not be accurate or grammatically correct. Use with care ;-)

Linux Debian Laptop Hardware
René Mayrhofer
René Mayrhofer
Professor of Networks and Security & Director of Engineering at Android Platform Security; pacifist, privacy fan, recovering hypocrite; generally here to question and learn