The K-Zone: Running Linux on the Sony Vaio PCG-FX802

Overview

Updated December 2003: I am currently running RedHat 9, with kernel upgraded to 2.4.23, on this laptop
This article describes the installation and configuration of Linux on the Sony Vaio PCG-FX802 laptop computer. I started with a RedHat 7.2 distribution, and later moved on to RedHat 9. However, with both versions it was necessary to recompile the kernel to get a basically useable system, and to get full support for all features it was necessary to replace the RedHat kernel with a more up-to-date stock kernel. The Vaio would be a bad choice to run Linux on, if you are looking for something that will run a standard Linux distribution out of the box.

The machine

When I originally wrote this article (October 2002) the Vaio PCG-FX802 was the latest model in Sony's range. Although Sony calls it a `laptop', it is really something between a laptop and a desktop workstation. The screen and the keyboard are both huge by laptop standards, and the whole machine is fairly big and heavy. This means that it can be used effectively as a desktop computer, but it's kind of portable if it needs to be. You wouldn't want to carry it under your arm for too long, however.
In summary, the FX802's features include: In short, the features would do justice to a desktop machine. I paid about £1000 for mine (from Comet, better-known for kitchen appliances) which seems a bargain for this set of features. Under Linux, the machine has a `bogomips' speed of 2595, which is about five times faster than my previous laptop, a Dell Lattitute CS. However, there is one unaccountable omission: no infra-red port.

Disk

The FX802 has a 30 Gb disk, which is supplied formatted with four partitions. The first of these contains something called `Windows XP' -- whatever the hell that is -- and the others are empty. I can see no reason why you shouldn't retain the Windows partition and install Linux on the others, but I'm never going to use Windows so I repartitioned the whole disk. I will, of course, be asking the supplier to refund the cost of the unused Windows software, but I don't suppose I'll get very far.

Video

The display supports 1024x768 in 16 or 24 bpp depth; it may support other resolutions and/or depths but I haven't tried. The video controller is an ATI Rage Mobility (a Mach64 variant) on the AGP bus, with 8Mb RAM. It was supported out-of-the-box by the version of XFree86 distributed with RedHat 7.2, but some tweaking was necessary to get the XV extension working. In particular, it was necessary to install the driver from the GATOS project, in place of the supplied driver. XV is what you need to get hardware scaling of image regions; with XV enabled, you can play a DVD in full-screen mode without any perceptible loss of frames. Without it, you'll have to watch in less than full-screen, or use software scaling (slow).
      XFree86 4.3 has drivers that directly support XV on the Vaio, making setup a triviality with RedHat 9.
      A bigger problem is getting direct rendering support (`3D acceleration') to work. Direct rendering is required by most games and simulation programs. I won't bore you with the details here; suffice it to say that it can be made to work. What's more, it can be made to work without disabling XV support, but it's tricky. If you need to get direct rendering to work, and can't, e-mail me for more information.

CD/DVD

The Vaio range is available with various types of CD-ROM, CD-RW and DVD drive. The FX802 has a `combination drive' that includes CD-ROM (24x), CD-RW (8x) and DVD (8x) functionality. This is very convenient, and saves carrying around a separate CD-RW unit if you frequently record CDs. A specific CD-ROM drive would probably offer a higher read spead than the combination drive, but in my view the additional convenience of the combination drive offsets this.

Playing video DVDs is straightforward using ogle; they appear to play at the full frame rate without any additional hardware acceleration (beyond what is provided by the XV support in the XFree86 drivers). Again, other players may work, but I haven't tried. I have seen reports that there are problems with switching regions using the DVD drive; all I can say is that there does not seem to be a problem with ogle, and I can play region-1 and region-2 DVDs interchangeably. I suspect that the region-switching limitation applies to software that uses the DVD's own firmware to decrypt the data stream; it may be that this firmware can only be reconfigured a limited number of times. Ogle does not decrypt DVDs; it uses the libdvdcss library to do this. Since this library does everything in software, there should be no regionalization problems. Please call me if you know more about this than I do, and think I'm talking nonsense. Note: using software decryption like this is of dubious legality. In the UK, it's probably OK, and in any event it's unlikely that the secret police will break down your front door with rifle butts in the middle of the night even if it isn't. But if you live somewhere more oppressive, don't say I didn't warn you.

Writing CDs works without problems using the cdrecord utility. This expects to see SCSI devices, not IDE, so you will need to simulate a SCSI interface to the IDE CD drive. This is straightforward: just load the ide_scsi module. If you run cdrecord -scanbus, it should show the CD-RW as device `0,0,0'. If it gets that far, it's probably going to work. The RedHat 7.2 installation set up the kernel to load this module automatically, so no great effort was required.

Modem

The FX802, like many Vaio models, has an integrated software modem. It's based on the same AC97 chipset that provides sound output, etc., and is not a full modem implementation. In other words, it does not provide a serial interface. On the other hand, it isn't a `winmodem'; the hardware does have some brains. You will need a driver, available here. I don't use a modem, so I can't comment on whether it works or not.

USB

The Redhat 7.2 and 9 installers both configured the low-level USB hardware correctly without any help. I use USB for four things: my digital camera, an external backup disk, my USB bluetooth dongle, and my portable MP3 player. All work fine, with a bit of tweaking. The first two - the camera and the external disk - are straightfoward bulk-storage devices, that is, they appear as disks. The are supported by the standard usb-storage driver in all modern Linux kernels. Bluetooth was more of a problem, but not a problem specific to the Vaio, so I won't go into it here. I previously had a Creative Labs Nomad MP3 jukebox, but its use of a proprietary USB protocol was a constant nuisance. I've now got an Archos, which uses the standard USB bulk storage protocols, and this works perfectly.

sound

The sound device is integrated: part of the AC97 chipset. It is supported by the via82cxxx_audio driver, which is part of the standard OSS audio distribution. The RedHat installation process detected and configured the driver automatically. There have been reports that the ALSA audio drivers also support this device.

There are two small problems with the standard driver. First, it does not survive a suspend-to-disk operation (see below). This can be fixed simply by removing the driver and reloading it after waking the machine. Second, it does occasionally resort to refusing to support any sampling rate apart from 48 kHz. I don't know why it does this, but cure is the same.

The speakers on the FX802 are larger than usual, and not too bad to listen to (compared to the competition).

TV out

The FX802 is unusual in having a composite video output, which can be used with most modern televisions or video recorders. I haven't tried it, but I have seen that it works under Linux on similar Sony laptops, so I'm reasonably confident. The output is a 3.5 mm jack next to the audio output, and a (too) short cable is included with the laptop.

FireWire

FireWire support is included in 2.4.x kernels, including drivers for common hardware. However, the first kernel with reliable support is 2.4.18. RedHat 7.2 is supplied with kernel 2.4.7, which will probably need to be patched to get FireWire to work. RedHat 9 is supplied with 2.4.18, and FireWire support worked out-of-the-box. I have successfully used the FireWire video driver to transfer video from my camcorder, but I had to buy a (very expensive) FireWire cable -- not is supplied with the laptop.

Ethernet

The built-in ethernet adapter is based on the RTL-8139 chip; a driver was configured automatically by the RedHat installer and it worked straight off, both at 10 Mbits/sec and 100 MBits/sec.

Power management

This is where things start to get tricky. The FX802 has problems in this respect, just as most Sony laptops seem to. Let me say at the outset that, at present, I have fan control and suspend-to-disk working. Suspend-to-RAM has worked exactly once, and I can't replicate it (see below). Suspend-to-disk takes about 15 seconds to shut down, and about 45 seconds to start up, which isn't too bad.

Background

To see why there are problems, let's start with some background information. Laptops need power management for two main purposes: to control the fan and CPU speed, and to provide low-power standy modes. The former is important because we need to maintain a good compromize between CPU temperature and fan noise. If the computer is very busy, the CPU needs to run at full speed, which makes it warm up, which means that the fan needs to be running at high speed. When the computer is idle, the CPU can be declocked and the fan turned off. Standby facilities are important in laptops because we expect to be able to work intermittently, without needing to either drain the battery or shut down the machine fully.

There are two main power management strategies in use in the PC world. `APM', the earliest technique, is fairly primitive. It assumes that, on the whole, it is the PC hardware that will do most of the work. The operating system is responsible for telling the APM hardware what is going on, and for notifying peripherals of a change in power state. It isn't all that difficult to implement APM support in an operating system, and it has been well-supported in Linux for some years. The problem is that not all manufacturers implement APM support properly in hardware, and the operating system vendor is left to make good the deficiency. For a system like Linux, which is developed mostly by volunteers, this isn't ideal: it is not easy to compensate for the problems imposed by the various manufacturers. Nevertheless, a PC that complies fully with the APM specification will work properly with any modern Linux kernel. My old Dell laptop worked flawlessly.

The more modern system, `ACPI', is much more sophisticated. It relies on the operating system to do a much larger share of the work. ACPI support is relatively new in Linux.

Over the last couple of years, laptop vendors have been moving away from APM to ACPI. It appears that Sony made a move to abandon APM altogether in some of its models. More recently, support has resumed, perhaps because ACPI implementations in popular operating systems (for which, read `Windows') were inadequate. Whatever the reason, the FX802 has only vestigial APM support, and expects the operating system to use ACPI.

So, the situation at present is this: the FX802 has a partial APM implementation, but it does not seem to be one that Linux can use reliably. Linux can use APM to power off the machine, and there seems to be rudimentary fan control. However, suspend-to-RAM does not seem to work. I tried with various kernel versions, even to the extent of compiling out all hardware support apart from that needed to get the machine to boot. It worked exactly once. On all other occasions the machine would suspend but not resume. In any case, with APM the fan control is barely adequate: the fan runs all the time, at low speed. There have been reports of Vaio laptops going into thermal shutdown because of overheating. Although it would probably be possible to use suspend-to-disk (see below) with APM, that lack of proper fan control seems to suggest that ACPI would be a better bet.

Enabling ACPI support

ACPI support has existed in Linux kernels for some time, but it is only relatively recently that it has worked properly. In any case, it is not enabled by default in any Linux distribution, so you will have to recompile the kernel. Now you could recompile the kernel that comes with RedHat 7.2 (2.4.7) or 9 (2.4.18) but it's doubtful that the ACPI support in these kernel versions would work properly. The ACPI project at SourceForge has kernel patches that can be applied to the 2.4.18 kernel, and I found these to work reasonably well. However, if you're going to be compiling and installing a new kernel, you may as well get a more recent version. I am currently using the stock 2.4.23 kernel. The ACPI support works in this kernel without patches, to the extent that the fan seems to switch on and off, and the temperature and battery life readings seem to be sensible.

This is not the place to describe how to compile a kernel. The only thing that I will point out is that you need to find the power management settings, and ensure that `APM' is turned off, and `ACPI' is turned on. I found that the ACPI support in kernel 2.6.0 also worked without patches, but suspend-to-disk (see below) did not.

If ACPI support is working, then you should find a set of kernel interface pseudo-files under /proc/acpi. You can get the current battery status by running 

cat /proc/acpi/battery/BAT1/state
and the temperature by doing 
cat /proc/acpi/thermal_zone/THRM/temperature
I find that in light use the fan comes on for about 5 seconds every minute or so. Under heavy load, however, it can generate quite a blast. When the laptop is relatively lightly loaded, the temperature seems to hover around 50 degrees Celcius, which seems quite healthy for a laptop. Under very heavy loads it has gone as high as 70 degrees; I'm not sure if that's healthy or not, but it doesn't seem to do any harm. I've decided that I can more readily afford to replace a burned-out CPU than I can afford to spend any more time worrying about it.

So we seem to have proper fan control, but after all this effort I was annoyed to find that suspend-to-RAM still did not work. However, suspend-to-disk does work, with the appropriate kernel patches, as described below.

Suspend to disk

At present, I don't think that any stock 2.4.x kernel has suspend-to-disk support included; it remains the province of a kernel patch called swsusp, which you can get here. I found that suspend-to-disk worked, with the appropriate swsusp, for kernel version 2.4.17. It didn't work, despite strenuous efforts, for 2.4.18 (which is the standard RedHat 9 kernel), or any other kernel until 2.4.23. Suspend-to-disk is included in the stock 2.6.0 kernels. In fact, there are two different versions in the source. Neither worked for me. So, I think that the two kernels that are useable with the Vaio are 2.4.17 and 2.4.23. If you have anything else, you could be flogging a dead horse. However, there are many different versions of the swsusp patch, for many different kernels, and it's just possible that you'll find some other combination that works.
      The swsusp patch has recently undergone a substantial revision, and is now distributed as version 2.0. This version requires substantially different configuration to previous versions, which I won't describe here.
      This isn't the place to describe the process of patching and recompiling a kernel. In brief, the swsusp 2.0 patch comes in two parts - a generic part (which is applied first), and then a kernel-specific part. After applying these two patches, you'll find that the kernel configuration program shows an additional entry for suspend-to-disk. So all that's necessary is to select that option and recompile. If you are using a kernel version before 2.4.23, things are likely to be awkward. You'll have to patch the kernel to get ACPI support to work, and then you'll be applying the swsusp patch to a kernel that is no longer clean. You can spend some time going through the patch to make it work with the modified kernel, or you can download patched versions of the swsusp patch which might apply cleanly. When it starts to be necessary to apply patches to your patches, this generally means you're in for a hard time. I managed to get this process to work for 2.4.17, but it's unnecessary in 2.4.23, which has to make it a better bet.
      When you've got the modified kernel compiled, you need to tell it at boot time the location of a partition to be used to store an image of the machine state. The kernel will write to this partition before shutting down. Then, when it starts up again it will detect the suspend data in the partition, and reload the machine state rather than going through a complete boot process. The partition is specified as a kernel parameter called resume2. You need to add this parameter to lilo.conf or grub.conf, depending on which boot loader you are using: 
resume2=swap:/dev/hdXXX
It is standard procedure to have the suspend-to-disk patch use a swap partition for its data. This can be a standard system swap partition, provided it is big enough (twice as big as RAM is probably enough).

If the patch is working, then you'll notice a new /proc directory: /proc/swsusp. You can control the suspend process by writing data to the files in this directory; however, since you will probably have enabled ACPI support, you need to control the suspend through ACPI (see below).

Linking ACPI and suspend-to-disk

If you have been used to using APM with Linux on a laptop, you've probably found that your system's suspend key or power button can be used to initiate a suspend. You may be surprised to find that ACPI does not deal with this itself. If you want a suspend to be intiated when, say, you close the lid or press the power button, you'll need some additional software. You'll also need this software to put the machine to sleep when the battery level gets too low to carry on working. Otherwise, you'll find that it just stops dead.

The ACPI drivers do make available information about which power management controls have been operated, so you don't need any additional kernel drivers for this: you simply need a daemon that can read the files in /proc/acpi/buttons and /proc/acpi/battery and determine what to do. There is a program called apcid that can do this. There are various versions, and all will need to be tweaked to do what you want. Personally, I'm not bothered with that level of sophistication. I have written a script that I run whenever I want to shut down. This script unloads troublesome kernel modules, then writes the number `4' to /proc/acpi/sleep. Later versions of swsusp also provide a suitable script.

Outstanding ACPI problems

There are a few outstanding power management problems, apart from the obvious one of the complete lack of suspend-to-RAM.

First, I have found that suspend-to-disk works fine from within the X environment, and it works fine from the text console. However, what doesn't seem to work is suspending and resuming from the text console and then starting X: the keyboard locks up. I don't know why this is. There are reports that resetting the typematic rate on the keyboard after a wakeup (in a script -- you can't do it from the keyboard, because the keyboard is dead) fixes this problem, but it didn't for me. If you work exclusively from the graphical environment, this is unlikely to bother you.

Second, some drivers do not survive a suspend. On my system, the sound drivers and the USB drivers do not resume correctly. This is simple to fix: just have the `suspend' script unload those drivers before suspending, and reload them afterwards. Some experimentation may be required to determine which drivers are affected. Many people have reported the PCMCIA cards need to be ejected (in software) before a suspend.

Third, the standard Gnome and KDE battery level applets read from APM, not from ACPI. This means that you don't get a battery level indication on the GUI, nor a graphical alert when the power is low. This can be quite disconcerting: the laptop will just shut down without warning. There are two basic ways to sort this out. First, you can use a Gnome applet that does support ACPI. There is one called power-applet, available from here, which has some ACPI support. It can display the battery charge level, time remaining, and pop up warnings about low charge. This applet looks very nice but, unfortunately, the current version -- which appears to be 0.5 -- does not support the latest ACPI drivers. This is because the names of the files that appear in the /proc directory, and the format of their contents, has changed recently. I therefore had to make some modifications to the source code and recompile it. I am reluctant to make the modified version available, because I can't be sure it will work on anyone else's computer. However, if you would like to try it please feel free to get in touch and I'll send you the modified executable or source.
      The second approach is to use something that `simulates' the APM system, by providing a dummy output from /proc/apm based on the values provided by ACPI. This seems a straightforward enough job, but it is not part of the standard ACPI patch. I have written a loadable kernel module to do this for; it's called acpi-apm and is available from the Linux download page. If you look very closely at the photo at the top of this page, in the bottom-right corner of the screen you'll see the standard Gnome battery monitor. This only uses APM, so this shows that the module is working. There are two versions of the acpi-apm module -- the original that mostly worked only with 2.4.17 and earlier kernels, and the new version 2.0, which should work on kernels 2.4.18 and later (tested on 2.4.23).

Odds and sods

Athlon support

If you are compiling a kernel for this laptop, don't forget that it has an AMD Athlon processor, and you need to configure this in. Otherwise the kernel won't boot at all.

IDE DMA support

You need DMA support for your hard disk -- it isn't really optional if you want decent performance. In addition, if you are using suspend-to-disk, shutting down and waking up are hugely faster with DMA enabled. To find out if DMA is working, do 
# /sbin/hdparm -d /dev/hda
If the result is `0', DMA is not enabled. To enable it: 
# /sbin/hdparm -d 1 /dev/hda
If this gives the message `operation not supported', most likely DMA support for the IDE hardware is not compiled into the kernel. This isn't a problem with RedHat distributions, but if you are installing a later kernel, be aware that there was a change in the IDE DMA architecture between versions 2.4.22 and 2.4.23. In particular, DMA support has been moved to lower-level chipset drivers. Therefore, to get disk DMA support you'll need to enable the kernel support for the IDE chipset. In the kernel source's .config file, make sure you have this line: 
CONFIG_BLK_DEV_VIA82CXXX=y

2.6 kernels

I have tried the 2.6.0 FCS kernel and it works fine. You need to pay the same attention to configuration as for later 2.4 kernels, but everything in the kernel seems to work. However, some software that I use doesn't work with the 2.6.0 kernel. In particular, the Mach64 video driver that has direct rendering support does not work. Also, as discussed above, neither version of suspend-to-disk provided with 2.6.0 worked for me. So, for the time being, I'm not using 2.6.0 on a day-to-day basis.

Summary

Almost all the features of the Vaio FX802 are supported by RedHat Linux 9 with no manual intervention. The one significant feature that is not supported -- power management -- is perhaps one of the most important to a laptop user. With a bit of effort this can be made to work -- fan control, suspend-to-disk, and battery level indication are now all working fine; it did take a couple of evenings of tweaking to get to this position, however.
©1994-2006 Kevin Boone, all rights reserved