ACPI/Fix common problems

Introduction
For the past few weeks, I've been wrestling with ACPI. The main problems are that it has a buggy DSDT and a missing ECDT. A bit of googling revealed that neither is an uncommon problem. Unfortunately, some other OSes are more forgiving of deviations from the ACPI spec than they should be, and that causes problems for the rest of us. The only real solutions are to provide a fixed DSDT and ECDT to the kernel.

Now when I heard this, at first I was afraid; I was petrified. But as it turned out, it wasn't so hard to fix the problem. The trickiest part was diagnosing it; from there (in my case at least) the fix was very straightforward. Here's how to go about doing it if you are also having trouble with ACPI on your machine. Much of this is taken from this post, but I've weeded out some other stuff that was more specific to my machine.

NOTE: This involves some kernel patching, and possibly overwriting your existing initrd. PLEASE make backups of important things. In particular, I found that backups of my kernel configs, working kernels and bootsplash initrd were extremely helpful.

Definitions
ACPI Machine Language (AML)

From the ACPI Spec (Page 13):

Pseudocode for a virtual machine supported by an ACPI-compatible OS and in which ACPI control methods and objects are written.

This is what the DSDT is compiled to. An ACPI-compatible OS must be able to understand AML. You don't have to be able to.

ACPI Source Language (ASL)

Again from the Spec (Page 13):

The programming language equivalent for AML. ASL is compiled into AML images.

This is the language that the DSDT is written in. If you need to fix your DSDT, you'll have to write at least a little bit of ASL.

Differentiated System Description Table (DSDT)

From the ACPI Spec (Page 14):

An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system. The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it.

Well of course this boils down to the DSDT describes the configuration of your system. It has definitions of all of the devices that ACPI supports, and describes their capabilities. So, for example, it describes the battery, AC Adapter, Embedded Controller, Fans and Thermal Zones. It presents this information in a hierarchical manner, so that ACPI (and therefore the OS) can be aware of dependency relationships among the system hardware. The DSDT is loaded at boot time. It basically tells the ACPI drivers what to watch out for.

Description of the Problem
The ACPI Specification defines the requirements for the DSDT (and everything else, for that matter) pretty explicitly. Intel's ASL compiler, iasl, used to compile the DSDT to AML from ASL, will throw errors and warnings if the underlying ASL is buggy. Unfortunately, Microsoft's ASL compiler allows many of these errors and warnings to sneak by. As a result, many OEMs write buggy DSDTs, and it turns out that Windows is very forgiving of bugs in the DSDT that get by Microsoft's compiler (not surprisingly).

What this means is that a DSDT that does not conform to the ACPI specification will work under Windows, even though it shouldn't. However, when you try to use it in Linux, where the ACPI developers expect that the DSDT is written to comply with the standard (and the Intel ASL compiler), the buggy sections of the DSDT are unsupported. If you have a buggy DSDT, ACPI may not be aware that certain devices exist. Or, if it is aware, it may not support all of their capabilites. If you have either of these symptoms (missing or incompletely supported functionality in /proc/acpi), then the cause may be a buggy DSDT.

You can tell whether your DSDT was compiled with the Microsoft compiler by the presence of "MSFT" in the DSDT line in dmesg, as below:

ACPI: RSDP (v000 GBT ) @ 0x000f6d20 ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000 ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040 ACPI: MADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7080 ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000

Ideally, we could each convince our favorite purveyor of laptops to fix their DSDTs. That's a good idea, but while we're waiting for hell to freeze over, we can implement a workaround to fix our DSDTs ourselves, and provide the fixed DSDT to the linux kernel, making it content, perhaps even happy.

In addition to the DSDT, laptops that conform to the ACPI 2.0 specification may provide an ECDT. This is a small table that provides minimal information about the Embedded Controller to the ACPI drivers before this section is parsed from the DSDT. This is necessary to prevent some chicken and egg type problems with initializing devices (such as the battery and ac adapter in some systems) that rely on the Embedded Controller. Sadly, again, some laptops that should provide an ECDT do not. So, to get around this, we'll have to patch the kernel to read the necessary information from the DSDT.

Disclaimer
The processes outlined here should help you to solve many common problems with ACPI under linux. However, they will not necessarily solve all of your ACPI problems. Unfortunately, there are many causes of ACPI trouble. If after trying these fixes, your ACPI problems persist, then you may have found a bug in the ACPI driver code, which is still under active development. You may also have found a system-related issue of which I am not aware. In either case, your best options are to send an email to the acpi-devel mailing list or to open up a bug at bugzilla. Sometimes, it's best to let the pros handle things.

But enough about what this can't fix. Let's dig into the things that it can. First things first - let's make sure we have a good DSDT.

Tested Kernels (DSDT Override)
The DSDT override procedures outlined in the following sections have been tested successfully with the following kernels:


 * 2.4.23 vanilla with ACPI patches from acpi.sourceforge.net (static DSDT)
 * 2.4.24 vanilla (static DSDT, initrd DSDT)
 * 2.6.0 vanilla (initrd DSDT)
 * 2.6.0-gentoo (initrd DSDT + bootsplash)
 * 2.6.1-rc1 vanilla (static DSDT)
 * 2.6.1 vanilla (initrd DSDT)
 * 2.6.10-gentoo-r6 (initrd DSDT)

What You'll Need to Fix DSDT
Before you get started fixing your DSDT, you will need the following:


 * 1) ACPI support compiled into your kernel (static or modules), so you have a /proc/acpi directory.
 * 2) The latest ACPI patches from Linux/acpi project (old site) (if using vanilla sources).
 * 3) The Intel asl compiler, emerge sys-power/iasl or available on Intel's homepage.
 * 4) The static DSDT override patch (tested with kernels 2.4.23 and above), available here
 * 5) The initrd DSDT override patch appropriate for your kernel, avaliable here

Diagnosing a Buggy DSDT
Obviously, fixing your DSDT won't be of any help if it isn't broken. So, the first thing we have to do is find out if it is buggy or not. The easiest way to do this is to recompile the DSDT and see if we get any errors from the compiler. In order to do that, we'll need the iasl compiler and the DSDT to compile. The Intel ASL compiler is available through portage so let's get it unmasked and installed:

Now we need to get the current DSDT, disassemble it and recompile it to see if we get any errors.


 * Extract your current DSDT to a file as follows:


 * or in older kernel

This will create a file in your home directory called dsdt.dat that contains your current compiled dsdt. Now we have to disassemble it so we can recompile it. To do that, we'll use IASL.


 * Disassemble the DSDT

This will create a file called dsdt.dsl, which contains the disassembled DSDT. Have a look at it if you like. You can view its contents with any text editor. Now we need to recompile it to find any errors or warnings, again with IASL.


 * Recompile the DSDT.

This will create two files, dsdt.hex and DSDT.aml.

That's it! If your DSDT is buggy, then you'll see some errors and/or warnings when you recompile. For instance, on my laptop, I got the following messages when recompiling:

One error, two warnings. In my case, the error was the source of my trouble. So, if we can fix that up, it should help. At this point, you're done diagnosing the problem. If you got errors from recompiling, then you have a buggy DSDT. The next step is to fix it.

If you like me have a reliability issue and have to boot with the noacpi flag and don�t have /proc/acpi/dsdt populated there is an another solution. If you are going to make a dualboot and got Windows available you could use this method.


 * Download windows binaries of iasl.exe by follow the link from http://www.acpi.info
 * Use start menu Run and type cmd
 * type

path_to_iasl\iasl -d

Hopefully you ended up with a fully readable dsdt.dsl file that you could move into your Gentoo install.

Repairing the DSDT
The first thing that you should do if you have a buggy DSDT is to head over to the DSDT repository at acpi.sourceforge.net. They have fixed DSDTs for a number of laptops, so your model may already have a fix available. If there is a fix there, then just download it, extract it, recompile the asl using iasl as above, and proceed to Section 9. If there isn't already a fixed DSDT available, then you will have to try to fix your DSDT yourself. Read on for an example from my machine.

Unfortunately, this step will differ for every system. In my case, the fix was simple and self-evident, but I can't guarantee that that will be the case with you. You can find solutions to common DSDT compilation errors here. At the end of the document, I'll have a list of useful resources in case you get stuck. OK - on to the fixing!

In order to fix the DSDT, you'll have to edit the dsdt.dsl file that we created in the diagnosis. Let's use mine as an example. Unless you also have a Gateway 200X, your process will be different (and if you do have a 200X, then you can get the fixed DSDT here). However, this should at least give you an overview of the process.

As you may recall, when I compiled my DSDT, I got one error:

This tells me the following: - The error is on line 2626 - The region in question requires ByteAcc Access

Since I see that this line has a DWordAcc value specified, I assume that that is what is causing the problem. So, I opened dsdt.dsl in a text editor and fixed that line:


 * Edit dsdt.dsl


 * Change any lines that are raising errors. I changed line 2626 from this

to this

Save and close the file. Now that we've made the change, we have to recompile to see if we actually fixed the problem.


 * Recompile dsdt.dsl

Now, when I recompile, I get the following:

Alright! The error is gone. The warnings are still there, though. Let's get rid of them now, too.


 * Repeat steps 1-3 for the warnings

The second warning seems to be the easier one:

dsdt.dsl 2672:    Method (_GLK, 1, NotSerialized) Warning 2024 -    ^ Reserved method has too many arguments ( _GLK requires 0)

So, the _GLK method has too many arguments. Let's get rid of them. We can fix this by changing line 2672 from this:

Method (_GLK, 1, NotSerialized)

to this:

Method (_GLK)

Recompiling now only gives me the one warning:

dsdt.dsl  163:   Method (_WAK, 1, NotSerialized) Warning 2026 -   ^ Reserved method must return a value (_WAK)

From this HOWTO, I see that the solution is to add the following line to the end of the _WAK method:

Return(Package(0x02){0x00, 0x00})

What does this line mean? A little digging into the ACPI spec (Section 7.3.5) yields some information about the _WAK method.

Arguments: 0 The value of the sleeping state (1 for S1, 2 for S2, and so on). Result Code (2 DWORD package): Status  Bit field of defined conditions that occurred during sleep. 0x00000000  Wake was signaled and was successful 0x00000001  Wake was signaled but failed due to lack of power. 0x00000002  Wake was signaled but failed due to thermal condition. Other  Reserved PSS If non-zero, the effective S-state the power supply really entered.

This value is used to detect when the targeted S-state was not entered because of too much current being drawn from the power supply. For example, this might occur when some active device�s current consumption pushes the system�s power requirements over the low power supply mark, thus preventing the lower power mode from being entered as desired.

OK, so the _WAK method accepts one argument, which is the number of the sleep state that was requested. It returns its result as a package of 2 DWORDs. The first value is a code that tells whether the wake was successful (0 on success, nonzero on failure) and, if not, why. The second value is also zero on success and on failure returns the value of the sleep state that was actually entered. So basically, it's a success/failure code.

In Chapter 16, we can find out how to define a Package.

PackageTerm  := Package(               NumElements  //Nothing |               //ByteConstExpr |               //TermArg=>Integer               ) {PackageList} => Package

The first argument of the package declaration specifies the number of elements in the package, and the second is the package itself. So, the declaration above simply defines a two element package, where each of the elements is zero. This is necessary because the spec requires that the _WAK method return two values.

So, what this really boils down to is a dummy return value that satisfies the spec (thus eliminating the warnings), but doesn't really do anything. It just always returns a "Success" condition.

OK, now that that is cleared up, I add that line, recompile, and.... (drum roll please)

Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003] Copyright (C) 2000 - 2003 Intel Corporation Supports ACPI Specification Revision 2.0b ASL Input: dsdt.dsl - 3760 lines, 123177 bytes, 1863 keywords AML Output: DSDT.aml - 14606 bytes 499 named objects 1364 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 392 Optimizations

Excellent! No errors, no warnings. We now have a "fixed" DSDT (remember, the _WAK method isn't really fixed, we've just shut up the warning on compile). Many of the suggestions in the DSDT HOWTOs that I found are really just workarounds, not proper fixes. If you would like a more thorough analysis of your DSDT, you may want to ask the folks on the acpi-devel mailing list. If you succesfully used this process to fix your DSDT, please consider posting the fix to the DSDT repository, so that others can benefit from your work.

All that remains now is to convince our kernel to use the new DSDT.

As stated above, this will create two files, dsdt.hex and DSDT.aml. You will need to use one or the other of these files in the next step, depending on which method you use to override your DSDT. If you use the static DSDT override method, then you will need dsdt.hex. If you use the initrd method, then you will need DSDT.aml.

Incorporating the Fix into the Kernel
There are three ways to incorporate your new DSDT into the kernel. The first way is to include it statically at compile time. The second is to pass it to the kernel at boot time as an initrd. The third way is to use the built in options on 2.6.9 and later kernels. If you are using a 2.6.9 or more recent kernel, the third option is the best. Otherwise, the initrd approach is probably preferable, especially if you need to make a lot of changes to your DSDT, because it doesn't require that you recompile your kernel for each new DSDT. The static method does. Each method requires a kernel patch. Let's start with the static method first:

Static DSDT Override
To statically override your DSDT at kernel compile time, you will have to apply a patch to your kernel to have it read in the new DSDT, and then copy your fixed DSDT .hex file (dsdt.hex) to the kernel source tree for inclusion in the kernel.

So, first things first, let's patch the kernel.


 * Obtain DSDT override patch from here (If you are using kernel 2.6.9 or newer, proceed to option 3 instead, since the ability to specify a custom DSDT is already compiled in the kernel).
 * Save the file to your machine. Let's call it dsdt_override.diff.
 * Patch your kernel. I'm assuming that the kernel sources are located in /usr/src/linux-2.4.23, since that's the version I used. If yours are elsewhere, then modify the paths accordingly.

cd /usr/src/linux-2.4.23 patch -p1 < /path/to/dsdt_override.diff

If you don't get any errors, then the patch succeeded. The patch expects to find the fixed DSDT in the linux source tree, under includes/acpi. It expects it to be named dsdt_table.h. So, let's give it what it wants.


 * Copy dsdt.hex to the kernel source tree.

cp /path/to/dsdt.hex /usr/src/linux-2.4.23/include/acpi/dsdt_table.h


 * Recompile your kernel.

That ought to do it. After recompiling, move your new kernel image to /boot (maybe don't overwrite your current kernel - just to be safe), and reboot. If any of your acpi problems were caused by the buggy DSDT, then they should be fixed. /proc/acpi/dsdt should now contain your new fixed DSDT, so you can always cat that back out and recompile it to make sure that you are getting what you expect (i.e. no errors).

Remember, if you make more changes to your DSDT, then you'll have to recopy it to /include/acpi/dsdt_table.h and recompile your kernel.

Initrd DSDT Override
The initrd method requires about the same amount of setup as the static method for the initial DSDT, but any subsequent changes can be incorporated much more easily. Basically, you will have to patch your kernel, copy your fixed DSDT .aml file (DSDT.aml) to /boot, and direct the kernel to incorporate it as an initrd. If you are already using an initrd for something, then there is a bit more work involved. I'll go over that after describing the basic case.

So, again, the first thing we have to do is patch the kernel.


 * Get the appropriate initrd patch for your kernel from here
 * Apply the patch to your kernel (in my case, I tested this on 2.6.0)

cd /usr/src/linux-2.6.0 patch -p1 < /path/to/acpi-dsdt-initrd-patch-v0.4-2.6.0.diff


 * Make sure that ramdisk and initrd support are compiled statically into the kernel

Linux Kernel Configuration: Initrd support

Device Drivers ---> Block Devices ---> <*> RAM disk support [*] Initial RAM disk (initrd) support

Make sure that the new "Read DSDT from initrd" option is selected under the ACPI menu Linux Kernel Configuration: Read DSDT from initrd

Power management options (ACPI, APM) ---> ACPI (Advanced Configuration and Power Interface) Support ---> [*] Read DSDT from initrd


 * Recompile the kernel

Great! Now the kernel is ready to accept a DSDT as an initrd. Next, we need to copy the fixed DSDT.aml file to /boot and edit our grub.conf to point to the DSDT.


 * Copy the fixed DSDT.aml to /boot:

mount /boot cp /path/to/DSDT.aml /boot


 * Edit grub.conf to use the new DSDT as an initrd. For example, mine looks like this:

title=Gentoo Linux (2.6.0 - DSDT initrd) root (hd0,5) kernel (hd0,5)/boot/linux-2.6.0-dsdt-initrd root=/dev/hd8 initrd=/boot/DSDT.aml

The important line is the "initrd=" line. Please remember to use your actual paths for root and kernel - don't just copy this into your grub.conf verbatim.

When you reboot, the new kernel should pick up the DSDT from the /boot partition and load it up as directed by the initrd parameter. You should see a message in dmesg that says "Looking for DSDT in initrd ..."

Now, if you make changes to your dsdt, all you have to do is copy the new DSDT.aml to /boot and reboot to incorporate those changes. No kernel recompile required.

Initrd Override with Bootsplash
If you are already using an initrd for something, like bootsplash, you can still use this method. You just have to create the initrd a bit differently. Instead of simply copying DSDT.aml to /boot and using it as the initrd, you have to cat a signature for the DSDT into your existing initrd, and then cat the DSDT into it as well. For example, my bootsplash initrd is currently called initrd-1024x768. So, here's what I did to add the DSDT.


 * Make a copy of /boot/initrd-1024x768 for use with the DSDT

cp /boot/initrd-1024x768 /boot/initrd-1024x768-dsdt


 * Append the DSDT signature to the initrd

echo "INITRDDSDT123DSDT123" >> /boot/initrd-1024x768-dsdt


 * cat the fixed DSDT.aml into the initrd

cat /path/to/DSDT.aml >> /boot/initrd-1024x768-dsdt

* Modify grub.conf to use the new initrd on boot:

title=Gentoo Linux (2.6.0 gentoo - bootsplash + DSDT initrd) root (hd0,5) kernel (hd0,5)/boot/linux-2.6.0-gentoo-dsdt root=/dev/hd8 video=vesa:ywrap,mtrr vga=0x317 initrd=/boot/initrd-1024x768-dsdt

Voila! When you boot up, you should now get your lovely bootsplash screen and your new dsdt, both incorporated from the initrd.

Warning: This may crash your system, as a kernel panic may happen upon rebooting. Don't delete your old configuration. I could find a workaround using the splash kernel parameter and the aml file as the initrd:


 * grub.conf should be like this:

title=Gentoo Linux 2.6.12-r6 + Suspend + DSDT root (hd0,5) kernel hd0,5)/boot/linux-2.6.0-gentoo-dsdt root=/dev/hd8 video=vesafb:ywrap,mtrr,1024x768-16@70 splash=silent,theme:livecd-2005.1 CONSOLE=/dev/tty1 initrd=/boot/DSDT.aml

The splash image shows a bit later, but everything else works perfectly

If you make changes to the DSDT, you just have to rebuild your initrd as above (which is a good reason to make a copy of your existing one, rather than appending to it directly).

Build-in Options for Kernel 2.6.9 and Later

 * Recent kernels include the option to specify a custom DSDT. First, copy the hex dsdt table that you compiled to somewhere convenient.

cp /path/to/dsdt.hex /usr/src/dsdt_table.h


 * First in kernel config, disable "Select only drivers that don't need compile-time external firmware"

Linux Kernel Configuration: Disable "Select only drivers that don't need compile-time external firmware"

Device Drivers ---> Generic Driver Options ---> [ ] Select only drivers that don't need compile-time external firmware [ ] Prevent firmware from being built


 * Then enable the custom DSDT options in the kernel, and provide a path to the hex dsdt table that you compiled.

Linux Kernel Configuration: Enable the custom DSDT

Power management options (ACPI, APM) ---> ACPI (Advanced Configuration and Power Interface) Support ---> [*] Include Custom DSDT (/usr/src/dsdt_table.h) Custom DSDT Table file to include


 * Recompile your kernel, copy the bzImage, and modify your grub.conf to point to the new kernel.

Troubleshooting
My DSDT is fixed, but I still have ACPI errors. Now what?

Windows-only DSDT functionality
You may find that you have no errors in your DSDT, but there are still errors in dmesg, or missing ACPI functionality. This may be because your DSDT is testing for the name of your OS. Many DSDTs do this, and enable certain functionality only if you are running a particular OS (usually, of course, Windows XP). To test for this, look for lines in your DSDT that check the value or length of the "_OS" variable. For example, you may find lines like this:

If (LEqual (SizeOf (_OS), 0x14))

This is checking for an OS name with a length of 20 (0x14) characters. Some examples are "Microsoft Windows NT" or "Microsoft Windows XP". You could try to rewrite your DSDT to skip these checks, or to provide the missing functionality for other OSes, but this is tedious and error-prone. Fortunately, there is a simpler way. There is a boot parameter that you can pass to the kernel to tell ACPI to pretend that you are running Windows to restore the missing functionality, rather than rewriting your DSDT. The parameter is called acpi_os_name. So, in grub.conf, you would just add this parameter to the kernel line, like this:

acpi_os_name="Microsoft Windows XP"

This should restore any functionality that is dependent on your OS identifying itself as Windows XP. Other common _OS length checks are:

0x11: "Microsoft Windows" 0x27: "Microsoft WindowsME: Millennium Edition"

Note: These tests are also sometimes used to disable certain functionality for certain Windows OSes. So, you may want to take a few minutes to try to work out what your DSDT is doing before fudging the OS name. You should probably take note of what works and what doesn't before and after trying this, just in case you end up turning something off.

Note: This section seems a bit off-base. Recent Linux kernels already set the OS name to "Microsoft Windows NT" (also length 0x14) - see ACPI_OS_NAME. The _OS object is obsolete anyway, and recent bioses use the _OSI method, to which Linux already responds in the affirmative to queries such as "Windows 2000" etc. See also http://www.microsoft.com/whdc/system/pnppwr/powermgmt/_OSI-method.mspx for what windows-y bioses might throw your way.

Missing ECDT
If your problem isn't that the DSDT is checking whether or not you are running Windows, then you may have a missing ECDT. The ECDT is used to provide some minimal information about the Embedded Controller to the ACPI drivers before the Embedded Controller region has actually been parsed from the DSDT. This is frequently necessary before initializing the battery and ac adapter, so if you have errors in dmesg from the battery, adapter or EmbeddedControl, the ECDT is the likely culprit. For instance, after fixing my DSDT, I had the following errors in dmesg:

evregion-0251 [22] ev_address_space_dispa: No handler for Region [ECR_] (df5ec688) [EmbeddedControl] exfldio-0284 [21] ex_access_region     : Region EmbeddedControl(3) has no handler dswexec-0435 [14] ds_exec_end_op       : [LEqual]: Could not resolve operands, AE_NOT_EXIST dswstate-0273 [16] ds_result_pop_from_bot: No result objects! State=df5fb428 dsutils-0525 [16] ds_create_operand    : Missing or null operand, AE_AML_NO_RETURN_VALUE psparse-1120: *** Error: Method execution failed [\_SB_.ADP1._STA] (Node df5f42c8), AE_AML_NO_RETURN_VALUE evregion-0251 [22] ev_address_space_dispa: No handler for Region [ECR_] (df5ec688) [EmbeddedControl] exfldio-0284 [21] ex_access_region     : Region EmbeddedControl(3) has no handler dswexec-0435 [14] ds_exec_end_op       : [LEqual]: Could not resolve operands, AE_NOT_EXIST dswstate-0273 [16] ds_result_pop_from_bot: No result objects! State=df5fb428 dsutils-0525 [16] ds_create_operand    : Missing or null operand, AE_AML_NO_RETURN_VALUE psparse-1120: *** Error: Method execution failed [\_SB_.BAT1._STA] (Node df5f4848), AE_AML_NO_RETURN_VALUE

EmbeddedControl is obviously the embedded controller. ADP1 is the ac adapter and BAT1 is the battery. After booting, my /proc/acpi/ac_adapter and /proc/acpi/battery directories were empty. All of this was caused by the missing ECDT.

A couple of patches have been proposed to correct this behavior. So far, the most promising one is here. This defers the Embedded Controller's initialization until it has actually been parsed from the DSDT. This patch restored my missing ECDT-related functionality (battery and adapter), and has been reported to do the same for a number of different systems. It may be applied to both the 2.4 and 2.6 kernel sources.

Power and/or Sleep Buttons Don't Work
The ACPI spec defines two types of power and sleep buttons. They are called fixed-feature (FF) buttons and control method (CM) buttons. The difference between the two is that FF buttons are defined at a lower level than the DSDT, in the FADT. CM buttons are defined in the DSDT. It is possible for your system to have both types of button. You can tell which you have by the presence of an "FF" or "CM" next to the button alert in dmesg. For example, my dmesg gives the following:

CPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID0] ACPI: Sleep Button (CM) [SLPB]

So, ACPI is detecting an FF power button and a CM sleep button. I actually also have a CM power button defined in my DSDT. However, in accordance with the ACPI spec, if the linux drivers detect an FF button, the CM button is ignored. Unfortunately, the FF power button does not generate an ACPI event in my case. However, the CM sleep button does generate events.

I opened a bug for this behavior. However, it is unlikely that the behavior will change, since it would contradict the spec to give CM buttons precedence over FF buttons. So, I posted a patch to provide a workaround for the problem on the 2.6 kernels.

The patch allows you to provide a new boot parameter, called ignore_ff_buttons. It accepts one of three values, PWRF (to ignore only the FF power button), SLPF (to ignore only the FF sleep button), or BOTH (to ignore both FF buttons).

In my case, I just want to ignore the FF power button, since I am already using the CM sleep button. So, I modified my grub.conf as below:

title=Gentoo Linux (2.6.1 - all ACPI patches) root (hd0,5) kernel (hd0,5)/boot/linux-2.6.1 root=/dev/hda8 ignore_ff_buttons=PWRF initrd=/boot/DSDT.aml

Now, when I reboot, dmesg shows me the following buttons:

ACPI: Lid Switch [LID0] ACPI: Sleep Button (CM) [SLPB] ACPI: Power Button (CM) [PWRB]

And I get ACPI events from my power button. Note: If you decide to use this patch, please be careful. I haven't created a kernel patch before. This one doesn't do much, so it should be pretty safe, but I highly recommend that you back up your kernel tree before applying it. Also, if you do decide to use it, I would be very interested to hear whether or not it works for you. Of course, I'm sure that I'll hear if it doesn't, but if it does, I would also like to know.

My BIOS is Blacklisted
Some BIOSes have been blacklisted by the ACPI developers because they have known problems. These problems are usually related to the DSDT, so you might be able to repair these problems using the above techniques. Unfortunately, if the ACPI code detects that you have a blacklisted BIOS, it will disable ACPI even if you have fixed your DSDT. If you have a blacklisted BIOS, you will see a message like this on boot:

ACPI: Vendor "PTLTD " System " DSDT  " Revision 0x6040000 has a known ACPI BIOS problem. ACPI: Reason: Multiple problems. This is a non-recoverable error ACPI: BIOS listed in blacklist, disabling ACPI support

To get around this, you'll have to comment out the line in the ACPI code that causes your BIOS to short circuit the ACPI startup process. The file that sets the blacklisted BIOSes is /usr/src/linux/drivers/acpi/blacklist.c. To prevent your blacklisted BIOS from causing trouble, open up the file and comment out the appropriate line in static struct acpi_blacklist_item acpi_blacklist[]. For example, in the above case, the line to comment is:

{"PTLTD ", " DSDT  ", 0x06040000, ACPI_DSDT, less_than_or_equal, "Multiple problems", 1},

Once you've commented out the line that corresponds to your BIOS, recompile your kernel and reboot. The ACPI drivers should now initialize, and the messages about the blacklisted BIOS should go away. You may also have to boot with "acpi=force" on the kernel line of your grub.conf to get this to work (thanks to sleek for clarifying).

Asus Laptops
If you have an Asus laptop, you may want to check out the acpi4asus project. This is a driver that provides ACPI support on linux for most Asus laptops, including special keys and LEDs. The driver is being actively developed, so if you have a recent Asus laptop that isn't yet supported by the driver, support may be coming soon.

However, the sourceforge homepage of acpi4asus says that the whole project has already been included into the kernel. It should be available in most of the recent versions.

The hard-drive does not return from power-saving mode
If you have a newer laptop you may experience this problem. Newer laptops use a SATA interface. In unpatched kernel versions before 2.6.16 powersaving support is not enabled causing the hd to spin down at bios request with no way to signal a return from this state.

If you believe this may be your problem you can run: hdparm -I /dev/ and look for "power management feature set".

If this is missing and you experience a lockup upon returning from powersaving mode (often with a solid HD activity light) then you are most likely experiencing this problem.

Further information about this problem can be found at the thinkwiki article on SATA and Suspend-To-RAM patches are available for kernel versions prior to 2.6.16 from that site.

Nothing Works
If, at this point, you are still having errors, there are one or two more things to try. If ACPI refuses to initialize, you can try booting with "acpi=force" in your grub.conf. This is sometimes necessary in order to force the ACPI drivers to initialize with older BIOSes. If you still have ACPI-related errors on boot and have a single-processor machine, then try disabling multiprocessor support, local apic support and IO-apic support in your kernel. You can also try booting with the "pci=noacpi" or "noapic" options. The apic code still seems to be a bit finicky; many people have reported problems with it.

If none of the above recommendations helps, then I would strongly suggest contacting the ACPI developers. You have likely found a bug in the ACPI code. In particular, if you are having suspend/resume problems, you are far from alone. This code is still being worked out. Give the acpi-devel mailing list a shot. You can also, of course, post your errors here, and I'll try to see what I can do to help, but the acpi gurus are likely to be a better resource. Useful ACPI Resources


 * 1) http://bugzilla.kernel.org/
 * 2) Linux/ACPI http://www.lesswatts.org/projects/acpi/old SF site
 * 3) acpi-devel and acpi-bugzilla mailing lists
 * 4) www.acpi.info (the ACPI spec is here, including ASL documentation, which is the language used for the DSDT)
 * 5) The Intel ACPI downloads page (get the iasl compiler here)
 * 6) HOWTO fix common DSDT errors
 * 7) DSDT fixes for the Thinkpad R31
 * 8) DSDT repository at acpi.sourceforge.net
 * 9) DSDT submission page at acpi.sourceforge.net.
 * 10) Documentation for the static DSDT override
 * 11) Documentation for the initrd DSDT override
 * 12) ECDT initialization patch
 * 13) FF button patch
 * 14) acpi4asus homepage
 * 15) kernel fix for R40E hang at boot with ACPI
 * 16) Original Guide on Gentoo Forums

Acknowledgements
Thanks to the ACPI developers, expecially Luming Yu and Bruno Ducrot. All of them have been very helpful and very responsive. In general, the ACPI mailing lists and bugzilla are wonderful resources for ACPI help. Notes

DSDT is specific to BIOS version and Memory configuration. Remember to get new DSDT and fix it when you upgrade BIOS or change Memory configuration. Retrieved from "http://www.gentoo-wiki.info/ACPI/Fix_common_problems"