Updated Dell D600 tips for Linux
This page notably helps you set up the suspend-to-ram feature on Dell D600 laptops.
20051104: Fedora kernel 2.6.13-1.1532_FC4 has functional S3 suspend on my D600. Yippee. I haven't taken time to nail down which is the patch that did the trick.
20050822: As I really have no time to update properly this page, this section contains various notes on recent stuff.
20050822: So far, and for quite a long time actually, the basics stay unchanged, no real revolution out there. Concerning S3 suspend, some features break from time to time (expect better results with kernel 2.6.13 than with previous ones, apparently), but such breakages are artifacts. I'm not going to maintain an exhaustive list of what breaks at any given moment in time, presumably such a thing will be of little interest anyway. Furthermore, I'm not using S3 suspend a lot these days, so I may even not notice when something goes amiss.
Concerning the D610 laptop: the major troublemaker concerning S3 is the graphics hardware. D610s come with an intel i915 chipset, which apparently behaves better. So perhaps you won't need the stuff here if you have a D610. See also the links section anyway.
20041108: It's been a year since I started hacking this laptop, and things have gone a long way since then. I'm updating this page to reflect the most up-to-date information. You can access older revisions of this page (the old one and the very old one), but please stop relying on the information from other versions, 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.
Update (20050527): Well, it's been a long, long while
since I haven't seen the machine crash on resume. Something close
to six months.
Some userland software tweaking is also necessary (scripts, silly fixes...).
Install the Fedora Core 2 distribution (or later ; I'm currently running FC3). 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 Fedora. For other distributions, you mileage may vary.
Grab the sources for the kernel. The patches given here should
apply to kernel 2.6.8.1 or later (considering ``official''
versions only). Without further notice, it
should just work since I'm updating my kernel quite frequently,
and I'll change the patch if need be. Today (20050527) I'm
running 2.6.11.10.
Kernel archives can be
grabbed from basically any
kernel.org mirror.
NOTE : You may also manage to use your distro-provided kernel sources, but this is trickier, because of the 4G/4G patch.
You'll also need a handful of patches and scripts (see next).
There is only one patch essential to making S3 suspend
work with your D600: check out
s3_late_bios.patch.gz (patch by Ole Rohne and
me), and use the acpi_sleep=s3_late_bios kernel boot
option. For kernels 2.6.10-rc2 and later, use s3_late_bios_new.patch.gz.
Furthermore, this page references other patches that you may need.
patch_collection.tgz should
contain everything referenced from this page, so you might grab
it.
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.9.tar.bz2 mv linux-2.6.9 linux
Apply all the needed patches:
gzip -dc s3_late_bios.patch.gz | patch -p1 -d linux
Get a config file. The one for your running kernel is on your hard disk, you can get it with:
cat /lib/modules/`uname -r`/build/.config | grep -v CONFIG_DEBUG_INFO > linux/.config
CONFIG_DEBUG_INFO is stripped out because otherwise you'll get an enormous bloat (300MB). Alternatively, my config file is here).
Configure the thing. You won't have many questions to answer.
cd linux/ make oldconfig
If you want to tweak manually the config, do make menuconfig.
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.9 root=LABEL=/ video=radeonfb:off video=vesafb acpi_sleep=s3_late_bios
NOTE: Currently, this does not work under X11 with DRI enabled. You should comment out the Load "dri" in /etc/X11/xorg.conf. This easy patch (local copy) for X.org is reported to fix the issue (thanks to Joey Reid for pointing this out to me). Note again that actually applying this fix and compiling a new radeon_drv.o without compiling everything and the kitchen sink is left as a tricky exercise to the reader, as the current “SDK” packages from X.org have gone wild.
Now, you've got the bare bones to have most of the thing up and running. You may miss proper ACPI scripts, in which case this section is for you. There is nothing hard here: nothing else than install instructions for the scripts I use. 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.
You need:
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 ; 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.
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 (problems may arise with DRI enabled ; see above).
Nothing absolutely needed in here, you can live without it.
Patches needed:
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. Furthermore, it is rather fragile, so you
may have to apply it more or less by hand). 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...
So you want to use the high resolution frame buffer driver ? It works, but seems to be more fragile than the classic console. You'll need to patch your kernel with s3_late_bios_radeon.patch.gz. If you want to patch kernel 2.6.10 or newer, use s3_late_bios_radeon_new.patch.gz instead.
The radeon framebuffer driver must be selected as built-in (NOT as a module, it won't work) under Device Drivers → Graphics support →ATI Radeon display support in the kernel config, and putting video=radeonfb in the kernel command line.
The problem with the high resolution framebuffer is that you'll get artifacts at the bottom of the screen. At the very high resolution 1400x1050, you've got less such artifacts, but the problem is that then the default font is really too tiny (65 rows times 175 columns). Here is 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.
If you choose to use the hires font, you must select it from the kernel config, under Device Drivers → Graphics support → Console display driver support → Luxi 16x32 font.
Last stuff for activating the high-resolution console font at bootup:
cp lux16m.psf.gz /lib/kbd/consolefonts/ echo 'SYSFONT="lux16m"' >>/etc/sysconfig/i18n
Concerning other hardware present on the D600, here is a bit of information.
Dell TrueMobile 1300works with ndiswrapper ; here is ndiswrapper-0.11.tar.gz (included in the big tar file patch_collection.tgz). NOTE: This is not an Intel Pro Wireless 2100/2200 card ; I know such cards are sold today with newer D600s, but the “Dell TrueMobile 1300” is really a Broadcom chip, and the ipw2100 / ipw2200 drivers won't help with broadcom chips. So please don't send me an email saying I don't need ndiswrapper. I do.
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.
Kernel patches might not apply immediately. If you're the
cautious kind of person, you'll first do things such as
gzip -dc s3_late_bios.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 the one specified, try to fetch more recent versions
of the patches.
While you're at building your kernel, select the ntfs module under File systems → DOS/FAT/NT Filesystems → NTFS file system support.
Told you it was poor code !
You should check Loadable module support →
Forced module unloading, so that root can do
rmmod -f hsfmc97ich (the command
hsfstop works afterwards).
If you're running Fedora Core 2, or have any sort of
/usr/bin/updfstab program installed on your machine,
there is the culprit. I provide a wrapper around
updfstab. In order to install it, 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
Do you have a proper initrd installed ? It's not unwise to check that an initrd image exists for your new kernel, and has everything it needs:
gzip -dc /boot/initrd-2.6.8.1.img > /tmp/fs echo "ls -l /lib" | debugfs /tmp/fs
NOTE: Late initrd's seem to be cpio images, and not ext2 filesystems. So here's what you do to check the contained modules:
gzip -dc /boot/initrd-2.6.8.1.img | cpio -i --list | grep lib/
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).
Well, you know, this page really does most of the work for you, and I've tried my best to explain what you need, under which conditions, and why you need it. But if you insist, here is a summary of the patches I provide (for the kernel).
If any of these patches does not apply cleanly, go there.
The following selections are relevant to this page, but of course you're on your own. I assume I don't have to educate you about the necessity of building pci support into your kernel, and all obvious things of this kind !
Here are extremely quick notes about the why and how...
The s3_late_bios patch does a real-mode call to the video bios, so that the video card 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). This code works for some radeon boards, but may work for other boards. 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. Update (20041117): this patch is reported to work on Dell D800 laptops (which have an nvidia card), if you use the open-source driver (NOT the proprietary one).
There is no need to use a custom DSDT for the D600, at least given the BIOS I use (A12).
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. Concerning acpi_handler.pl, it turned out that removing the usb and network modules before the standby was necessary. Update (20041108): the usb subsystem now has experimental suspend/resume support. It seems to almost work.
Kernels before 2.6.8.1 (and acpi before 20040715) had problems with usb on resume. These problems are now solved. If you encounter problems with stanby and usb, you should try recent kernels.
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.
This page has been visited 1 times since Nov 08, 2004 (or more likely since the last time the counter broke).
Last modification: Fri Nov 4, 2005, 05:33:28 PM (CET)
If this (