Thanks to Erich writing this section.

You might need to override the DSDT when certain features like battery status are incorrectly reported (usually causing error messages to syslog). DELL laptops usually need this kind of override. Fixed DSDT for many systems are available on the DSDT page, along with a patch that tells the kernel to ignore the BIOS-supplied table but use the compiled-in fixed DSDT.

Basically you need to copy the fixed table into your kernel source with a special filename (or modifying the filename in the patch supplied at the DSDT page) This override is quite easy: instead of loading the DSDT table from BIOS, the kernel uses the compiled-in DSDT table. That is all.

This document was originally written for the 2.4.20 kernel and has been updated since to include information about the 2.6.x series kernels. At the time of this update the 2.6.x series kernels are proving easy for some and harder for others.

If you can, I would recommend waiting to upgrade your kernel to the 2.6.x series until more bugs are ironed out, and more documentation is available. There are a lot of changes in the 2.6.x series kernel. When I upgraded to 2.6.5 to update this document I ran into problems with my wireless connection, my nVidia graphics card, my touch pad, and with ACPI. Your mileage may vary. I personally had good success with the 2.4.20 with the latest patch and the 2.4.22 kernel with no patch. (And then I upgraded from 2.4.22 directly to 2.6.5.) A Google through your distribution's mailing list, and the acpi-devel mailing list should help you to pick the right kernel.

Regardless of which kernel you choose, if it is a kernel that requires patching, it is important to use the latest version of the ACPI patch. Some distributions have already patched their kernels. This is the case for Debian, and may be the case for others. For more information on the patches that have been applied to the Debian kernel source package scan through: /usr/src/kernel-source-<version>/README.Debian. If you are not using Debian look in the /usr/src/kernel-source-<version> directory for an equivalent file.

If you are running a production-level server and/or are serving web pages to the Internet, please also apply any additional security patches. You may have additional patches which must be applied for hardware or software problems specific to your system. Most laptop users should be fine with only the ACPI patch. If possible laptop users should also apply any additional security patches.

If you are already running a kernel that is the same version of the one you are about to patch I recommend creating a fresh directory for the newly patched kernel. You should create a backup of all important kernel configuration and kernel-related files that may be affected by your work. Remember that backups are never a bad thing and can be easily deleted after your system has been successfully patched.

Use make oldconfig to configure your new kernel. Using oldconfig instead of menuconfig allows you to start with the options you have selected in your current kernel and prompts you to select your preference for all new kernel options. This is much easier than looking for all of the new options by hand. For everything specific to ACPI and your hardware (if you use a Toshiba choose the Toshiba options, Asus choose the Asus options) choose M for module. There are about ten different ACPI related options that you will need to select.

It is now time to compile the kernel. These instructions are for Debian users. If you are not using Debian, or you do not like compiling your kernel The Debian Way, please read Appendix B, Compiling Kernels the Non-Debian Way for more help.

If you have additional modules that are not part of the main source tree, you will need to add modules_image when you make your Debian packages. This is almost inevitable if you are using a laptop and an older kernel. I still need this option even in the 2.6.6 kernel due to my nVidia graphics card.

Now that the kernel is compiled it can be “installed.” For Debian users this means installing the Debian package file you created in the last step and then loading the new kernel into lilo. I like to configure lilo on my own and have provided the instructions here, but I leave that decision up to you.

At this point you should reboot your machine. When your system comes back up (assuming of course that everything went well and you still have a system), you will need to check that you are running the new kernel with the correct patch.

Check to see that each of the ACPI modules have been loaded after your machine boots. You can do this with the command lsmod. You are looking for the following options: button, battery, fan, ac, thermal and processor. If you chose “Y” instead of modules when you compiled your kernel, you will not see this list. The output on my computer looks like this:

Module                  Size  Used by    Tainted: P  
button                  2420   0 (unused)
battery                 5960   0 (unused)
ac                      1832   0 (unused)
fan                     1608   0 (unused)
thermal                 6664   0 (unused)
processor               8664   0 [thermal]
NVdriver              945408  11 

The last module is my graphics card, which uses proprietary drivers. This is why I have a “P” next to Tainted on the top line.

If you compiled ACPI support in as “M”odules and you do not see the ACPI modules listed you will need to load the modules by hand. The modules should be in /lib/modules/<version>. <a_unique_and_clever_name>/kernel/drivers/acpi/, and are as follows:

-rw-r--r--    1 root     root         4.1k Jun  3 23:57 ac.o
-rw-r--r--    1 root     root         9.5k Jun  3 23:57 battery.o
-rw-r--r--    1 root     root         5.2k Jun  3 23:57 button.o
-rw-r--r--    1 root     root         3.7k Jun  3 23:57 fan.o
-rw-r--r--    1 root     root          14k Jun  3 23:57 processor.o
-rw-r--r--    1 root     root          11k Jun  3 23:57 thermal.o
-rw-r--r--    1 root     root         6.2k Jun  3 23:57 toshiba_acpi.o

The first time I rebooted I loaded them all by hand, typing insmod <modulename>. I personally load processor first, although there are mixed feelings on whether or not the order matters.

To prevent having to load the modules each time you reboot you can do one of two things: compile them directly into the kernel (bit late for that though, eh?), or add them to your /etc/modules file. If you do not already have a copy of the file just create a new one and add each module name (remember, no dot-o) on a separate line. You can also try running update-modules which should automatically update your /etc/modules.conf configuration file.