Updated Dell D600 tips for Linux
There used to be a page here with (mostly) an account of how to get ACPI suspend-to-ram working on the Dell D600. While the page is still accessible here, please stop relying on the information it contains, since it is outdated. Things have become way simpler recently.
I'm not a support service. I give out the information I have, and point you to the places where I found hints on it. When I claim that I don't know something, I mean it. Don't email me to ask.
If you follow the steps described here, you will have suspend-to-ram (also known as S3) working under linux for your Dell D600 laptop. This is handy, since the machines consumes something like 1W when suspended, to be compared to 20W when running.
Former versions of this page implied patching XFree86, which is no longer needed. You'll only need to build a custom kernel.
As a general fact not concerning D600s specifically, Suspend-to-ram sometimes work, yet some or many devices crash on suspend, or never wake up on resume. The most annoying of these crashes being the graphics card, of course. With the patches included here, all devices resume ok after a stanby. This includes notably:
If you've been using (or trying to use) S3 for a while, you'll notice that this is a very good result. I am not enjoying 100% reliability yet (sometimes the machine crashes on resume) but it is pretty close.
Some userland software tweaking is also necessary (scripts, silly fixes...).
Install the Fedora Core 2 distribution. You may be an addict of some other distribution, I don't mind. But I'm not giving a definitive account of what is needed to make each and every distribution work. The steps I describe are those required with FC2 (brought up to date with the patches up to 20040813). For other distributions, you mileage may vary.
Grab the sources for the kernel. I used linux-2.6.8.1.tar.bz2, which you can grab from basically any kernel.org mirror.
NOTE : You may also manage to use your distro-provided kernel sources, but this is trickier. It's OK for 2.6.6-1.435.2.3, but for 2.6.7-1.494.2.2, I've encountered a few annoying difficulties.
You'll also need a handful of patches and scripts (see next).
Impatient user: patch_collection.tgz should
contain everything.
Here are the required patches I recommend for your kernel.
Only the first two are really important.
Additionally, you will need :
Obviously you'll need the usual tools as well (bzip2, patch), and gcc of course.
Additional things you may want to download are related to bringing to life some of the proprietary hardware on the machine. More specifically:
Dell TrueMobile 1300works with ndiswrapper ; here is ndiswrapper-0.11.tar.gz (included in the big tar file patch_collection.tgz).
Say you've
elected ~/Local/kernel for holding all the required
stuff concerning the kernel (patches, archive, build tree and so on).
Follow these steps.
cd ~/Local/kernel tar xjf linux-2.6.8.1.tar.bz2 mv linux-2.6.8.1 linux
Apply all the patches I've listed:
bzip2 -dc acpi-20040715-2.6.8.diff.bz2 | patch -p1 -d linux gzip -dc radeonfb.patch.gz | patch -p1 -d linux gzip -dc function_keys_kernel.patch.gz | patch -p1 -d linux bzip2 -dc font-lux16m.patch.bz2 | patch -p1 -d linux
Note: These patches might not apply immediately. If you're the
cautious kind of person, you'll first do things such as gzip -dc
radeonfb.patch.gz | patch -p1 --dry-run -d linux to
see first if everything applies OK, and afterwards for real, without the
--dry-run option. This allows you to resolve the differences
by hand inbetween if conflicts show up. Don't trust anything that doesn't
patch well. If you're trying to build from a kernel source tarball
more recent than 2.6.8.1, try to fetch more recent versions of the
patches.
IMPORTANT NOTE (20040823): There is a critical bug in the 2.6.8.1 kernel. This bug is going to bite you if you try to burn audio CDs (no joke). The purported fix requires applying these two patches: patch1, patch2. Kernel 2.6.9 fixes this.
Import the config file for your running kernel:
cp /lib/modules/`uname -r`/build/.config linux/
Configure the thing:
cd linux/ make menuconfig
You have to check/uncheck the following options. Explanations come later in the details section in case you wonder why I suggest these choices:
Build the kernel and modules.
make bzImage modules
Install the kernel and modules. You will need to do this as root. This won't erase anything of your existing configuration.
make modules_install install
If you're lucky, make install has been successful in
updating your grub configuration and initrd. It's not a bad idea to
check, though. You'll need to update the kernel command line. I have in
my grub.conf:
kernel /vmlinuz-2.6.8.1 root=LABEL=/ video=vesafb:off video=radeonfb fbcon=font:lux16m
It's also smart to check that the initrd has everything it needs:
gzip -dc /boot/initrd-2.6.8.1.img > /tmp/fs echo "ls -l /lib" | debugfs /tmp/fs
It is expected that jbd.o and ext3.o belong
to the list of modules included. If they don't, then your initrd is
screwed up and you'd better fix it (cf. man mkinitrd) before
trying to boot your new kernel (but make sure you have the proper
modutils and mkinitrd packages first).
Last stuff for activating the high-resolution console font at bootup:
cp lux16m.psf.gz /lib/kbd/consolefonts/ echo 'SYSFONT="lux16m"' >>/etc/sysconfig/i18n
At this point, you may reboot your machine, it shouldn't crash. At least I hope it won't. It's time to set up acpid so that it uses the proper scripts. I suggest you use my scripts, but many other reasonable scripts would do. Just don't blindly use scripts that are not suited to your hardware. If you can't read nor write trivial shell/perl, get someone to help you.
To hook my scripts into acpid, you need to do the following (as root,
from the same ~/Local/kernel directory as the rest):
mv /etc/acpi/events /etc/acpi/events.old (cd /etc/acpi/events ; tar xzf -) < acpi_events.tgz mkdir -p /etc/acpi/actions tar xzf radeontool-1.0.tar.gz gcc -o radeontool -O -Wall radeontool.c cp -p acpi_handler.pl radeontool /etc/acpi/actions/ chmod 755 /etc/acpi/actions/* /sbin/chkconfig --add acpid /sbin/service acpid stop /sbin/service acpid start
Your machine is now supposed to be able to power down cleanly, and do so
when you press the power button as well. If you press the power button
for more than 5 seconds, then the machine powers down as in the good old
days, without any OS notification.
As for suspend-to-ram, this should already be almost functional too, but
there's a major cause for random bugs that must be evicted:
updfstab. Therefore you should do, as root (still from the same
directory ~/Local/kernel where all the tiny files have landed):
mv /usr/sbin/updfstab /usr/sbin/updfstab.orig cp updfstab /usr/sbin/updfstab
Now you can try to suspend-to-ram by closing the lid (for debugging, just press the lid button, it's easier). The machine should spring back to life when you open the lid again (or release the lid button). This should work either from X11 or from the console.
Here are extremely quick notes about the why and how...
The radeonfb patch does a real-mode call to the video bios, so that the radeon performs the necesssary resume code when returning from sleep. This is done from within the kernel, but has to be done at the proper point, namely after PCI is reinitialized (which happens in protected mode, so another pmode/rmode switch happens). There is nothing radeon-specific in this code, but it's triggered from the radeon frame buffer driver. You may insert a similar call from any other frame buffer driver to obtain similar results for a wide range of cards (unless I'm mistaken, this has pretty good chances of working). The radeon frame buffer driver must be built into the kernel, and not built as a module, since it must take over the console as early as possible.
I've seen several references to the text above on
acpi-devel lately (20041031). It is a fact that the code in question is
absolutely generic. There's no reason for it to work only for Radeons !
However, on some machines, it might fail (for example, if the video card
sits on an agp slot, then we may have problems, or some other unknown
condition for proper working may not be met). You can give a try at s3_late_bios.patch.gz ; it applies to (stock) kernel 2.6.9.
This gives the acpi_sleep=s3_late_bios kernel parameter which,
when provided, calls the real-mode ROM code when resuming the pci vga
card. It does not work if you have a module providing a resume function
for the device (resuming becomes the responsibility of such a module
then ; but the module can use the same trick: s3_late_bios_radeon.patch.gz does so on radeons ; it's a
skimmed down version of the radeonfb patch).
My current problem with this code is that the machine hangs in the ROM
code when it resumes from a VESA mode. Issuing beeps fails as well. So
the real mode setup is probably incomplete, and there is a lot
of room for improvement here.
Forcing the use of the radeon frame buffer (with the video=radeonfb command-line option) gives the neat, but somewhat unreadable resolution of 1400x1050 for the boot console. Given the standard font, this is 65 rows and 175 columns. The problem is that this is the only resolution for which the display is good. At other resolution, many glitches appear. Therefore I include a high resolution font (16x32), which I rendered from the freetype library using a hand-crafted code. The corresponding patch for the kernel was produced by the same code.
The acpi patch is a collection including a large number of things. Among these is a patch (by D. S. Li) which I formerly used separately as wakeup.patch. Its purpose is enabling the machine to wake up, for example, when you open the lid after a standby. This patch is now on its way to the mainstream kernel, which is a good thing. Kernel 2.6.9 will probably include it. Note that there is no need to use a custom DSDT for the D600 (at least given the BIOS I use (A12). I recall it has been working as well before I flash my BIOS to A12, perhaps the BIOS version was A05 or something similar). Johannes Peeters informs me that until recently, the Dell Latitude suffered from blacklisting with regard to some APIC features (APIC is the programmable interrupt controller -- this has to do with ACPI somehow, but the acronym similarity is fortuitous). Versions of the acpi patch since 20040715 give a much better treatment to Dell Latitude. This results in better behaviour (w.r.t. powering down, as well as resuming from S3).
The function keys patch for the kernel (see below) is here to correct a misbehaviour of the dell keyboard to this regard, since the keyrelease event never comes for some of these keys. There is a standard way in the kernel code to forcibly synthetize it, this is the purpose of the patch. The qsetkey utility is necessary to map these scancodes to something understandable for the kernel.
The acpi_handler.pl script is a relatively straightforward script. You are of course welcome to patch it heavily. Same applies to multimedia_handler.pl (see below). Concerning acpi_handler.pl, it turned out that removing the usb and network modules before the standby was necessary.
The wrapper around updfstab is here to correct a woe of the hotplug system. Indeed, when the usb hierarchy is unconfigured, the updfstab program is run asynchronously. This means that it's sitting there peeking the devices randomly while the kernel tries to go to S3. Obviously this is a bad idea. The idea behind the wrapper is simple. Forbid execution of updfstab within a suspend sequence (hence the semaphore file), and run it once on resume.
The reason why I recommend enabling the forced module unloading is the winmodem. The driver is so messy that you end up quite easily with an rmmod -f hsfmc97ich as the only cure (!).
The usb subsystem is now robust to standby, which is something rather new. If you encounter problems with stanby and usb, you should try recent kernels.
There is a way to get something out of the volume keys, wireless toggle
keys, battery info keys, and CD eject keys (note: I don't think the
crt/lcd key is usable ; it doesn't even trigger an interrupt). The path
to bringing these keys to
life is quite complicated, but I've done the hard part. Just grab these
two patches, one for the
kernel (I already invited you to include it above), and one for your X11 tree
(to be applied below /usr/X11R6/ ; NOTE: This patch assumes you're
using X.org, and not XFree86). This defines the
latitude keyboard model (for XKB). You'll also need this quick utility (really a relaxed and
simplified version of setkeycodes), which will enable you to put the
following at the end of your /etc/rc.d/rc.local script:
/usr/local/bin/qsetkey /dev/console 0xe007 0x83 /usr/local/bin/qsetkey /dev/console 0xe008 0xb0 /usr/local/bin/qsetkey /dev/console 0xe009 0xb5
Of course, I'm assuming you've compiled qsetkey.c into
/usr/local/bin/qsetkey.
Once you've done all this (and rebooted your system, sort of), you
should get X11 events (see via xev for instance) named
XF86ToggleWireless, XF86BatteryInfo, XF86Eject, XF86AudioLowerVolume,
XF86AudioRaiseVolume, XF86AudioMute.
Now, what notably remains to be done is of course the binding to
actual utilities that serve the corresponding function. I can't tell
how this can be done fully generally, Maybe it isn't too hard.
As far as I am concerned, it is the task of the window manager
to achieve this binding. In my case : fvwm
(the one and only). I have added the following to my
.fvwm2rc:
AddToFunc MMK + "I" Exec CONFIGDIR/bin/multimedia_handler.pl $0 Key XF86Eject A A Function MMK "Eject" Key XF86AudioMute A A Function MMK "AudioMute" Key XF86AudioLowerVolume A A Function MMK "AudioLowerVolume" Key XF86AudioRaiseVolume A A Function MMK "AudioRaiseVolume" Key XF86ToggleWireless A A Function MMK "ToggleWireless" Key XF86BatteryInfo A A Function MMK "BatteryInfo"
where CONFIGDIR/bin/ is just any directory where it pleases
you to put this multimedia_handler.pl
perl script. It's very very primitive at the moment... I have nothing
against contributed nifty lightweight applets for doing the same, by the
way...
This page has been visited 15011 times since Aug 15, 2004 (or more likely since the last time the counter broke).
Last modification: Wed Dec 1, 2004, 09:59:01 AM (CET)
If this (