Kroon Information Systems CC: Howto: Toshiba Satellite P10-792 howto

This "howto" attempts to explain my experiences with a Toshiba Satellite P10-792 notebook. I'm using Gentoo Linux (Starting from the 2004.3 LiveCD, using stage 1) as that is the only distro which I currently even take under consideration due to it's total configurability (the only disadvantage being the time it takes to compile packages).

Hardware configuration

The specs of the notebook is as follows:

Mobile Pentium4, 3.06 GHz Processor.
512MB RAM.
60GB 4200rpm Hard drive.
15.4" screen with a 1280x800 resolution (weird ratio of 16:10).
ATI Mobility Radeon 9700 (64MB DDR VRAM, tv-out).
IEEE1394 Firewire.
SD card reader.
DVD Super-Multi Drive (DVD-RAM, DVD+-R/+-RW).
SRS TruSurround XT.
56K modem.
Integrated LAN.
Infrared.
3 * USB2.0 ports.

I would actually have prefered a nVidia card as their drivers are much better packaged (And according to a friend of mine someone has recently written a wrapper for their driver to allow for suspending) and in general gives less problems with regards to memory corruption et al.

Additionally I was initially a bit skeptical about the speed of the processor, being aware of the tremendous heat problems that seems to plague these processors, but seemingly Toshiba has done something to resolve this issue (after about an hour of compiling the temperature still feels really low)

Additionally the notebook does not have integrated wireless - which is not a requirement but it would have been nice to have

Hard drive partitioning

Here I have to admit that I go against all recommendation, I don't perform partitioning to the level I should be doing at all, I merely created a 20GB Windows partition (ntfs, might get dropped to 10GB later), a 100MB partition (ext2) on /boot, a 1G swap partition (I want to attempt the suspend stuff, for which I'll probably need a big swap partition if I understand the howto's correctly), the remainder is a huge reiserfs partition for mounting on /.

This results in the following partition table:

Disk /dev/hda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
   /dev/hda1   *           1        2550    20482843+   7  HPFS/NTFS
   /dev/hda2            2551        2563      104422+  83  Linux
   /dev/hda3            2564        2686      987997+  82  Linux swap
   /dev/hda4            2687        7296    37029825   83  Linux

Install order

I normally install Linux first, then Windows and then "rescue" the system by booting my LiveCD again and re-installing the boot-loader. In this case I did it the other way round.

What happened is that I had a 2004.1 LiveCD lying around and installed from that (downloading the 2004.3 stage1 archive). Unfortunately I did something wrong (or more likely - Windows has yet another bug) and when inserting the Windows CD and booting from it I got a black screen of death (no, not blue). It would just print that inspecting hardware message and then die. As "luck" would have it, the 2004.1 LiveCD seems to contain a reiserfs bug (I've had problems before), or the Windows black screen of death did more that just die (likely as I have booted the half-installed Gentoo). As a result of either of these two I lost some data on the reiser partition, at which point I decided it was an apt opportunity to execute

dd if=dev/zero of=/dev/hda bs=1M count=1

which effectively wiped the partition table and as it turns out Windows was now able to install (albeit without any networking support - how can one ship an OS nowadays without a raeltek driver on it?). This is actually quite good as it sommer provided opportunity to install SP2 without having to worry about getting hacked. Another anoying feature is that I was forced to create a second administrator account - what the hell? They say to create your user accounts and then the first one of those automatically becomes a "System Administrator".

Either way, after the initial hiccup the installation went without insident (other than me getting annoyed about insane defaults).

So it seems for a change I'm sticking to recomendations of installing Windows first. I still recommend using some other partitioning tool (such as linux fdisk) though.

UPDATE: It turns out the black screen of death is a bug in the Windows Installer. I've managed to reproduce it a few times now and every single time just wiping the first 512 bytes of the actual NTFS partition managed to solve it. It seems that Windows really isn't very resistant to corruption of the boot-record on it's partitions.

Bootstrapping Gentoo and installing the base system

This went without insident, the Gentoo installation guide is very thorough. I just had to explicitly unmerge linux-headers during the bootstrap process as the bootstrap process installed both linux26-headers and linux-headers. Since I'll be using a 2.6.x kernel I opted to unmerge linux-headers. Be warned, I've read the guide once, more than a year ago, so some of what I do may differ from the official guide, and in some cases I blatantly break away from it.

Since I have a desktop machine up and running, I set up gentoo-rsync-mirror on that and sync'ed against that, I also have DHCP up and running, so the net-setup was easy. My desktop also serve as a gentoo distfiles server using torpage and a choice of nfs, samba or ftp (vsftpd). Since the notebook will not always be connected to the network I've opted to go with ftp. While torpage is not yet running at this point in time I can already use my desktop (pug) as my first local ftp mirror.

My make.conf file looks as follows:

CFLAGS="-march=pentium4 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
PORTDIR_OVERLAY="/usr/local/portage"
USE="-oss -crypt -fortran -ipv6 -gnome -kde -nls -tcpd -perl -python -acl \
	-esd -arts -java -curl -tcltk -tetex X nptl nptlonly userlocales sse \
	sse2 mmx alsa readline ncurses pam qt dvd userlocales rtc apache2 berkdb dba"
PORTAGE_NICENESS="10"
#SYNC="rsync://ftp.is.co.za/gentoo-portage"
#SYNC="rsync://ftp.up.ac.za/gentoo-portage"
#SYNC="rsync://localhost/gentoo-portage"
SYNC="rsync://pug.lan/gentoo-portage"
#SYNC="rsync://rsync.rucus.ru.ac.za/gentoo-portage"

#FETCHCOMMAND="/usr/bin/wget --limit-rate=2K -t 5 --passive-ftp -P \${DISTDIR} \${URI}"
#RESUMECOMMAND="/usr/bin/wget --limit-rate=2K -c -t 5 --passive-ftp -P \${DISTDIR} \${URI}"
FETCHCOMMAND_TORPAGE="/usr/sbin/torpage_fetch \${URI} \${DISTDIR}"
RESUMECOMMAND_TORPAGE="/usr/sbin/torpage_fetch \${URI} \${DISTDIR}"
#FETCHCOMMAND="/bin/false"
#RESUMECOMMAND="/bin/false"

I maintain some of my own ebuilds, these will go into /usr/local/portage. The large number of SYNC lines is for when I'm not at home (even my desktop has moved around a bit - the localhost record is for those cases where I need to sync via ssh/squid tunnels due to firewall restrictions). The USE flags is set up to be rather minimalistic, the way I like it (I used to use -* but that gets a bit insane). You should attempt to keep this list as short as possible. Rather set flags for individual packages in /etc/portage/package.use. Additional mirrors is set in /etc/portage/mirrors, mine looks like:

local torpage:// ftp://ftp.rucus.ru.ac.za/pub/linux/gentoo/distfiles/ \
	ftp://ftp.up.ac.za/mirrors/gentoo.org/gentoo ftp://ftp.is.co.za/mirror/gentoo.org

After editing these files (using vim outside the chroot) it's time to emerge sync, which worked flawlesly. As mentioned the scripts/bootstrap.sh script broke once, a emerge -C linux-headers took care of that. emerge -u system went clean on the first install. The second time round I discovered that the libpam build process suffers from a concurrency issue (ie, it fails sometimes but not always when performing parallel builds). Issueing "MAKEOPTS="" emerge --resume" resolved this issue and build the rest of the base system without incident.

Configuring the kernel and booting

I have this bad habbit of doing this at least twice. Once to get a minimal system up and running and get off the LiveCD, and then from there bit by bit to get everything else working. Before I start configuring a kernel however I get myself some pciutils (emerge pciutils) and run some lspci, the output of which looks as follows:

00:00.0 Host bridge: ATI Technologies Inc RS300 Host Bridge (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge
00:13.0 USB Controller: ATI Technologies Inc OHCI USB Controller #1 (rev 01)
00:13.1 USB Controller: ATI Technologies Inc OHCI USB Controller #2 (rev 01)
00:13.2 USB Controller: ATI Technologies Inc EHCI USB Controller (rev 01)
00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 18)
00:14.1 IDE interface: ATI Technologies Inc ATI Dual Channel Bus Master PCI IDE Controller
00:14.3 ISA bridge: ATI Technologies Inc Unknown device 434c
00:14.4 PCI bridge: ATI Technologies Inc Unknown device 4342
00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller
00:14.6 Modem: ATI Technologies Inc IXP AC'97 Modem (rev 01)
01:05.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:04.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller
02:04.2 Class 0805: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller

When I installed there were lots of Unknown device's (the above list is on 2005/12/17 after a update-pciids). Needless to say, it took a while to figure out exactly which drivers I needed for what. At least the "hardware list" in the manuals on stickers and stuff in and around the box was relatively accurate.

The Mobility Radeon 9600 M10 is advertised as a 9700m on the box - wonder which one is correct.

Lots and lots of ATI stuff, this initially made me raise my eyebrows but it mostly turned out ok. And yes, the Raeltek card seems to be a genuine Raeltek, or a damn good clone for a change.

At this point in time I proceeded to rsync my local ebuilds via "rsync -rav rsync://pug.lan/gentoo-local /usr/local/portage" and emerged own-sources (A custom ebuild that pretends to install kernel sources but in fact does nothing). The reason for not running gentoo-sources or vanilla-sources is that I like running vanilla-sources but it almost always seems to be out of date, albeit I don't upgrade at every version, I'll for example run 2.6.9 for a long time and then jump to 2.6.12 or something. Currently I'm running a vanilla 2.6.14.2 on my notebook (config here - the only modules I actually load is autofs4 and pcspkr, every now and again I load ntfs).

A few things you should note:

Be sure to select P4.
DISABLE SMP.
Do not select "Toshiba extra's" - they don't work on this particular notebook.
MCE is good.
Local APIC is good.
The ACPI modules that work are as follows:
- AC Adapter.
- Battery.
- Button.
- Video (not particularly usefull though).
- Processor (but not thermal zone).
You must compile the USB driver modules into the kernel or the keyboard won't function at all.

I personally like disabling as much as possible, things I know I use all the time I compile into the kernel and maybe's or "not used often" I compile as modules. To this end I compile a rather monolithic kernel, you'll note that all the hardware should almost "just function" with the config above. Noteable exceptions are lm_sensors (does not function at all to the best of my knowledge) and the SD card reader (albeit - mine might be disfunctional since it doesn't work in Windows either).

At this point a boot loader is required, as is my preference, I merged lilo (and sommer vim at the same time) and the following config file does the job:

lba32
boot = /dev/hda
map = /boot/.map
prompt
delay=0
timeout=50
vga=791 # 1024x768 - need to figure out 1280x800 if possible :).
#append="hdc=scsi" #"video=vesafb:1280x800@75"
append="usb-handoff i8042.nomux"

root = /dev/hda4
read-only

image = /boot/vmlinuz
        label = Gentoo
        
other = /dev/hda1
        label = WindowsXP

image = /boot/vmlinuz.old
        label = Gentoo-old
        optional

image = /boot/vmlinuz-2.6.11.11
        label = Gen-2.6.11.11

Note the commented append - I used to use scsi-emulation for the DVD writer, and the video= part is a remnant from attempting to use TNG vesa to get fullscreen console.

Remember to edit /etc/fstab!!

Before the system can be booted it is required to install the reiserfs filesystem utilities, which a emerge reiserfsprogs solves easily enough. Now set the root password by issueing a passwd and we are ready to reboot. Hit ^D to exit out of the chroot, umount all mounted filesystems, issue a sync (to be on the safe side - I still don't trust the LiveCDs fully). Now do a reboot, removing the CD when the system reboots. Foila. Now log in and start hacking individual components in order to get everything working.

Base system services

At this point it's time to install a couple of base system services. I like syslog-ng and vixie-cron (emerge -av syslog-ng vixie-cron). After they have completed merging it is still required to add them to the default runlevel by issueing (and sommer starting them up too):

# rc-update add syslog-ng default
# rc-update add vixie-cron default
# /etc/init.d/syslog-ng start
# /etc/init.d/vixie-cron start

Some people consider slocate (for the locate command) part of the system too. I find that it tries to update it's db at the most inappropriate times (when battery is low). While it is certainly possibly to alter the cron job to only run if we are on AC, and have the ACPI system kill the update process should we lose AC this feels like way too much effort for a really negligible gain (I almost never use locate in any case).

Other packages which I consider indispensible include bind-tools, netkit-telnetd.

The LAN

The LAN was an easy enough game. lspci reports the following:

0000:02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Which makes it quite clear that we require the Realtek RTL-8139 driver. The RTL-8139C+ driver might work too but I have never had that specific driver work for me. Compiling it into the kernel works like a charm as "ifconfig -a" shows. There are two routes to follow, one can either add net.eth0 to the default runlevel (bad idea on a notebook), or one can use ifplugd. Initially I just added net.eth0 to the default runlevel, and left ifplugd for later (which I now use).

For those who's wondering what the issue is with just having net.eth0 in the default runlevel, imagine roaming about with a notebook (that is what it's for right?). So sometimes you are connected to a network where you need to have a 192.168.0.? IP address, other times you need to be in another IP range, and in some cases you are not attached to a network at all. And in some other cases there is no dhcp on the network your attaching to. ifplugd is a tool to at least help solve the long timeout that net.eth0 has, in addition to preventing network timeouts due to the physical connection not being there. I set up net.eth0 to use dhcp, it does not help in the cases where there is no dhcp on the network - in those cases a manual "ifconfig eth0 inet i.p.ad.dr" is still required.

The ifplugd package on gentoo has come a long way. The default configuration works on this notebook, so it boiled down to removing net.eth0 from the default runlevel, merging ifplugd and adding ifplugd to the default runlevel. Oh, I just had to edit /etc/conf.d/ifplugd to point to eth0 instead of the wlan0 device that was the default.

In addition to this I like to run synergy when I connect up at home, and at the office (most common places for me to sit down and work). For this reason I put the following in my /etc/conf.d/net file:

function postup() {
    Xuser="`who | awk '{ if($2==":0") print $1 }'`"
    [ "${Xuser}" != "" ] && su - "${Xuser}" -c "DISPLAY=:0 /usr/local/bin/setup_synergyc" &
}

function predown() {
    pidof synergyc >/dev/null && killall synergyc
}

With /usr/local/bin/setup_synergyc as follows:

#! /bin/bash

[ "`dnsip pug.lan. 2>/dev/null`" != "" ] && synergyc pug.lan. && exit $?
[ "`dnsip nix.cs.up.ac.za. 2>/dev/null`" != "" ] && ping -c2 -w1 nix.cs.up.ac.za. &>/dev/null && synergyc nix.cs.up.ac.za. && exit $?

exit 1

For this code to function you require the djbdns package. Actually any method to test on what network we are would have worked. And I actually just realised that checking the dnsdomainname might be more effective. This is for later investigation though.

To finish this off one is also required to call /usr/local/bin/setup_synergyc from ones window managers startup routine (~/.icewm/startup in my case) and to kill synergyc processes from the exit routine (~/.icewm/shutdown), although, synergyc does die along with the X server. All this just serves as an example of what could be done.

Xorg and ATI

Step number one is to get Xorg, a display manager (I like gdm) and a window managed (I like icewm). I like my backgrounds, so I merge icewm with imlib support by issueing:

# echo x11-wm/icewm imlib >> /etc/portage/package.use
# emerge -av xorg-x11 gdm icewm

gdm unfortunately pulls in an overly large portion of gnome, including some unwanted docbook stuff, but I'm not going to bother with fixing that.

At this point I managed to get Xorg up with a very basic xorg.conf file. This config file is supposed to have a working mouse (and it does work with an external USB mouse), but as explained below the touchpad gave me even more problems than the ATi graphics card.

At this point in time ati-drivers is working relatively nicely. It's preventing me from suspending or hibernating but I can live with that. Good news is that someone managed (apparantly) to make the nvidia drivers suspend by adding some extra hooks. I might attempt doing something similar for ati-drivers if I can get hold of the nvidia version. When initially I installed ati-drivers insisted on downgrading Xorg to 6.7.0 whilst 6.8.x has long since been released.

The fglrxconfig utility also failed to produce a working config file. Don't know what the status on that is at the moment but I took the ATI specific section from the produced config and hacked it into my config to produce a working config. This took a while to produce. Note that the card doesn't play particularly nice with mirroring and the like. So you'll probably want to note "MonitorLayout" parameter. The documentation that I didn't manage to find also sucks.

You should note that ati-drivers and the xtrap module does not function together. In particular it causes X to just segfault. This situation may have changed in the last few months but I somehow doubt it.

In summary: Next time round I'll be getting a nVidia graphics card thank you very much.

At least the newest ati-drivers works with newer kernels and also with Xorg 6.8.0, you should note however that rmmod'ing the fglrx module and modprobing a new one is catastrophical. REBOOT.

Sound

Right, so the real uphill battle has been won. To get sound working the first step is to merge alsa-utils (the kernel sources provides the actual alsa modules). From there on lspci comes in usefull again:

0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller

So compiling the appropriate module (PIC - ATI IXP AC97 Controller) into the kernel, rebooting, running "alsamixer" and then "/etc/init.d/alsasound save" gets us some sound. To make alsa load automatically issue "rc-update add alsasound default". The big problem I had was that I didn't realise there was a volume knob on the front of the notebook that was turned down all the way - talk about brain dead.

You also want the ati-ixp-modem module for later use for the modem.

The touchpad

The touchpad was a bugger. I finally managed to get it working. The touchpad it turns out is seriously broken in it's ACPI implementation. It works under Windows (had to load extra drivers), it works under the 2.4 kernel (doesn't use ACPI to do detection) and it breaks under the 2.6 kernel (uses ACPI).

I don't want to run a 2.4 kernel, I want to run a 2.6 kernel. In short, I used to run a custom hack (below for historical purposes) to make it work. Whilst it didn't do the right thing (tm) it worked. It slowed down all I/O to and from the touchpad but it made it work. You'll note that in my lilo.conf file above I pass usb-handoff and i8042.nomux to the kernel. The combination of these two options make the touchpad work correctly without any custom patches to the kernel. Previously I had 2 possible workarounds:

boot with acpi=off (not really an option on this particular notebook).
Use the following patch (which simply ignores the erronous error code).

Due to this I'm upgrading my kernel to 2.6.11-rc1 (came out just about a week back).

The patch for kernels <= 2.6.10:

--- linux-2.6.10/drivers/input/serio/i8042.c    2004-12-24 23:33:52.000000000 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c    2005-01-24 21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
  */
 
                if (i8042_command(&param, I8042_CMD_AUX_TEST)
-                       || (param && param != 0xfa && param != 0xff))
+                       || (param && param != 0xfa  && param != 0xa5 && param != 0xff))
                                return -1;
        }

My sincere thanks to Sebastian Piechocki who pointed me towards the solution, pointing out that his touchpad worked with acpi=off, as well as pointing towards the i8042 module. Turns out the kernel guys made a rather big change to the existing i8042 driver between kernel versions 2.6.10 and 2.6.11-rc1, these changes seems to be ACPI related for the most part, but they don't resolve the detection issue (unfortunately), so simply passing i8042.noacpi=1 to the kernel does not help as I had hoped.

UPDATE: After various emails on the kernel mailing list between myself and various big names the conclusion was made that the ACPI/SMM implementation on the BIOS is bust. A firmware upgrade may fix this later on but for now the best solution is probably the patch above. The problem is that the return value is delayed by one command, ie, we issue a loop test, it times out, we issue the aux test and that returns the result expected for the loop test.

The touchpad itself serves up an ALPS protocol. Not sure yet whether synaptics will run on that, I'll update again as soon as I know how to get the most out of this touchpad under X.

UPDATE (April 3, 2005): New updated patch to the i8042 driver which makes the whole ALPS thing work properly. I've even managed to get synaptics working on it, gpm can't seem to get tapping right (the ALPS driver disables hardware tapping - this might be a problem), and nothing seems to get multi-finger detection right. I don't see any reference to multi-finger stuff in the ALPS kernel driver, so it might be that the driver doesn't support it yet, or that the protocol doesn't support it. Either way, the patch (built against kernel 2.6.11.6) is available here.

If you care what the problem is, here is the short version: Somewhere along the line the response on queries to the i8042 gets buffered incorrectly, this causes the first query to wait indefinately for a response (or timeout). This just happens to be the AUX_LOOP test. All consecutive queries get the previous queries response. I call the "delayed response bug". Anyway, the fix is to issue queries twice and chuck away any output that the device provides between the two commands.

Suspend/Resume

Is finally working. It took me a week of hard hacking on this one, including spending many hours reading kernel sources and stack traces and being pointed to various docs. Thanks for the help of a few individuals around the world who helped me out on this one, especially Pavel Machek.

The short version: Initially the screen wouldn't come back up. So I got nothing. But I was able to make it go away using /sys/power/state (echo'ing "mem" into it). I tried using suspend2 and will probably try that again at some point but for now good old swsusp is working.

First off, I'm still running a vanilla kernel, no patches. I initially got this working with 2.6.15-rc6 but later back-ported to 2.6.14.3 for the sake of fglrx which I later found need this patch to work with 2.6.15 and up kernels.

I actually got suspend-to-ram working before suspend-to-disk, but both turned out to work rather nicely in the end. And in fact, if you are using ati-drivers you can (so far as I managed to determine up to now) only suspend-to-disk. You should note that the following kernel options are of critical importance (both under General Settings):

Local APIC: on
IO-APIC: off

And obviously you need to enable Software Suspend under Power Management. Kernel parameters to pass is simply resume=/dev/hda3 (where you need to replace hda3 with your swap partition), as well as acpi_sleep=s3_bios,s3_mode. This enables a few kludges to make the video come back on. It may be that it's the acpi_sleep parameters that is breaking the ati-drivers on suspend-to-ram though.

That should be it. I actually suggest not using hibernate (the package recommended by everyone to perform suspend/resume) but to rather hack your own scripts. For the moment I don't have any written but I might later. For the moment a simple echo command does the job:

echo mem > /sys/power/state
suspends to RAM. Breaks in some cases with ati-drivers.
echo disk > /sys/power/state
suspends to DISK (swap, actually). This works nicely.

Note, in order to allow suspend-to-ram to function you may require a patch in the kernel. This applies if you are using the kernel-provided agpgart modules instead of the fglrx provided driver. The patch basically adds suspend/resume support, and can be found here. If you are not using an ATi AGP bus you may need to patch the appropriate agpgart module in a similar fashion. There seems to be patches for i845 and via available here. You need these if you can suspend/resume fine from a console but as soon as you switch back to X it crashes (hard-lockup). I've also got a (as yet untested) version for nvidia-agp - please let me know whether this works.

The omnibook module

You should note that the ACPI implementation on this notebook is badly broken though. I suggest loading the omnibook module (emerge -av omnibook) to at least obtain console blanking (well, omnibook switches off the screen when it gets blanked) and be able to read the CPU temperature. This mainly provides you with some minor enhancements, and is probably not crucial but most deffinately very nice to have.

The Modem

Works with slmodem. Simply load the snd-atiixp-modem module, install slmodem and start it up. It sometimes locks up when trying to dial (reporting no dialtone or something equally silly), just retry and it should work. Failing that, restart the slmodem daemon. Note that since this is actually a soundcard all modulation/demodulation happens in software on the CPU. Thus on an extremely busy system it is possible that you may drop connections. It may help to adjust the niceness value of the slmodem daemon to a smaller (-10 should be good) value.

IEEE 1394 (Firewire)

The modules load and the devices gets created. Unfortunately I have no devices to test with, so it'll probably stay "unknown" for at least a while longer.

According to Antonis Tsolomitis (via private email) the Firewire just works:
I went quickly over this howto to get an idea. Just to mention that firewire works immediatelly. I have been using my camcorder with kino to transfer from tapes to digital files many many times. It works fine.

CardBus/pcmcia

Loading the pcmcia module and the yenta module provides you with a working cardbus. I've managed to run a "Xircom CreditCard Ethernet 10/100+ Modem56" from it, as well as a "Dell TrueMobile" wireless card.

My suspicion is that the SD card reader connects to the system via the cardbus subsystem (based on the device numbers in lspci - not confirmed though - since they only differ in function number).

SD card reader

This used to be an unknown device in lspci but it got added recently. There is some support for SD cards in the the 2.6.x series kernels but as of yet I haven't managed to make it work. There is essentially a single module for a winbond-based SD card, and dmesg reports the following (Causing me to suspect that it won't be working in Linux any time soon):

wbsd: Winbond W83L51xD SD/MMC card interface driver, 1.0
wbsd: Copyright(c) Pierre Ossman
wbsd: Unknown hardware (id ec11) found at 4e
wbsd: Unknown hardware (id ec11) found at 4e

I suspect this means something like, I managed to locate your SD card reader but I don't know much about it.

DVD-Writer

cdrtools does a great job, using either scsi emulation or the atapi interface. I've read an extremely interresting kernel thread the other day with regards to cdrecord and it's claims that the kernel is broken. It seems most of the warning messages that cdrecord spits out with regards to priority and DMA is just about all FUD. In fact, apparantly there is full DMA going there, and the priority will only make a difference on a loaded system. The issue with regards to why burnfree isn't the default was also raised. Will post a link if I can locate it again.

For recording onto dvds I recommend using the dvd+rw-tools package. It works wonders and seems stable enough. No kernel patching is required for the 2.6.x kernel whatsoever.

Non-functioning hardware

SD card reader - have tried, no success.
IEEE1394 (FireWire) - should work in theory but I have no way to test it.
The three buttons on the right edge of the notebook.
InfraRed - Haven't tried, no way to test.

Conclusion

All in all a very nice notebook. The only real issue imho is the graphics driver. This is probably largely due to personal viewpoint, see my ATi vs nVidia rant. Next time round I'll be sure to get a nVidia graphics card, preferably on a Centrino-based system, or possibly an AMD64-based system.