The Setup
ThinkPad T41p
|
|
|
||||||||||||||||||||||||||||||||||||||||
Debian GNU/Linux (3.1 "Sarge")
|
||||||||||||||||||||||||||||||||||||||||||
Table of Content
- Predesktop area
- DOS XP
- Linux
- Kernel
- OK: Sound
- OK: Network
- OK: PCMCIA
- OK: IrDA
- OK: BlueTooth
- OK: ACPI
- OK: ACPI - Advanced
- OK: HotSwap / UltraBay
- OK: SpeedStep
- Additional Compontents
- OK: TrackPoint Scrolling
- OK: XFree86
- OK: Connecting a Beamer
- OK: Wireless LAN
- OK: Switch LAN Interfaces
- OK: Modem
- OK: Backlight
- OK: ThinkPad Buttons
- Current Software Selection
- Not Working parts
- Reported Problems (& Solutions)
Installation
Predesktop Area
Nasty. IBM stores the recovery image for Windows XP there. Windows itself is dumb enough to believe the BIOS that the Harddisk is several GB smaller than it's actual size. Linux checks this itself and will tell you something like "The BIOS claims some hidden area. Enableing it...". So: if you want to preserve it take care that you do not touch it while paritioning with Linux fdisk.
DOS XP (aka: Windows XP "Professional")
Seems to work "as designed", whatever this means. Didn't play with it much.
There are some choices to get rid of it:
- fdisk in all it's flavours
- Some recent version of PartitionMagic to resize the windows parition to some minimum. Though PQMagic 7 seem to have corrupted my partition table so I came to the fallback above.
- Linux recovery CD aka "Dual Boot CD". My box came with SuSE 9.0 as alternative OS and the recovery CD for Linux is capable of dealing with the Windows parition ie. resizing it or removing it to recover a full SuSE 9 Professional.
The last method leaves the "Predesktop Area" untouched, so you are capable of "recovering" your windows from the harddisk. Note that Linux itself doesn't care about this area and will overwrite it! This happend to me though I tried to be carefull. Anyway I will not be able to recover from harddisk as far as I can see so I called IBM and asked about the "Rescue Disks" for Windows XP. Just in case I some day find some usefull thing to do with Windows. These 5 CDs came promptly the other day. That's what I'm used to from IBM.
Installing Linux
As I don't intend to run SuSE (though it came with the box and is some decent Linux distribution I never really liked it) I started to install Debian GNU/Linux.
For installation I used an XFS-Enabled Netinstall iso-Image from Blade This is based upon a Debian Stable but with built in XFS-support which I wanted to use as my primary file system later on. Baseinstall from this image went smooth and without any problem.
As Debian Stable (Woody r2 at the time of this writing) is actually quite old I choose to base my system on Debian Testing aka Sarge. Additionally I wanted to be able to add certain packages even from the unstable tree. This requires an appropriate sources.list for apt and a proper preferences file and the apt.conf in /etc/apt/. After the usual apt-get update, apt-get dist-upgrade cycle I had a very basic "Debian Testing" system. Note that I didn't install any software compontents so far but kept it at a minimum, so no tasksel or whatever, just the base. Additionally I needed to install modules-init-tools from testing as the next step is to get a 2.6.x-kernel up and running. Additionally you need the ncurses-dev-package if you want to use menuconfig. Don't think about using xconfig or whatever at this stage, there is no X yet.
Sarge became the new Debian Stable as of 06.05.2005 finally. For that reason I chose to convert my system from the "testing"-tree back into the calm backwaters of Debian Stable. The transition process went smoothly as expected, but it needed of course adoptions to the apt-setup:
- preferences with a pinned X11 (see later section about installing XFree86 4.4) to avoid the removal of the part done by hand.
- sources.list was updated to represent the Debian names of the releases. This list also contain Debian sources for the new testing tree (aka 'etch') and of course the unstable. Just in case something is needed to be pulled in from there in the future. Also some trustworthy 3rd party respositories are included and of course Debian Security.
- apt.conf represents the default usage of sarge.
After adopting the apt-setup it was just a
apt-get dist-upgrade
which worked like a charm :-)
Kernel
Reading through the net I found that some people where very fond of
"2.6.5 vanilla" so I got the kernel
image from kernel.org. Additionally I applied the
laptop mode patch though I didn't explore in detail yet what I had
won by this patch, but some people told me that I should include it.
The additional setup is mentioned below.
Note: If you use Kernel
2.6.6 (which was finished just at the moment of this writing) or
later versions the laptop mode patch is already included and you do
not need any additional kernel stuff. Though you need to set up the
scripts below.
Configuring the kernel took some time, and I'm pretty sure that my config is far from perfect. Additionally I tend to compile almost everything as module and nearly nothing into the kernel. Anyway, you can grep my .config for Kernel 2.6.5 if you want to.
Added support for serial devices e.g. for the ThinkPad Replicators/Dockingstations.
Added ISA-Support to build some FIR-modules. FIR doesn't work till now. As well as SIR.
Also note that you will need a populated kernel source tree to build WiFi-support later on. If you use make-kpkg it runs a make clean once the built is completed. To avoid this set
Note that you have to disable the local APIC in order to get the ACPI-things to work properly. Disableing the local APIC solved quite some problems I had with my first build. You may find this info on the net if you search long enough.
Note: To build a Debian compatible Kernel image, and as I myself can't remember how to call make-kpkg I wrote a short DEBIAN_KERNEL script to accompolish this. Adopt the revision tag first, and consider this script only as an inspiration what you might want to do. Do NOT use it if you do not know what you are doing. (Though it doesn't instal a kernel but builds only the .deb.)
/dev/sda1 /mnt/ms vfat noauto,user,sync 0 0
New in this release is also the DSDT-Handling. See ACPI - Advanced for this issue. My current .config. Note that the DSDT-Handling is not included here so it does not get confused if you have other paths.
Besids that there are some extensions to PCMCIA/CardBus as well and at least I got some PCMCIA-MemoryStick(tm) adaptor to work with this kernel which did not want to cooperate with the older 2.6.8.1.
NOTE 1: Due to some other box I sometimes throw an eye upon the above config also enables DRI-support for Intel-Chips and builds the appropriate modules. These chips are used in some of the lower end R-Series from IBM. The above kernel is reported to work well on some R51. I'll call this the "jj config". (Yes Jochen, you can just use it on your box...)
NOTE 2: At this point I also found that IBM's broken DSDT seems similar if not the same throughout some of their models. At least the mentioned R51 requires exactly the same fixes as my T41.
apt-get shfs-source shfs-utils
Note to adopt /etc/modules to autoload shfs.
Kernel 2.6.14 is finally released and gives an excuse to play again in kernel land, as it incoroprates quite some fixes. Additionally it is relevant for newer ThinkPads and pure Centrino machines as it incorporates the wireless modules found there. Upgrade went smooth using the config based upon earlier versions. For Speedsteping the new "on-demand-govenor" is available which would allow to drop cpufreqd but in some areas more control might be of advantage. Additionally ibm-acpi got quite some enhancements so it is worth a look.
Besides that it was reported swsusp seems to have reachted a stable state. To use it, it is required to add a kernel parameter first:
in case /dev/hda2 is a valid swap device. Using swsusp without this parameter specified at boot up (or the equivalent compile time option) will cause nasty effects on the file system.
At this point many thanks to sgi for xfs, its stability and its repair and recover tools. I can report this file system as it is implemented in 2.6.x as productive stable. Otherwise this update would have been postopned until an entire new install of the system. (Just to give you an impression on what happened actually to my root-fs.)
Documentation for swsusp is a bit poor but can be found in /usr/src/linux/Documentation/power. Essentially all that is required it to add the above stanza to your normal boot kernel. Upon startup it will write it's signature to the specified swap device and make it unusable for a kernel bootet without this option. Once you bootet your kernel with that parameter set you can just issue
echo disk > /sys/power/state
This will initiate the suspend to disk action. To resume just switch on the box again and select the kernel where you put the resume= parameter mentioned above.
Of interest is also the way how it is done. Normally /sys/power/disk is set to shutdown which stores the memory in the swap file and then tells the BIOS to just power down. From the docs this is the most reliable way to handle hiberantion. Also working is the "correct" way to handle hibernation aka ACPI's S4-state. To this end issue
echo platform > /sys/power/disk
This instructs the linux kernel not to ask for a powerdown but for entering ACPI S4. This could cause the blinking of some hibernation LED but IBM seems to have saved this light.
Another stanza that should be added to the grub-configuration is the noresume. Just for the same kernel image. It does nothing more than to remove the hibernation signature from the swap-partition again and make it usable by normal kernels. And it throws away the frozen state of Linux so you get a clean bootup. Note that also your recovery kernels should therefor add this parameter.
Having sayed this it works well here till now and it is added and bound to the usual key (Fn-F12) using ibm-acpi.
Another new feature that made it into Kernel 2.6.14 is the subsystem for IBM's Active Hard drive Protection System (hdaps). This system monitors the hard drive and is meant to park it's heads into a safe area once the notebook is droped or gets a shock otherwise. With the module hdaps there is finally a kernel module for handling this usefull device. Unfortunately there seems not to be much userspace applications as they would be required to really use it within the Linux environment, but the project is very busy so they are likely to show up shortly. At the moment the only application I found "usefull" is wmhdaps which is available from the projects sourceforge page. At the moment it shows the relative position of the notebook in a windowmaker dock.
Note: Use this config to get the hdaps built as a module together with the kernel. It is slightly different to yesterdays config which did not enable this feature. (It is burried down below and needs Hardware Sensors to be enabled which I disabled almost all cause of certain issues with ThinkPads in the past.)
Playing arround quite a bit with Kernel 2.6.14 revealed a strange bug within the battery module of ACPI, which seems to die suddenly for whatever reason and throwing a lot of errors into the logs. As I was not able to shutdown the system cleanly after such an event I reverted back to 2.6.10 for the time beeing. This problems occured only when the battery is in place and caused special trouble in case of wakeup from suspend to disk. In this context: suspend to disk works here reliable also with 2.6.10. Should have tried it earlier.
Built a new kernel Kernel 2.6.16.14. Using this config-2.6.16.14-vanilla.050506 solves the aforementioned battery problems and all seems fine now.
New kernel Kernel 2.6.18.1 with config-2.6.18.1-vanilla.141006 as there seemd to be some trouble with a recent cvs-version of madwifi. Now works fine with madwifi 0.9.2, all other features known to work so are up and running as well.
Sound
works by default with the above config which just enables alsa. debconf configures this perfectly, anyway here the contents of /etc/modutils/alsa in case you don't run debian:
### DEBCONF MAGIC # This file was automatically generated by alsa-base's debconf stuff alias char-major-116 snd alias char-major-14 soundcore options snd major=116 cards_limit=4 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss alias /dev/dsp* snd-pcm-oss alias snd-card-0 snd-intel8x0m alias snd-card-1 snd-intel8x0 alias snd-slot-0 snd-card-0 alias sound-slot-0 snd-slot-0 alias snd-slot-1 snd-card-1 alias sound-slot-1 snd-slot-1
After the last kernel update sound did not work anymore. To cure this problem it was enough though to remove /var/lib/alsa/asound.state stop the whole alsa subsystem by /etc/init.d/alsa unload and after that restarting it by modprobe snd-intel8x0.
Though I never experienced any problems with sound mixing as I used esd happily for years I found in other circumstances, that the Intel ICH4 chip built into this box does not support any hardware mixing and requires a software mixer to be set up. (Thanks to J. Jansen for pointing this out and never giving up on insisting that I should solve a problem I never had...)
This is most easily done using ALSA's dmix plugin . Actually a suitabe /etc/asound.conf and a complete description on what it does can be found at the ALSA Project page on the Intel 8x0 driver. They also list how to configure a lot of well known (and not so well known) audio applications.
Note: Here we are talking about real sound mixing not relying on the fact that some application might be finished after a second so it looks like sound mixing.
Having set up the software mixer correctly, all old OSS-applications work here without blocking the hardware device /dev/dsp if they are started through the aoss wrapper from the alsa-oss package that comes with Debian. As this wrapper just sets a LD_PRELOAD to the libaoss.so and this does not seem to disturb real ALSA enabled applications it might be an option to source it from the startup scripts. (Though I have no idea if this is a good solution or about it's drawbacks; I do not use it that way).
The setup used here replacees the call to some osssoundtool by
and all is well. Having said this one famous application that seems to require this is Java which seems to fall back to OSS if it does not find a hardware mixer within ALSA. To this end I use a simple wrapper script for java:
#!/bin/sh # # Pipe Java through aoss # aoss /usr/local/j2sdk/bin/java "$@"
which I place in the path before the actual java-executable in /usr/local/j2sdk/bin and just call "java" as well. So if any application tries to open java it goes through this wrapper.
Note: Also sound daemons (esd, artsd etc.) can be wraped in aoss if they do not support alsa by default, which eases up life considerably.
If all applications use play from the sox package for sound output (which is pretty common and still uses the depreciated OSS!) an immediate solution is to replace play by a small shell script:
#!/bin/sh aplay "$@"
The same way one could reroute calls to esdplay or whatever to use ALSA directly.
Additionally allmost all modern applications speak to ALSA by default or if they do not they offer a switch to change to ALSA. Examples are e.g. xmms, xine and so on. In this case just instruct the application to use ALSA directly and all is well.
A pretty broad coverage on the topic can be found also at the Gentoo Project. Though I do not consider Gentoo an option for my daily work for various reasons the main feature of this project is the excellent documentation on "how do I actually do it without any fancy whizardry provided by distribution XYZ". The pages one might want to consult are
Network
Well, the e1000 module. Works out of the box.PCMCIA
With the above kernel out of the box, using yenta.IrDA
Checked this part, but not yet in detail an didn't get it working yet. According to the Net the nsc-ircc.ko should work, at least it is documentet that some similar machines work with that FIR module. Note that in order to compile this module you have to enable ISA-support. (Uh.)
IrDA is finally working due to some very good hints by Nikias Bassen either in SIR or in FIR Mode. The above kernel config already contains everything necessary. The trick is to give the nsc-ircc module the proper dongle id as a parameter. This ID is 9 on the T41p. So you can just load the FIR-Module by
You can use this irdamode script by Nikias to switch between both modes. Just call it with sir to enable SIR-Mode on /dev/ttyS1 or with fir to enable FIR mode.
Alternatively I've added some lines to /etc/init.d/irda and its config file /etc/irda.conf to incorporate it into the normal system startup. Note that this init-script incorporates the loading/unloading of the modules as well as I don't fire up IrDA on every system startup. I rarely need it an it does not need to consume power all the time.
Right now my udev Setup does not create a proper /dev/ircomm0 if I load the FIR-Modules. This has to be fixed. It seems that udev is still lacking some rules to create all the usual devices correctly.
Since I am using udev I do not get /dev/ircomm0 anymore so pilot-link is unusable. It continues to work without udev though, so there is only a rule lacking for the creation of this device.
As a work arround I currently use irobex_palm3 to transfer files to and from the Palm and the notebook. In a way it is even more convenitent than pilot-xfer as it doesn't require the invokation of hotsync on the Palm. Unfortunately, backups of the device are impossible with irobex_palm3 but this seems to be the major drawback.
The IrDA issue mentioned above is fixed with these local.rules for udev which should go to /etc/udev/rules.d. Additionally it is required to load the ircomm-tty module by hand.
NOTE: The acpi-scripts map switching IrDA on and off as event for Fn-F9. It works for IrDA the same as for BlueTooth.
Motorola Timeport Cellular Phone
To connect a Motorola Timeport as modem via IrDA one can follow the instructions on M. McConnels page. With the above setup for IrDA it is already recognized correctly as IrDA-Device in FIR mode. This can be checked with
easily. To use it just set up minicom to use /dev/ircomm0 as modem device. As init-string one needs AT+CBST=7,0,1 to request an analogue modem connection. The dial command is the usual atdt. Note that this is a 9600bps GSM connection. Connection build up requires some 15-20 seconds. Also note that you need data calling services enabled on your handset by your GSM provider (should be default today). Of course also wvdial can use this modem device.
Palm III PDA
Connects via pilot-xfer right out of the box. Just use /dev/ircomm0 as $PILOTPORT or place a proper link from /dev/ircomm0 to /dev/pilot. Connection works fine for me up to 57600bps which is the upper limit of my Palm III for serial/Ir connections. FIR surely should provide much higher rates.
BlueTooth
As documented on the web enableing BlueTooth works fine and loads the proper kernel modules once you installed the necessary tools via apt-get. Unfortunately switching off the BlueTooth components hangs the kernel as is documented above. You can even find the way how to fix it there, but I didn't have time yet to look into details of this quite involved procedure.
Freezing of the laptop once disabeling the BlueTooth connector is described below. Once the problem with IBM's own DSDT are fixed switching BlueTooth on and off works as designed. To check wether BlueTooth-enabled devices are arround use the command
respectively. Now you should be able to see e.g. your mobile phone, your printer or whatever other devices are arround.
Right now the only device I have at hand which uses BlueTooth is a Sony Ericsson T610.
Once it is discovered file transfers to the phone are easy: Just use the obexftp program to send them to your phone which will store them in appropriate places once it can handle the file you tranfer. (E.g. it stores pictures in "My Pictures" and so on; please read the documentation for your phone about this.) Unfortunately obexftp is mainly a backend program not really meant to be used by the user itself. But this is possible of course. Documentation is a bit thin and especially lacks any examples as usual in the new Linux word, so it can take some time to fiddle out how to use it. Here is the example that is lacking in the docs:
would put myfile.jpg to the phone where you have to replace the ID by the ID of your phone. Even the channel may change if you have a different device. The necessary information is provided by the hcitool scan and hcitool inq commands as shown above. To transfer files you want the service "OBEX push" as channel.
Now all this is not quite nice and one surely wants some real userland tools for it. As I don't like KDE at all but prefer my own desktop based upon WindowMaker and ROX together with some addenda from GNOME I use the GNOME BlueTooth Subsystem. The author also provide an Unofficial Debian Repository which can be used by adding
deb http://debian.usefulinc.com/gnome ./ deb-src http://debian.usefulinc.com/gnome ./
to /etc/apt/source.list. Note that it is built against Debian Unstable, but it works very well for me in Sarge, so I just installed gnome-bluetooth via apt. Having done this the following applications are available:
- gnome-bluetooth-manager: A simple app replacing the old gnome-vfs-implementation for Bluetooth. It just scans for available devices and shows them. Unfortunately right now it can't do much more than just showing them. To get details about them you have to use hcitool on the shell.
- gnome-obex-server: A simple daemon running in background and monitoring your Bluetooth-Device for incomming data transmissions. Once a file is sent from your phone or whatever a dialog pops up asking you first wether you want to allow the specific device to talk to you at all and then wether to store the file. Right now all files downloaded that way are placed in your $HOME-directory. To send data from your phone to the computer just fire up this daemon and then send the files from the phone via BlueTooth.
- gnome-obex-send: gets a file as argument and starts a Bluetooth transfer. A dialog pops up asking you to which device you want to send it. Select the destination and that's it. Using this as a "Send-to" target in Rox is immediat ;)
For sending and receiving SM's via BlueTooth you can install gnome-phone-manager. This one right now requires a GNOME Panel with a status area to be usable.
Using Bluetooth throughout
The following applications are worth closer consideration:- PilotLink network hotsync
- gammu: Multipurpose text mode application for communication with your mobile
- wammu: a nice wx-frontend for gammu
- MultiSync: synchronise some device with some other device e.g. your mobile with your handheld
Synchronising your Palm with Bluetooth
Actually PilotLink does not know a thing about Bluetooth. But this is not really a problem as PilotLink knows how to synchornise via network. So the work arround is immediate: built up a network connection to your Palm using Bluetooth! And the nice thing is: everything is there already. The main part is documented already. For Debian one just has to switch on the dund daemon via /etc/default/bluez-utils. This can be done by editing this file and adding/uncommenting the following stanzas:
DUND_ENABLED=1 # To sync the Clie DUND_OPTIONS="--listen --persist --msdun call dun"
The first line is set to 0 so DUND is disabled by default. The last line differs a bit from the default and is just taken from Daves excellent documentation. In other words the above is just a "where to place it on sarge". As already mentioned the rest is all in Daves documents so it is not repeated here. After all is set up like above and the handheld configured pressing Hotsync there will just connect to your linux box and log in. Before pressing hotsync however the PC should wait for the Palm to connect. The proper port for pilot-xfer is -p net:any which will listen to any incomming network connection. Of course in case of multiple devices one could limit this by replacing any accordingly.
Connecting your phone
To get access to the mobile on the shell gammu is the way to go. Unfortunately it is not in sarge yet so it needs compilation from the sources. Another drawback is, that the documentation is a bit thin. Especially if one is not using a Nokia-phone but some other. For the Nokias there is almost everything in the doc as each of them seems to speak a different dialect and they seem only to have in common not to use any standardised interface. The proper gammurc for a Sony Ericsson T610 should look like this:[gammu] port = 00:00:00:00:00:00 connection = blueat logfile = /tmp/gammulog logformat = textall startinfo = yes
$ gammu --identify
Connecting the phone to the PDA
Having several devices at hand to store certain data at some point rises the question how to synchronise them. One way is multisync which is part of Debian stable already. Just$ aptitude install multisync libmultisync-plugin-all
to get it.Do not forget to install the plugins! Without them multisync will just create a nice window. To connect a Palm PDA with the phone one just creates a sync pair in multisync consisting of the Palm on one side and the phone on the other. If both devices should be connected using Bluetooth (i.e. entirely wireless) the Palm pluing has to be configured for network sync. The port needs to be set to any (in the easiest case). The phone setup is immediate using the irmc plugin. This also handles Bluetooth connections to the phone though the name suggests the other end of the optical spectrum. To get the phone knonw to multisync it is easiest to let multisync search for it, as it also needs the proper channel to be set. Just click on search in the setup dialog and select the phone from the list. Once everything is set up one can sync both devices. multisync will ask for Hotsync to be pressed and this should be answered by initiating a (Bluetooth) network sync on the Palm using the Hotsync application there.
Note 1: It might happen that the first synchronisation duplicates some address entries on the phone and the PDA. Deleting the dupbletts on the handheld and resycing cured this here.
Note 2: multisync offers quite a lot of plugins. So it is worth checking even if one is not using a Palm and a T610. There are also plugins to synchronise to evolution. And one nice thing about multisync is, that it can synchronise periodically without user intervention. (Though in case of PalmOS one unfortunately has to press Hotsync.)
Note 3: multisync will soon be superseeded by OpenSync which is already in Debian testing, though as of this writing it is still in beta.
Note 4: For people who had once a weak moment and for some incomprehensible reason bought a device using a thing called "Windows CE" multisync might also be the way to go. At least it offers a plugin for synchronisation with such beasts. Note however that this plugin (synce-multisync-plugin) is NOT installed upon installation of libmultisync-plugin-all.
ACPI
Compiled into the kernel as module via the options above. Note that my kernel config also has the possibility to use the older APM which is also compiled as a module, so in case ACPI doesn't work for you as you expect just switch back. For me it works except Fn-F3 aka "Backlight off". I use the follwing events and scripts which live in /etc/acpi/events for the event files and /etc/acpi respectively (see the event-files):
- lid: close the lid to put the machine into sleep mode. This is done via lid.sh, where you may change the standby-mode easily.
- powerbtn: to shutdown the machine cleanly use powerbtn.sh-Script.
-
ac_adapter: triggered when the
power mode changes from AC to Battery and vice versa. This
script is directly from Laptop
Mode and just the path is adopted to look like the other
scripts. It calls the battery.sh which
is from the same source and enables/disables laptop-mode as well
as sets the spindown timers. See the scripts on how they
work.
Note: These scripts require laptop-mode to live in /sbin and beeing executable. This script is also from Laptop Mode but includes already the correction for XFS (XFSHZ set to 100 as mentioned on the web page, which is required since kernel 2.6.5).
Update: 05.08.04At the moment I disabled the Laptop Mode as it caused certain system hangs, and to me a reliable system is always the main goal. E.g. I get very often a HDD spindown on system shutdown. And I'm entirely unable to wake the HDD up again. Unfortunately the system can't close it's FS and commit the journals with a spun down HDD. Even beeing quite fond of XFS and never ever lost any data on it's recovery, I love my data and don't want to loose it just cause of such a silly thing...
- sleep: triggered by Fn-F4. Curretly I use the same sleep mode as for lid close. You can adopt this easily though via sleep.sh
- standby: should be triggered by Fn-F3. Till now I don't know how to configure this, but I hope to get it in the future. Its easy to set it to the Access IBM button via tpb which I use as a work arround right now.
-
Update 31.10.05As with 2.6.14 swsusp seems to work reliable (in fact I never tried earlier versions) it can be bound to its designed key: Fn-F12. This script actually uses some features of ibm-acpi in 2.6.14. E.g. it signals entering stanby to the user by blinking both the battery and sleep-LED and issuing the well known "IBM-beep". Besides it calls sync before entering sleep mode (one never knows ;).
Adding this feature makes Linux to finally arrives at nearly the stage of my productive OS/2 setup (except the GUI of course, here OS/2 is still years beyond Linux) dated back to 1996: OS/2 Warp 4 on an IBM ThinkPad 760XD. Some things take some time... It would be nice if the box would "hibernate on power low" (like OS/2 did), but till now I have no clue about the acpi-event thrown at low batt. If there is one it is easy to implement now though. Anyway, right at the unfortunate end of OS/2 lifetime there seems to grow a replacement at the horizon.
Note: These scripts are not my invention buy from enyo.de
For some reason ACPI just stoped working with one of my latest kernels built. Searching arround the net I found that at least for some systems setting acpi_sleep=s3_bios as kernel parameter solves this problem. For me it doesn't. But I found that the problems were caused by the hotplug subsystem here, ie. disabeling hotplugging will reenable proper sleep modes via ACPI. As I'm currently experimenting with some patch to the USB subsystem to be able to mount my Sony Clie (in this case some delay scanning patch which resolves all problems on that front very nicely) I'm not sure wether this is causing the problem. Anyway, I updated my ACPI-Scripts to reflect the new situation and they now shut down the hotpluging subsytem before entering sleep mode. After waking up again they reinitiate it again. At this occasion I also found how to have some actions done after waking up. Actually it is very easy, one just hast to see it... (Yes, the scripts are just continued after issuing their respective sleep commands and waking up again. Hint for the maintainers: sometimes it would be really helpfull to have some working not oversimplified but also not fancy examples in the docs, ie. examples and examples which have some relationship with "Real Life"(tm).)
Note: Entering sleep mode on the console switches off the radeon
backlight, and it will not be switched on again. Unfortunatley even
the radeontool doesn't switch it on properly again, that is it
switches it on, but I get a complete white screen. Not much difference
to a complete black one... But I found that switching to X and back
again reinitializes the graphics card to a proper state. (Ati. Was
always strange, will always be strange, I'll never like them.) So it
is a good idea to have X11 running on consloe 7.
Note 2: Sometimes after waking up I found that the machine enters
sleep mode right again. I feel there are some ACPI-events lurking
arround in some buffer and that it would help to just clean all those
buffers right before entering sleep mode. Unfortunately I have no idea
how. Additionally "wake up on lid open" would be nice.
With the ibm_acpi module provided since kernel 2.6.10 there is the possiblity to catch any button-related ACPI-Events, so I reworked the above setup completely and assigned the defined functions to the buttons where possible. The princple is the same as described above so I'll not place the indiviudal scripts here but just one tar-files (acpi.tar.gz) which includes my whole /etc/acpi directory. Essentially, if one enables the hotkeys as described in Documentation/ibm-acpi.txt the name of the events change, so e.g. the sleep-button now requires the following event-file:
# /etc/acpi/events/sleep # event=ibm/hotkey HKEY 00000080 00001004 action=/etc/acpi/fnf4.sh
You can see easily how this works out. Besides using different events I renamed all action-files to represent the name of the fn-key pressed. They then exec some scripts with more sensible names. I found this easier than my old approach based upon the suggestions of enyo.de especially as now there are quite some events to handle.
NOTE 1: My new scripts also handle the Fn-F5 function to switch BlueTooth on and off using the ibm_acpi functions. So there is no need to start bluez-utils at boot time anymore, it is triggered by the Fn-F5-ACPI-event. NOTE 2: For handling of UltraBay-Events there are also two scripts, but as I don't own "multiple" UltraBay Devices I can't test them thoroughly. Anyway, have a short look at the HotSwap / Ultrabay section.
Just see that I missed to mention that "wake up on lid open" works fine in 2.6.10. Additionally the problem that the machine suspends right away once a wake up is initiated is gone with the new kernel. Anyway, if you stick for some reasons with an older kernel I got the hint, that adding
[[ `grep open /proc/acpi/button/lid/LID/state` ]] && exit 0
at the beginning of the sleep.sh solves this problem, as it is simply caused by an additional sleep-event generated on wakeup. Thanks to D. Won for fiddling this out.
There seems to be a bug in ibm_acpi not to evaluate parameters given to it upon modprobing. For this reason the hotkeys do not work until issuing an explicit enable to /proc/acpi/ibm/hotkey. As I had no other idea on how to do this upon system startup I simply added a new system service LOCAL to /etc/init.d/ and configured it
update-rc.d LOCAL start 99 2 3 4 5 . stop 99 0 1 6 .
Some changes to the ACPI-Handling, e.g. disable sleep by lid close if AC powered and stuff like that can be found in acpi-040806.tar.gz).
Another change included the installation of the Laptop Mode Tools which work very well with the laptop mode compiled into the kernel and allow the disk to spinn down automagically and stuff like that. One has to adjust laptop-mode.conf for personal needs though. Special hint to Ubuntu users: According to the author the Ubuntu-packages of these tools are based on a very old release so checking out the above website is advisable. Also according to the author his packages will work on Ubuntu as well. (Well, they are "only" a bunch of shell scripts...)
HotSwap / UltraBay
With the ibm_acpi module from kernel 2.6.10 there is also the possibility for hotswapping of UltraBay-Devices, if you own several of them. I don't but at least I was able to safely remove my DVD and reattache it without any problems. Currently my ACPI-Scripts just take care about a CDROM inserted or ejected from the bay. As mentioned in the ibm_acpi docs all you have to do to create an eject request is
echo eject > /proc/acpi/ibm/bay
and once the light wents off you can safely remove the drive. The status of the Bay is reported by the same file so if you use several drives there you might want to use one or two of the newly gained Fn-Key-Cominations to generate events for swapping devices.
SpeedStep
Additionally you may want to apt-get install cpufreqd to use the "Enhanced SpeedStep Technology" of the built in Pentium M. Though you might want to adjust it to your personal needs you can use my cpufreqd.conf as a starting point. Note that as I'm using ACPI the parametes in this file are given in Hz and not in % of the max. CPU speed. Also note that I power down the machine on AC-power to keep it cool and even quieter than it already is. My lower limit is only 600MHz. But this is enough for typing. (If you don't believe it try to get 100% CPU-usage within vi if you run you CPU at 600MHz. ;) Also note that on AC the CPU can step up to it's maxiumum 1.7MHz if certain apps run or the CPU-usage is very high. So in normal usage I never saw any performance losses.
Rewrite of cpufreqd.conf to be more readable (at least to me) and clean up of profiles and rules.
Also note that running at 500MHz and running an scp command on the integrated LAN-Interface, transfer speed is limited by CPU-power! This happens in my config e.g. if the machine runs on battery. In case you copy large ammounts you may want to step up. You can most easily achieve this by just fireing up xine. Simply as it is listed as an app that triggerst upstepping to the max (via "dvd_watching" rule) and does not need any CPU if you do not watch a film.
Besides cpufreqd one could also use cpudynd. I didn't mention this here before as it just didn't work out for me and after some fiddling arround with cpufreqd and it's not that easy config (only at a first glance once you got the concept it's straight forward indeed) and getting this to work I just applied (as usual) the
Never touch a running system.
Anyway, I got the information and a config file for cpudynd from M. Kienle so I just wanted to add it here for your convenience. Just feel free do choose whatever deamon you want. Note that in principle cpudynd can also spin down your harddrive. "In principle" means that unfortunatley this is not that an easy task on Linux and you need to enable the Laptop Mode and tweak accesses to the file system. Otherwise the HDD will always be busy (e.g. for writing the journal, the a-time and so on). So for me this "in principle" is only a principle which unfortunatley till now never worked as I expected.
Note: Continuous spinning up and down of your hdd will shorten it's lifetime considerably. In a way you're stress testing the mechanics here. You'll find some infos on the net about this issue and Linux.
ACPI - Advanced: Installing Custom DSDT
As I recently found out there is a real issue with ACPI and the internal USB. I.e. if you connect some ttyUSB-Device you run into the same problem as switching off the internal BlueTooth: the machine hangs and is entirely dead. I didn't experience this problem with my mass storage though but I normally detach it once the machine goes to sleep. The same problem was reported to me if one attaches a USB mouse. (But why would anybody want to attach a USB mouse as a ThinkPad has the only decent pointing device on the planet: a TrackPoint...)
The only way to get it to life once again is to power it off entirely. This is a known ACPI-issue with the BIOS-implementaion of IBM as far as I could figure it out. According to my reading through the net one has to fix it via DSDT using Intels ACPI Build Utilities for Linux. As far as I read one can follow this detailed description (evenly helpfull might be this document) on what has to be done or even obtain a working DSDT from Sourceforge.
Note that I got this informations only by reading right now and did not implement it myself yet. It seems to be a rather involved procedure and not entirely easy. But as there arrose some pressure to get it working I'll soon check into this.
Finding out that I needed a newer revision of the Kernel to be able to mount the MemoryStick of my Clie. Kernel 2.6.7 should fix this issue.
The Procedure
- Dumping the DSDT
First of all one needs the original (ie. broken) DSDT:cat /proc/acpi/dsdt > dsdt.dat - iasl
After downloading Intels ACPI Build Utilities for Linux I found that the compiler does not compile on my System. Seems to be an issue with the gcc, which is probably to new. So I compiled iasl on a RedHat Box 9 box. It should be mentioned that Intel never heared a thing about "case sensitivity" in file systems. So you will have to rename all directories which are in uppercase to lowercase. - disassemble the dsdt
With the freshly build iasl it is easy to disassemble this table into Intels ACPI Assembly Language:iasl -d dsdt.datwhich yields a dsdt.dsl file. - Recompile to find the errors
iasl -tc dsdt.dslcompiles the file and issues some errors and warnings. As this is specific for the BIOS-Version you are running it might be wise to just check how it looks like "done right"(tm). For this I compared the additions in a working DSDT with the actual code I got and added the neccesary things. The result is my fixed dsdt.asl which compiles without any errors and warnings.
Here a short summary what I had to change:is IBM's original code. This yields an out of bound reading of some array. The last 0x02 has to be 0x04 as I got from the table from SourceForge. Changing this already fixes all errors within the DSDT, leaving one with two warnings.Device (USB7) { Name (_ADR, 0x001D0007) Name (_S3D, 0x03) OperationRegion (U7CS, PCI_Config, 0x62, 0x02)
andMethod (MHQC, 1, NotSerialized)both had no return and required to add the following line at the end of the method:Method (MHGC, 0, NotSerialized)Now also all warnings had gone.Return(Package(0x02){0x00, 0x00}) - Patch the Kernel
First of all one hast to copy the newly created dsdt.hex file (one of the outputs of Intels iasl) to the kernel tree:cp dsdt.hex /usr/src/linux/drivers/acpi/dsdt_table.hThen one needs to modify /usr/src/linux/drivers/acpi/osl.c. Clearly this file might change depending on the kernel version and some distributions even have already patched files here. So here are just the changes and no patch.
- Add the hex-File to the source:
add this line at the beginning of this file.#include "dsdt_table.h"
-
Search for
acpi_os_table_override (struct acpi_table_header *existing_table, struct acpi_table_header **new_table) -
Replace the line
by the following:
*new_table = NULL;*new_table = (strncmp(existing_table->signature, DSDT_SIG,4)) ? NULL : (struct acpi_table_header *) AmlCode;
- Add the hex-File to the source:
- Recompile and install your kernel (e.g. using DEBIAN_KERNEL script)
The above procedure simplifies significantly with Kernel 2.6.9. With this release two switches for the .config where introduced which allow to set the path to your DSDT once and for all. Just add the following lines to your .config:
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/dsdt_table.h"
and place your dsdt_table.h in /usr/src. You do not need to patch the kernel source according to the above instructions by hand anymore! But note, that in the created config-file in /boot these two lines are removed.
Sometimes make olconfig seems to ignore the custom DSDT. One can check wether the DSDT replacement is actually working by looking at dmesg. It should state somewhere the line
ACPI-0284: *** Info: Table [DSDT] replaced by host OS
#define CONFIG_ACPI_CUSTOM_DSDT #define CONFIG_ACPI_CUSTOM_DSDT_FILE "/usr/src/dsdt_table.h"
Then just run make oldconfig and build the kernel as usual (e.g. using DEBIAN_KERNEL script).
Running Kernel 2.6.9 for some time now I found that again the huge parts of the USB Subsystem have changed. Especially the Mass Storage Part. I found it convenient to switch from my old-fashioned static /dev-tree to the new, dynamic udev system via
apt-get install udev
udev requires to add nvram to be loaded by default on system bootup. Just add
nvram
to /etc/modules. Additionally tp-scroll needs some additions described in Trackpoint scrolling.
Though I disabled the ub module in 2.6.10 again and I have now found udev a nice thing and stay with it. Also it solves the old problem of USB-Mass-Storages in a very conventient way for me.
First of all I should mention that I do not like the /media/usb:00:ab:cd:ef:gh:ij:kl-approach at all as I know it e.g. from SuSE Linux. Mainly I hate this long and meaningless mountpoint and also I don't like their automounting-approach. I prefer the "classic" style: mount by hand and especially to some decent position in my file system and proper static entries in /etc/fstab for the devices a user uses. And if (s)he wants something new, well this is a Unix, so go to your adminstrator and (s)he will enable it for you. (And think twice if you really want it ;). My approach has some pro's and con's of course which I don't want to discuss here. Anyway, the main problem is, that one has no influence which sd device is assgined to some usb-drive if inserted.
And this I solved, as I find, "nicely" with udev. I just craeate a link for some of the special devices nameed /dev/usbhd or /dev/usbstick and then use /dev/usbhd6 or the like in my /etc/fstab. For this to achieve some local.rules are required to assign the poper links. Placing this file in /etc/udev/rules.d will enable my additions. The first rule crates symlinks for the CDROM to /dev/cdrom, /dev/cdrw and /dev/dvd. It is mainly a copy of the supplied rule. The next two rules are examples on how to use the SYSFS-keys to find a specific vendor and model and base link assignements on it. The rules itself should be considered an example, they can easily be adopted to your needs. Note that you HAVE TO adopt them to your needs! It is very unlikely that you own exactly the same devices as I do ;)
According to some hint the following entries might be helpfull to handle external USB-HDD's or a card-reader:
BUS="usb", KERNEL="sd*", SYSFS{product}="External HDD", NAME="%k", SYMLINK="usbhd%n"
BUS="usb", KERNEL="sd*", SYSFS{product}="Memory Card Reader", NAME="%k", SYMLINK="usbcr%n"
BUS="usb", KERNEL="sd[a-z][0-9]", SYSFS{product="DiMAGE Xt", NAME="%k", SYMLINK="usbdigicam%n"
BUS="usb", KERNEL="ttyUSB1", SYSFS{product}="Palm Handheld", NAME="%k", SYMLINK="pilot1"
BUS="usb", KERNEL="ttyUSB0", SYSFS{product}="Palm Handheld", NAME="%k", SYMLINK="pilot"
To find the proper entires udevinfo is uesfull, e.g.
udevinfo -p /sys/class/tty/ttyUSB0 -a
Additionally it is may be helpfull to set
udev_log="yes"
in etc/udev/udev.conf.
A current fstab implementing all of the above and the accompaning local.rules for udev.Installing Additional Components
TrackPoint Scrolling
This section comes here cause you'll want to have it for X. Note that TP-Scroll is not compatible with gpm though!
First get the software from http://rsim.cs.uiuc.edu/~sachs/tp-scroll/ then just follow the Readme for installation. Note that the init-script that comes with tp-scroll is designed for SuSE Linux or something similar so it will not work out. I use a pretty simple script based upon the delivered one. Also use update-rc.d to add the script to the automatic startup deamons for you X11-runlevel, which for some strange reason is 2 on Debian for X11.
Note: The first thing I do on a Notebook is to check how to switch off an eventually installed Touchpad. I'm just not compatbible with them and consider them absolutely useless. That is one reason to stick with IBM: They use a decent pointing device (aka: TrackPoint). Anyway, the built in touchpad is quite an extended version of such a device. You might want to look on other pages how to make most out of it. From my reading it is quite well supported on Linux but as I don't use it I didn't check it. (As I said, the first thing was to switch it off via the BIOS. An additional plus for IBM: they allow this selectively for the Touchpad, the Trackpoint or both!)
Using udev breaks tp-scroll as /dev/imouse is treated as a normal file and not as a fifo anymore. Till now I didn't figure out how to create it again in /dev and to have it handled by udev correctly so I decided to use some hack: just create it at an other location. I choose /etc/X11/imouse for it:
mkfifo /etc/X11/imouse
and just adopted /etc/sysconfig/tp-scroll accordingly. With udev the input device is /dev/input/mouse0 and output is the newly created fifo. So the necessary two line read:
INPUT_DEVICE="/dev/input/mouse0" OUTPUT_DEVICE="/etc/X11/imouse"
Additionally one has to adopt the XF86Config-4 accordingly:
Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/etc/X11/imouse" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "on" Option "ZAxisMapping" "4 5" EndSection
Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/mouse" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "on" Option "ZAxisMapping" "4 5" Option "EmulateWheel" "on" Option "EmulateWheelButton" "2" EndSection
to get a Wheel-Emulation without the need of tp-scroll. Pressing the middle mouse button and dragging the mouse. And he is right indeed. Unfortunately I lost the ability to paste text from the X11-Cliboard with the middle mouse button if I use this setup, so I stick with tp-scroll for the time beeing.
Probably for some of you the Linux Trackpoint Untilities might prove usefull, though I do not use them myself.
Kernel 2.6.14 introduces an interface to configure the TrackPoint via sysfs. This feature was availabe in earlier kernels only as a patch but now made it into the vanilla. A documentation how to use this interface states that it should be possible to get a "press to select" functionality, but unfortunately this did not work out in my test yet. The interface itself can be accessed in sysfs via the files in
(if anybody can explain me the coolness of this location compared to the "old-fashioned" /proc/trackpoint I'd give him a honorable quotation here as an update.) Besides the press to select one can set the sensitivity and the speed of the device. Unfortunately the driver removed the scrolling emulation and the readme suggests to use X for that which has the downside mentioned above. So sticking with tp-scroll gives one the most at the moment. But there seems to be a patch underway which can handle the middle click in x.org. For the configuration itself there exists a graphical tool but unfortunately I found this not working as it seems to rely on the existence of /sys/devices/platform/i8042/serio0/middle_btn_disable which is not created in my setup for whatever reason. Probably the utility will be updated to match the kernel driver as it was obviously written for one of the patches.
To enable the press to select feature one should issue
echo -n 1 > /sys/devices/platform/i8042/serio0/press_to_select
Similar commands hold for all other configuration options.
XFree86
Before I set up a "non-framebuffer" Version of X I installed the X-Environment from Debian + the basic X-based apps I wanted to have. Just to make sure that I have already the necessary infra structure before replacing the actual XFree 4.3.0-7 which doesn't support the ATI FireGL T2 card of my Notebook. Note that with 4.3.0 you get already a working framebuffer which is at least a start. Though I didn't get 1400x1050 to work but only 1024x768.
Then I decided that it's time to use some real driver. Here I use the binary version of XFree 4.4.0 from XFree86.org. Installation goes smooth following the "Install"-File. Note to Backup your original X11R6-Installation as described in the install file in case something fails. Of course you can also build from source if you prefer. (I didn't do that this time myself.)
This installation doesn't support the OpenGL interface of the ATI-Card though which needs some kernel modules ATI only provides in binary form as RPM for some 2.4.x SuSE or RedHat-Kernels. If someone can give me a hint how to enable even the real OpenGL this would be nice. Though for my work it is really a minor issue.
Unfortunatley XFree 4.4.0 comes with a font manager that is to old to work with GIMP 2.x (coming with Debian Testing). Luckily Debian installs the librarys for it's own font manager to /usr/lib and not to /usr/X11R6/lib so you can savely remove the libs that came with XFree 4.4.0 and gimp is happy again. You have to remove the following files:
- libfontconfig.a
- libfontconfig.so.1.0
For the default resolution of 1400x1050 you don't have to add anything to your XF86Config-4, running X -configure will write you a suitable config-file. Anyway, here is the XF86Config-4 file I use. Note that it contains already the imouse-support. You have to add the software for this first.
As recently a new release of XFree86 for testing was added to Sarge I added the necessary lines to /etc/apt/preferences to ignore it entirely and not to overwrite any of the XFree 4.4.0 stuff.
Recently it was pointed out to me by F. Zeller that there is some howto and some packages for the proprietary FireGL Drivers for Debian. According to his mail this worked for him though I did not have the time to check into this in detail yet. You might want to give it a try anyway it is quite detailed.
Connecting a Beamer
First of all this sounds trivial: just plug it to the VGA outlet. "Unfortunately" this has a problem: the internal display is 1400x1050, a resolution not only uncommon but almost unknown to a beamer of these days. Some people might say that connecting a beamer on Linux isn't an issue as "of course you need some Windows-Software for your presentations anyway". Well, I don't need any windows and I want presentations with some style and real world mathematical formulae which is the reason that I make my talks of course with LaTeX (together with the Propser package). So connecting a beamer is an issue.
Back to the main problem: the ideal setup would be to run the external display at a resoluton of 1024x768@60 while the panel should of course stay at 1400x1050. Of course one wants to see the entire screen of the presentation on the panel. To achieve this I followed closely the setup of K. Weidner.
The main idea runs as follows:
- Set up X t orun a dual moitor setup, one monitor is the panel one the external display
- Install xvnc by means of
apt-get vnc-common vncserver x11vnc xvncviewer
- Run a vncserver on the local host
- Connect two xvncclients to the vnc-server, one displayed on the panel, the other on screen1 in fullscreen mode.
- Send the presentation application (in my case Adobe Acrobat Reader) to screen one and stear it via xvncclient on the panel.
The main feature of this setup is to have an independent external screen which can display entirely different content than the panel. Though it is not possible at the moment to move windows from one screen to the other with the mouse. Additionally, the presentation application runs on an X-Server which is already at the right resolution. So it is just a ctrl-l to switch it to full screen mode and all is well.
For Dual Monitor support I use XF86config-4 it just uses a different server layout incorporating the two screens: one running by default at 1400x1050 for the internal display, the other running at 1024x768 max resolution with 60Hz which is the external display, aka the Beamer. Given better resolutions and higher frequencies you might also want to attach an external monitor there.
The next steps incorporate the vnc-software. In esence all I had to do was:
vncserver -geometry 1024x768 :3 & vncviewer -fullscreen -shared -viewonly -passwd $HOME/.vnc/passwd localhost:3 -display :0.1 & xvncviewer -passwd $HOME/.vnc/passwd -shared :3 & acroread -display :0.1 myfile.pdf
Looks pretty unixish with all those cryptic parameters, which is why it is put together in present, a simple shell script doing all this stuff. Just call it with the pdf of the presentation. Note that compared to K. Weidnerdescription some parameters of the vnc-programs changed. This seems to be version dependent. I use the edition distributed with Debian Testing which is 3.3.7 as of this writing.
Drawback:
- vncserver sometimes believes that it is already running so a second startup of present fails. The straight forward solution would be to split the client and server startup. Seems that it just needs quite some time to settle till one can start it again.
Note: If you are using WindowMaker, which you definitly should consider, you may want to addd -display :0.0 to the wmaker command in your .xinitrc. Otherwise WindowMaker will manage all your screens which you obviously don't want for the usage mentioned above.
madWiFi
First get the following packages:
- wireless-tools
- wavemon
In order to compile madwifi modules for Linux you need a populated linux-kernel tree. Populated means that you need all the *.o-files created during make modules. In normal circumstances Debians make-kpkg runs a make clean once the deb-packages are finished. To avoid this set
in /etc/kernel-pkg.conf. If your tree is already clean the modules will be rebuilt while compiling madwifi-modules which does no harm but takes a lot longer.
To compile madwifi you first need to get it anyway. Currently the project has not released any tarballs but you have to check out the current version from SourceForges cvs:
This will create a directory called madwifi where you can find detailed instructions which you will read of course. :) To make long things short, before you issue a make you set two environment variables:
is required for "some legacy AP's" as the README put it. I found that I need to set this to get wireless to work with the installed accesspoints here.
After this just run make and wait some seconds for the modules to compile.
Running 2.6.5 kernel the modules should be called *.ko and the makefile creates such files indeed. But they are unusable. For some reason one has to load the *.o-files (like for 2.4.x series kernels.) So just copy the *.o-files mentioned in the README to your modules-tree. (If you don't know where use make install and then run find /lib/modules -name ath_pci.ko and copy the ath_pci.o-file over this installed unusable ko-file. Do the same for wlan.ko and ath_hal.ko)
Load the modules with
which should load without any problems and the LED should light up. You can check wether the modules loaded successfully in /var/log/syslog. Now you need to bring up the interface which in case of madwifi is called ath0
NOTE: In order for the driver to do anything you need to bring the interface up first! This is a documented feature. To scan for your next access point issue
Once you have the access point you can see the essid etc. all the stuff you need. Now edit /etc/network/interfaces:
#---------------------------------------------------------------------- # Wireless Card via madwafi # NOTE to compile the modules once the kernel is updated!!! # Not configured by default, start it manually #---------------------------------------------------------------------- manual ath0 iface ath0 inet dhcp wireless_mode managed wireless_essid YOUR_ESSID wireless_power off wireless_txpower auto
Replace YOUR_ESSID with the essid given by the scan-command above. Everything should work fine. With wavemon you can monitor the status of your wirless connection, signal quality etc. pp. Check the docs of wavemon.
As wireless LAN can require some additional work here is my /etc/network/interfaces with quite some commented lines that should deal with this. Thanks to F. Zeller for pointing out that it was missing.
To build the madWiFi-driver for the 2.6.8.1 kernel it requires this patch. After the usual checkout from the madwifi respository just apply it (after unpacking using bzip2 -d) by
and build the driver as usual. This page contains detailed instructions.
Kernel 2.6.9 now works again with the current CVS-Snapshot. No additional patches are required anymore.
Kernel 2.6.10 works with the most recent CVS-Snapshot, the version used with 2.6.9 doesn't compile. This gets a bit nasty, hopefully madwifi makes it way either into the official kernel or things hopefully settle soon. But as long as one also needs the cvs-co I wrote some script to retrieve both, the Kernel Source specified as parameter and a cvs-co of madwifi.
Switch WiFi/Ethernet
To switch easily from ath0 to eth0 and back a simple lan script which does the loading/unloading of the modules and brings up the interfaces. This script knows three parameters:
- --auto: Checks if there is a link on eth0 (cable) connected, if so, configure eth0. If not, remove the network module, load the modules for wireless and check for an access point. If there is an accesspoint, configure ath0. If not remove the madWiFi-Modules and configure no interface, lo is left untouched though.
- --eth0: configures the eth0-interface if "link" is detected and disables ath0.
- --ath0: configures ath0 if an access point is available and disables eth0
- --off: unconfigures both interfaces
To be able to use this as a normal user just add the follwoing line to your sudoers-file using visudo. (Don't forget to apt-get install sudo first ;)
%users ALL= NOPASSWD: /sbin/lan, NOPASSWD: /etc/acpi/standby.sh
Note: There are plenty of tools to configure this stuff automagically (e.g. laptop-net, laptop-netconf, whereami) but as most of them where to automagic for my usage I use my more simple and straight forward script. You might want to check out the others though, they offer plenty of functionality and may suite your own needs a lot better.
To embed the LAN switching tool into my desktop (manly using ROX and WindowMaker composition; see e.g. this page for an example how it looks like) I use this ROX-Wrapper.
Enabled syslog interface for the lan-switching script.
To use the lan-script on every system startup to check which connections are available and configure them properly you can use a slightly modified version of /etc/init.d/networking script. Also note that all interfaces except the loopback should be listed as manual in /etc/network/interfaces. The lan-script will bring them up if they are available.
The script got some reworking especially in a more effective usage of logger, adding tags and also logging to the console which removed some echo-stanzas. Besides that I added handling for AP's which respond with "unavailable"-statements to a scan. They are now treated like no available AP at all and the modules are removed.
A new lan script that also switches off certain services if there is no LAN connection at all.
Due to recent events on a local Unix cluster it is advisable also to install fail2ban from Debian Testing. It runns without problems on Debian stable as well and does not require any additional packages. Start/Stop of this service is also included in the updated lan-script.
A new verison of the lan script is available. This one includes a simple, dialog based interface to select the wireless access point to connect to.
Note 1: the madwifi-module needs some time for things to settle and to find the APs available. For this reason the script contains several sleep commands and it takes about 15s to acutally bring up the interface. Experiments without sleeps or with shorter periods resulted in unreliable network association, ie. madwifi did not find any wlan or scanning produced strange results. This is tested with version 0.9.2 of madwifi.
Note 2: This script associates in the current version to a specified AP not only to a network. This is no requirement but can come in handy in some home networks where the "administrators" don't know a thing about the ESSID so one has several APs with the same ESSID but not belonging to the same network.
Note 3: Till now it did not prove neccessary to compile a newer version of the wifi-tools though the driver complains about beeing compiled with a newer version than the wifi-tools of Debian sarge.
Modem
Though ALSA comes with the kernel modules (snd-intel8x0m) you still need to compile at least slmodemd from the SmartLink Soft Modem package. If you want to use the ALSA-version (ie. the free modem driver) only compile slmodemd from ./modem/ subdir and add the --alsa switch to its startup. That says the readme. Till now I didn't get this working (probably a problem with libalsa?) so I use the kernel modules provided by the SmartLink package. This seems to work fine. BTW: The modem device is /dev/ttySL0. It is probably a good idea to set a linkt from /dev/ttySL0 to /dev/modem.
Note: The SmartLink driver comes with a nice startup-script for slmodemd in scripts/debian/slmodem. To configure the startup-parametes (mainly the country) edit /etc/default/slmodemd. To get a country list use
After the modem is set up properly wvdialconf recognizes it properly and you can use it to configure your internet connection for wvdial.
Though I got the "latest and greatest" version of the SmartLink Soft Modem (2.9.10 as of this writing) I was not capable of loading the newly built modules with kernel 2.6.10. If someone has a clue... Otherwise I hope for a new release. But as I hardly ever use the modem (in fact I never needed it at all till now) I'll stay with 2.6.10 and keep an older kernel handy, just in case.
Switch off the backlight
For this I use the standby.sh script which just calls radeontool. Note that you need to be root to do this, see the above sudo line for an example how to achieve this as normal user. As I'd prefer to invoke this by the usual Fn-F3, which I didn't yet work out how to acknowledge via ACPI, this script lives in my /etc/acpi and for the time beeing I invoke it via the "Access IBM" button I remap by tpb.
tpb
Normally meant for those ThinkPads that have some additional buttons and to get them to use this tool provides anyway some usefull functionality on the T41p. First of all you get nice On Screen Displays for the hardware settings like backlight brightness, mute, sound, but you can also remap the otherwise useless "Access IBM" button. Currently I use this button to switch off the backlight till I found out how to capture Fn-F3 for this purpose. For my setup you can get the tpbrc here. Note that you can just apt-get install tpb on Debian.
Removed the mappings for Forward/Backward from the config as this is now handled by Fn-F3 in a more convenient way and "as designed".
Current Software Selection
My currently installed Software Selection. This is for my usage and even changes from time to time. Probably it is of some help anyway. As this list is procuded by dpgk --get-selections you can use it as input for dpkg --set-selections though I don't believe that this is a good advice to do so. Note: The kernel-images listed are my own builts.
Adding some repositories to sources.list mainly for multimedia stuff also changed my current Software Selection. The new repositories consist of
Backup of the Configuration
Th. Ohl has provided some very nice litte shell scripts to backup your configuration data by creating a cvs-enabled automatic shadowing of the files you specify. This procedure enables a rapid recovery of the system even if one is unable to write full dump backups by just reinstalling and playing back the configuration.
The installation of these tools work as follows:
- Become root
- Be carefull and understand what you are doing from this point on.
- Create some directory for the backup which should have 700 permissions for root. You probably want to backup files like your passwd or other critical files like /etc/fetchmailrc. The name of the directory is /home/CONFIGURATION by default. You can change this by adopting the scripts by hand.
- Within this directory create a new dir called shadow.
- If not already done initialize CVS for the user root. Note, that your configuration should live in a private repository, readable only by root!
- Import /home/CONFIGURATION into your private CVS.
- Add checkpoint to your daily cron jobs, eg. by placing it in /etc/cron.daily
- Use adopt to add a file to your
backup set. The usage is pretty simple
./adopt /etc/fstab
for a single file. You can of course use wildcards and specify multiple files. adopt will copy the file to your shadow directory and add an entry to a simple text file called just /home/CONFIGURATION/files. checkpoint works through this file copies all files from there source to your shadow directory (there the whole path is built up again, so restore is immediate...) and runs a cvs commit afterwards storing all cahnges to the cvs. Additionally checkpoint runs dpkg --get-selections to get a list of all packages installed on your system via Debians Package Management.
Found some inconvenience in the scripts but did not fix it (yet?). For those of you not familiar with CVS just a short note. If you add say /etc/udev/rules.d/local.rules via adopt you will get an error on your next checkpoint cause this file lives one level to deep. To fix it:
$ cd /home/CONFIGURATION/shadow/etc/udev $ mkdir rules.d $ cvs add rules.d $ adopt /etc/udev/rules.d/local.rules
You just have to tell cvs about a new directory if it is some levels to deep down in the tree. This applies to all directories to deep down in the tree. So if cvs tells you something like don't know anything about... this is most likely the reason.
Reported Problems
Most problems reported concern power management, especially sleep/wakeup. In order to get sleep modes to work well the customized DSDT is required due to some bugs in IBM's BIOS. Fixing it is rather simple as IBM seems to build in the same bugs in all their BIOSes. So try to follow the instructions above. Espeically if you have problems with entering sleep mode or wake up while USB devices are attached, this is the reason.
Similar problems often occur with X. It was reported that at least some versions of the original FireGL Drivers from ATI have this problem. Note that I never checked any of the original drivers (no need of 3D here at the moment) nor do I run the original XFree86 supplied with Sarge. My setup uses XFree86 4.4. I.e. I accepted their license for the time beeing. I never tested neither x.org's version yet nor did I ever use the x-window-syetem supplied with Sarge. Actually I installed it to meet all dependencies, pinned the release and just installed the 4.4 release over Debian's binaries. (Yes, I know, this is a hack.)
Using X11's mechanism to emulate the mouse wheel disables the middle mouse button for past. tp-scroll does not have this problem.
If the Sleep mode is initiated from within a console only session (i.e. no X11 running at all) the graphics card is not reinitialized properly and no screen output is active after wakeup.
Newer kernels require acpi_sleep=s3_bios as kernel parameter to enter sleep mode and wake up again properly.
Not Working Parts
- OpenGL hardware support. But there seems to be a howto, see above.
Helpfull pages
- The Debian Project
- Blade Install Image (XFS enabled)
- Debian Kernel Compile HowTo
- FireGL Drivers for Debian (HowTo and Packages)
- ThinkPad T40/p, T41/p - Hardware Maintenance Manual (October 2003)"
-
- Linux on Laptops
- kernel.org
- ThinkWiki
- GNUStep LiveCD
-
- Intel ACPI Assembler
- ACPI-Howto
- ACPI on R31
- ACPI4Linux
- Powermanagement for Laptops (Gentoo Linux)
-
- W. Sowerbutt
- M. Stilkerich
- Th. Ts'o
- K. Weidner
- P. Nurcahyo
- A. Clouter
-
- Dual Monitor Setup
- M. Foster (madwifi)
- M. McConnel (Motorola TimePort on Linux)
-
- Linux on a R52
Back to Theory II
Physics department homepage
Universität Würzburg
