Newer note: It's now 2009-07-25 and I haven't used this laptop in quite a while (the disk is semi-dead). I have no clue what the status is of running latest versions of FreeBSD on the T40p.
Note: This page was last updated back in the FreeBSD 5.x days. Now running 6.x on the laptop (also having tried 7-CURRENT which works), but I do not have any up-to-date detailed information on what works and what does not. I am keeping the page for historical reference, hoping it will help people. If you do have some specific concern prior to purchase, feel free to contact me and perhaps I can answer.
The above note reflects reality as of: 2007-11-02.
There are already several pages out there describing FreeBSD (and Linux) on the T40. However, I have had experiences that aren't quite covered by these pages. Also, I have the T40p (as opposed to plain T40), which is slightly different. Below I will try to summarize things that you would want to know about running FreeBSD on a T40p. In cases where an issue is covered elsewhere I will usually link to that page instead.
It is by no means complete, but will hopefully help someone out there. If you would like clarifications on something (or perhaps know how to get something to work that I don't), feel free to contact me at peter.schuller@infidyne.com.
When you receive your laptop, DO NOT BOOT IT if you want to keep Windows on the box along side FreeBSD! At least, it's best if you don't. Upon first boot, it will convert the FAT32 fs on the Windows partition to NTFS. It's easiest to resize the partition before this happens. I used Knoppix for doing this. Pay special attention to the fact that the IBM pre-desktop software is at the end of the disk in supposedly "free" space behind the Windows partition. You probably don't want to overwrite it. More information about this - and other things - is available here.
I installed FreeBSD 5.1-RELEASE from CD. The only thing you need to pay attention to during the installation is the partitioning. Make sure your slice doesn't overlap with the IBM pre-desktop area.
After installation I began working on getting stuff to work, one thing at a time. Read below for notes on each part.
At the time of this writing this is the working/non-working status of the components. Details will follow below.
UPDATE: In addition to the troubles detailed below that are solved, I found that the em driver would not reliably survive a suspend/resume cycle. this patch solves the problem - at least on my machine (not commited/commented on by any FreeBSD developers so far, so use at your own risk - PR is here).
The gigabit ethernet interface - em0 - worked perfectly during installation. When I booted the resulting system however, it no longer worked. The driver failed to load properly during boot with an error regarding the EEPROM checksum being invalid. I found this post which indicated the em0 driver "broke" support on the X31 somewhere between 5.0-RELEASE and 5.1-RELEASE. I tried using the old 5.0 driver in 5.1, aswell as removing the checksum check in the 5.1 driver. No luck. I eventually figured out that the pcmcia support seemed to break just about everything, including the em driver. When the cardbus bridge (cdb) was commented out in the kernel configuration, em0 suddenly worked perfectly. So basically, a good idea in general is to strip down unused stuff in the kernel configuration, but specifically the cardbus bridge.
(The driver could be made to recognize the card in GENERIC by - don't laugh - starting X! But even after this, the card would not actually work, as the driver would perpetually say the link was up/down/up/down/up/down with an interval of a few seconds.)
UPDATE: The problems I had with the ath driver was all my fault. After issuing an "ifconfig mode 11b" everything works perfectly for me on 802.11b networks; it's just that the mode does not seem to be autodetected.
On June 28, Sam Leffler posted on freebsd.current that a driver for the Atheros Communications chipset used in modern a/b/g wireless cards was now in CURRENT. When I found this post in the archives, I decided to cvsup CURRENT to see if it would work. I had not expected getting it to work before ordering the laptop, so this was a pleasent surprise.
To enable the driver, I added the following in the kernel configuraiton:
device ath device ath_hal
The driver successfully recognized the card, and all ifconfig commands worked perfectly. However the wireless LAN indicator on the laptop was not lit, and no traffic ever seemingly reached the card.
I talked to IBM support about communication perhaps being cancelled hardware wise (similarly to the way the Bluetooth card doesn't even show up on the USB bus when disabled), but supposedly the card should be fully working without any kind of activation sequence. At least according to the guy I talked to.
It is worth noting that when I incorrectly allowed Windows Update to update the wireless NIC driver in Windows XP (upgrading to some Phillips driver instead of the Intel one that shipped with the laptop - or possibly the other way around), I had what looks like the very same problem. The card is detected and I can change network settings and such in the Windows GUI, but it was no longer able to detect any networks. (Forgot to check whether the WiFi indicator light was on or off though.)
If I get it to work I will update this page.
Use xf86cfg to generate a template config. It should work - with native 1400x1050 resolution - more or less by default. The only complication for me was that X wanted to use /dev/sysmouse for the mouse, but the correct device was /dev/bpsm0. I had to take the config it generated by default and run XFree86 in configuration mode manually, telling it to use the modified configuration as the default (sorry, no longer remember the exact command) in order to have a working mouse in the configuration tool (I still haven't figured how to use the numlock key on this machine, so I needed the mouse :)).
Note: I had some semi-random hang problems when starting X; but that was all before I disabled the cardbus bridge (see em0/pcmcia notes) in the kernel. Do that first and X seems to work fine.
Also: There is supposedly 3D support for Radeon cards coming from the XFree86 project. I have not tested this yet, and I have no idea how well it works in general, and even less of an idea how well it works, if at all, with a Radeon Mobility 9000 on the T40p.
Update: I have been using the box for a while now, and I can report that I have had no stability problems - or performance problems - with X what so ever. It's working quite perfectly, including 3D - though in software. I still haven't tried to get accelerated graphics working.
UPDATE: Multiple programs can indeed output sound by using different sound devices. Modify hw.snd.maxautovchans and hw.snd.pcm0.vchans accordingly with sysctl and point different applications to /dev/dsp0.0, /dev/dsp0.1, etc...
No fuss whatsoever. Just add "device pcm" in the kernel configuration. I don't think this chipset supports hardware mixing, and as a result only one process can output sound at a time. If anyone knows of a way to get the driver to mix in software, feel free to let me know.
If you get a kernel trap when booting with the built-in bluetooth card enabled (Fn-F5), you probably haven't disabled the cardbus bridge (see em0/pcmcia notes). Do it.
The BT device sits on the USB bus, speaking a standard protocol. I used the procedure described hereto get it to work, with the following noteworthy exceptions:
Also when following those instructions, keep in mind that enabling Bluetooth with Fn-F5 is equivalent to plugging in the USB dongle for external Bluetooth interfaces.
After some initial trouble - the reason for which is still unclear to me - I have now gotten Dial-Up Networking over Bluetooth to work perfectly, according to the guide.
Haven't tried this one yet.
Ok, this is a hairy issue. It kind of works, but is pretty buggy. If you want it to work at all you need the cardbus bridge enabled (the one I disabled, see the em0 section for details) It's all a very long story, but he gist of it is:
Bottom line: I haven't gotten pcmcia to work at the same time as the gigabit ethernet card, and pcmcia seems to generallhy break things all over. With the cardbus bridge disabled, the orinocco card doesn't work even though it is not a Cardbus card (but an older PC Card).
UPDATE: Suspend/resume works, even with X, by following the instructions at http://www.cs.ucr.edu/~trep/tsrT40freebsd.html. Below is the old info for this section, about ACPI (which still does not work for me):
I get variuos ACPI warnings/errors during boot, but nothing fatal. apm reports battery statistics successfully. Suspend seems broken, but I have not investigated in detail. DJB said he disabled the apm support to get resume to work, but this has not worked for me. When I attempt to suspend, nothing happens except a complaint in the kernel log.
UPDATE: Ok, suspend at level 3 works, though resume is more difficult. When I resume after a level 3 suspend, the USB driver starts complaining and bails out completely after a few seconds. Also, from that point on the whole system feels quite slow and laggy as if it was under tremendous load. Typing characters in the console is not even lag free. Is there something in the kernel running amok?
Works, though I am now loading it as a module. (I removed it from the kernel config in my great kernel stripping mission when I wanted to make the gigabith ethernet card work. I suspect it works fine compiled into the kernel aswell, I just haven't tried it yet.)
The CD-ROM works without a problem, being a standard IDE device. At the time of this writing I have also burnt one CD with 'burncd' without difficulties.
I selected the extra ultra bay battery as an accessory. You can get some nice battery times with both batteries in the machine :) However, whenever I have the extra battery in the bay - instead of the CD-ROM - I am suffering from hangs during certain actions that I assume is causing or is the result of some form av acpi event or similar:
As a result, I am not currently using the extra battery in day-to-day operation, though its still nice to have handy if needed.