HOWTO: Fix Common ACPI Problems (DSDT, ECDT, etc.)

[jetblack]

HOWTO: Fix Common ACPI Problems (DSDT, ECDT, etc.)

NOTE (2009-11-09): This guide is coming up on 6 years old, so it's probably pretty outdated, especially where kernel options and such are concerned. Some of the links are also stale.

For the past few weeks, I've been wrestling with ACPI on my laptop (a Gateway 200X). 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.


Table of Contents

1. Revisions
2. Definitions
3. Description of the Problem
4. Disclaimer
5. Tested Kernels (DSDT override)
6. What you'll need to fix your DSDT
7. Diagnosing a Buggy DSDT
8. Fixing the DSDT
9. Incorporating the fixed DSDT into the kernel
   1. Static DSDT override
   2. initrd DSDT override
   3. initrd override with bootsplash
10. My DSDT is fixed, but I still have ACPI errors. Now what?
    1. Windows-only DSDT functionality
    2. Missing ECDT
    3. My power and/or sleep buttons don't work
    4. My BIOS is blacklisted
    5. I have an Asus laptop
    6. It's still not working!
11. Useful ACPI resources
12. Acknowledgements

1. Revisions

Code: Select all

01/08/2004
  * Added three new sections:
     1. Revisions
     2. Definitions
     3. Description of the Problem

01/09/2004
  * Tested with some 2.6 kernels
  * Added initrd patch section, corrected misinformation about bootsplash and initrd DSDT (it does work)
  * Reformatted to conform better to the guidelines
  * Added links to HOWTOs with fixes for common DSDT errors
  * Added fixes for warnings to the main doc[/list]

01/10/2004
  * Added missing ACPI resource links
  * Corrected numerous typos

01/11/2004
  *Added Disclaimer section

01/12/2004
  * Added explanation of "Return(Package(0x02){0x00, 0x00})" fix for _WAK method warning.

01/13/2004
  * Modified Intel iasl links to point to the main download page. Thanks, Moled.

01/14/2004
  * Clarified Description of the Problem, included Microsoft compiler information. Thanks, Kesereti.
  * Added link to the acpi.sourceforge.net DSDT Repository to section 8.

01/25/2004
  * Added a couple paragraphs about acpi_os_name boot parameter to section 8.
  * Added new section for ECDT, acpi_os_name and ff button problems
  * Added a couple more links to patches
  * Removed To Do section, since it's all done.
  * Renamed, because this has evolved into more of a general ACPI HOWTO

01/26/2004
  * Clarified section 10a (Windows-only DSDT functionality)

02/02/2004
  * Reformatted revisions as code block so they don't take up so much space.
  * Added blacklisted BIOS section.
  * Added acpi4asus section.
  * Added brief information about some other acpi boot parameters to Section 10f.

2. 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 Basically, what this boils down to is that 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.


3. 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.


*Kernel happiness not guaranteed. The author does not take responsibility for surly kernels.

4. 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.


5. 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)

6. What you'll need to fix your 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 acpi.sourceforge.net (if using vanilla sources).
3. The Intel asl compiler, available here.
   and EITHER
4. The static DSDT override patch (tested with kernels 2.4.23 and above), available here
   OR
5. The initrd DSDT override patch appropriate for your kernel, avaliable here

7. 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. First, let's get the compiler ready:

1. Get the iasl compiler here.
2. su to root (not really necessary yet, but you'll need to be root eventually, so why not?)
3. Extract the iasl compiler to a directory somewhere.
   

   Code: Select all

   tar -xvzf iasl-linux-20030228.tar.gz

4. Enter the newly created directory. You should see a file called iasl. That's the compiler. For simplicity, I'll assume that the rest of the diagnostic steps are done from this directory.
   

   Code: Select all

   cd iasl-linux-20030228
   ls
   >> AslCompiler.pdf     iasl

   Now we need to get the current DSDT, disassemble it and recompile it to see if we get any errors.
5. Extract your current DSDT to a file as follows:

   Code: Select all

   cat /proc/acpi/dsdt > dsdt.dat

   This will give you a file, 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.
6. Disassemble the DSDT

   Code: Select all

   ./iasl -d dsdt.dat

   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, again with iasl.
7. Recompile the DSDT.

   Code: Select all

   ./iasl -tc dsdt.dsl

   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:

Code: Select all

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

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

dsdt.dsl  2626:                     Field (ECR, DWordAcc, Lock, Preserve)
Error    1048 -                              ^ Host Operation Region requires ByteAcc access

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

ASL Input:  dsdt.dsl - 3759 lines, 123154 bytes, 1862 keywords
Compilation complete. 1 Errors, 2 Warnings, 0 Remarks, 390 Optimizations

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.


8. Fixing 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:

Code: Select all

dsdt.dsl  2626:                     Field (ECR, DWordAcc, Lock, Preserve)
Error    1048 -                              ^ Host Operation Region requires ByteAcc access

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:

1. Edit dsdt.dsl

   Code: Select all

   vi dsdt.dsl

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

   Code: Select all

   Field (ECR, DWordAcc, Lock, Preserve)

   to this

   Code: Select all

   Field (ECR, ByteAcc, Lock, Preserve)

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

   Code: Select all

   ./iasl -tc dsdt.dsl

   Now, when I recompile, I get the following:

   Code: Select all

   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
   
   dsdt.dsl   163:     Method (_WAK, 1, NotSerialized)
   Warning  2026 -                ^ Reserved method must return a value (_WAK)
   
   dsdt.dsl  2672:                     Method (_GLK, 1, NotSerialized)
   Warning  2024 -                                ^ Reserved method has too many arguments ( _GLK requires 0)
   
   ASL Input:  dsdt.dsl - 3759 lines, 123153 bytes, 1862 keywords
   AML Output: DSDT.aml - 14600 bytes 499 named objects 1363 executable opcodes
   
   Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 390 Optimizations
   

   Alright! The error is gone. The warnings are still there, though. Let's get rid of them now, too.
4. Repeat steps 1-3 for the warnings
   
   The second warning seems to be the easier one:

   Code: Select all

   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:

   Code: Select all

   Method (_GLK, 1, NotSerialized)

   to this:

   Code: Select all

   Method (_GLK)

   Recompiling now only gives me the one warning:

   Code: Select all

   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:

   Code: Select all

   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.
   

   Code: Select all

   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.

   Code: Select all

   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)
   

   Code: Select all

   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.


9. Incorporating the fixed DSDT into the kernel

There are two 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 kenel at boot time as an initrd. 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:

9a. 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.

1. Obtain DSDT override patch from here
2. Save the file to your machine. Let's call it dsdt_override.diff.
3. 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.

   Code: Select all

   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.
4. Copy dsdt.hex to the kernel source tree.

   Code: Select all

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

5. 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 <linux>/include/acpi/dsdt_table.h and recompile your kernel.


9b. 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.

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

   Code: Select all

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

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

   Code: Select all

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

4. Make sure that the new "Read DSDT from initrd" option is selected under the ACPI menu

   Code: Select all

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

5. 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.
6. Copy the fixed DSDT.aml to /boot:

   Code: Select all

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

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

   Code: Select all

   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.


9c. 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.

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

   Code: Select all

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

2. Append the DSDT signature to the initrd

   Code: Select all

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

3. cat the fixed DSDT.aml into the initrd

   Code: Select all

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

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

   Code: Select all

   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.

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).


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

10a. 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:

Code: Select all

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:

Code: Select all

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.


10b. 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:

Code: Select all

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.


10c. My 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:

Code: Select all

ACPI: 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:

Code: Select all

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:

Code: Select all

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.


10d. 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:

Code: Select all

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:

Code: Select all

{"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).


10e. I have an Asus laptop

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.


10f. It's still not working!

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.

11. Useful ACPI resources

There are a number of good ACPI resources, in case you get stuck. The ones that I found most helpful were:

• bugzilla.kernel.org
• acpi.sourceforge.net
• acpi-devel and acpi-bugzilla mailing lists
• www.acpi.info (the ACPI spec is here, including ASL documentation, which is the language used for the DSDT)
• The Intel ACPI downloads page - get the iasl compiler here.
• HOWTO fix common DSDT errors
• DSDT fixes for the Thinkpad T31
• DSDT repository at acpi.sourceforge.net
• DSDT submission page at acpi.sourceforge.net.
• Documentation for the static DSDT override
• Documentation for the initrd DSDT override
• ECDT initialization patch
• FF button patch
• acpi4asus homepage

12. Acknowledgements

I'd like to thank 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.

[jetblack]

Added a couple of sections that I was too lazy to write last night.

Apologies for the bump.

[jetblack]

In response to the *ahem* overwhelming demand , I've added a section for the initrd DSDT override method, along with some new tested kernels and other changes. I think that that about wraps it up for the DSDT override, unless someone finds some errors in the doc.

[jay]

This is what I'm getting from recompiling my DSDT on my ASUS M2400A
Laptop:

Code: Select all

./iasl -tc l84f-dsdt.dsl
 
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
 
l84f-dsdt.dsl   966:     Method (\_WAK, 1, NotSerialized)
Warning  2026 -                      ^ Reserved method must return a value (_WAK )
 
l84f-dsdt.dsl  1281:             Method (INIT, 1, NotSerialized)
Warning  2019 -                             ^ Not all control paths return a val ue (INIT)
 
l84f-dsdt.dsl  2939:                     Method (S_TM, 3, NotSerialized)
Warning  2019 -                                     ^ Not all control paths retu rn a value (S_TM)
 
ASL Input:  l84f-dsdt.dsl - 4851 lines, 155658 bytes, 2284 keywords
AML Output: DSDT.aml - 21243 bytes 608 named objects 1676 executable opcodes
 
Compilation complete. 0 Errors, 3 Warnings, 0 Remarks, 625 Optimizations

You max notice that the warnings look exactly like yours. Maybe we can fix these as well?

[jetblack]

May as well give it a shot!

As an aside, I've managed to get rid of the "too many arguments" warning I had. It doesn't correspond to your warnings, but I'll include it just for the sake of documentation, in case someone else comes across it.

[EDIT] Details moved to main doc [/EDIT]

So, now when I recompile, I only have the _WAK method warning:

Code: Select all

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

[EDIT] _WAK method warning fixed. See following post and main doc [/EDIT]

[jetblack]

Well, that didn't take very long

I found a couple of HOWTOs for common DSDT problems. They are here and here. I'll add them to the main doc.

It turns out that both of your warnings have the same solution. Just add this line to the end of the methods in question:

Code: Select all

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

Doing that got rid of my _WAK warning. I don't have the "Not all control paths return a value" Warning, so I can't test that. If I can figure out why that is the proper line, I'll let you know

[rabidsg]

alright, so quick question, from my dsdt.dat decompiled, I basically see these 4 comprise about 47 warnings, with 0 errors...

also, is it worth fixing them, as they're only warnings, with what im guessing is a superficial fix to give them some return so they don't complain, will fixing them actually do something?

dsdt.dsl 2069: Method (_STA, 0, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_STA)

dsdt.dsl 2074: Method (_CRS, 0, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_CRS)

dsdt.dsl 2079: Method (_PRS, 0, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_PRS)

dsdt.dsl 2104: Method (_PSC, 0, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_PSC)

so to fix, im assuming I'm suppose to add, the line

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

one of the corresponding lines is

Method (_STA, 0, NotSerialized)
{
STAL (0x60)
Return (Package(0x02){0x00,0x00})
}

should it now be

Method (_STA, 0, NotSerialized)
{
STAL (0x60)
}

or

Method (_STA, 0, NotSerialized)
{
Return (Package(0x02){0x00,0x00})
}

[crazy-bee]

Great document. Really cool work !!!

I was so desperate I fixed the 3 warning. Worked perfectly. Unfortunately, it doesnt change anything at the current situation. Suspend-to-ram does not work (doesnt resume), and neither pmdisk or the other suspend to disk method works for me in 2.6.x. That really sucks.

[jetblack]

rabidsg

Yeah, I think that this really is just a placeholder value, just to get the warnings to shut up. At least for the _WAK method, it sounds like the ACPI drivers don't even check the return value of the method, even though it's supposed to return one. I guess that's why it's a warning and not an error. It shouldn't hurt to add that line, but I don't think that it will restore any missing functionality. If you like, you could post a link to your DSDT and I could look over it. I'm not an expert or anything, but maybe there are some methods missing or something that woud jump out. Your dmesg output seems to suggest that. You also mentioned that you think your laptop suports ACPI 1.0. Perhaps that's the root of the trouble. I'm not sure what the differences are (if any) in supported functionality from 1.0 to 2.0. I've only been focusing on the 2.0 spec so far.

crazy-bee

Thanks
I haven't had a whole lot of success with suspend/resume either. I haven't played with it too much, though. I can tell you that the mailing lists are riddled with this kind of problem. I've seen a couple of suggestions for things to try. The main ones appear to be:

- unload all modules before suspending
- try it first without running X

I plan to dig into suspend/resume a bit more over the next week, so I'll let you know if I get any better information.

[Kesereti]

Hrm...any suggestions on what to do when the dumped DSDT re-compiles cleanly with the Intel compiler (on a Gateway M350 if you're wondering...looks like they might have fixed it, since I get no errors on the compile), but you still are missing features? The battery status (/proc/acpi/battery exists, but is empty), in particular...some error about no handler for a region [ERAM] pops up on boot before the AE_NOT_EXIST errors regarding BAT0 =\ This is on 2.6.1-love1 kernel, by the way...

Specifically:

Code: Select all

evregion-0251 [21]ev_address_space_dispa: No handler for Region [ERAM] (df652c28)[EmbeddedControl] 
exfldio-0284 [20] ex_access_region      : Region EmbeddedControl(3) has no handler 
dswexec-0435 [13] ds_exec_end_op        : [LGreater]: Could not resolve operands, AE_NOT_EXIST 
psparse-1120: *** Error: Method execution failed [\_SB_.PCI0._INI](Node df657528), AE_NOT_EXIST  
nsinit-0408 [06] ns_init_one_device    : \_SB_.PCI0._INI failed:AE_NOT_EXIST
evregion-0251 [21] ev_address_space_dispa: No handler for Region [ERAM](df652c28) [EmbeddedControl] 
exfldio-0284 [20] ex_access_region      : Region EmbeddedControl(3) has no handler 
psparse-1120: *** Error: Method execution failed [\_SB_.BAT0._STA](Node df658428), AE_NOT_EXIST

Immediately following the "Executing all Device _STA and_INI methods:........" portion of bootup...the other thing I noticed is that after these errors, there's the notation "58 Devices found containing: 58 _STA, 0 _INI methods" immediately after the errors...shouldn't there be *some* _INI methods? Hence the errors about \_SB_.PCI0._INI not existing and whatnot...or would these be found if the first error (about the EmbeddedControl and ERAM) fix that, do you think?

[jetblack]

Ah, that could be the ever-popular "BIOS does not provide an ECDT" issue (don't you just love all of these acronyms? ). That was at the core of my battery problems, too. Even after I fixed my DSDT, I still didn't have battery and ac adapter information until I applied another kernel patch.

Basically, the system needs some preliminary information about the Embedded Control before it is actually parsed from the DSDT. The BIOS is supposed to provide this in the form of an ECDT, but on some systems it doesn't. There is a patch somewhere (I can't remember exactly where, and I'm about to fall asleep, so I'll check in the morning) that is supposed to allow you to supply an ECDT similarly to the initrd DSDT method here. I tried it without much success. This patch is the one that I am using to get around the problem. It provides a workaround that parses the Embedded Control region of the DSDT a bit early, but it doesn't work with the 2.6 kernels. It may be worth grabbing 2.4.24 and applying the patch just to see if you get battery info from it. Maybe this is a common Gateway issue.

[EDIT]
Ah, I see you're a step ahead of me. Let me know how that works out

[Kesereti]

I actually managed to apply the patch to fake a table by hand to the 2.6.1 kernel tree...there really wasn't much different, to be honest, just that some things weren't line for line what the patch expected them to be =) I went through and got the necessary information for the fake table (0x66, 0x62, 0x1d, 0x01 were the four hex addresses in my case...the last two being GPE and UID), added the line to my grub.conf, and it didn't seem to do anything...should there be any debug output to indicate the fake table was accepted? Or any output of any sort? Because either I didn't quite patch it as successfully as I thought I did, and it's not doing anything, or the change doesn't help even after loading the fake table =P

Edit: Same effect (or lack thereof =P) when applied to gentoo-sources 2.4.22-r4 =\

[jetblack]

Hm. I think that there was a line in dmesg after applying the fake ECDT patch. It was subtle, something like "Using fake ecdt" or something like that. Then, if it fails, it will say "couldn't use fake ECDT". I never had much success with that patch, though. The one I linked to above is slightly different, and perhaps a bit more involved to incorporate into the 2.6 kernels, but we'll see. That's my project for today

[crazy-bee]

jetblack: I guess I've read so much stuff about suspend, I cant remeber everything. Of course I tried without X and with 0 modules loaded, no success. I'd be happy if suspend-to-disk would work, to-ram is a dream I guess.
The thing I *really* dislike is suspend-to-disk (pmdisk) did work for me *perfectly* under x11, with 3d acceleration, with usb and pcmcia modules. This was some 2.6.0-test5 version. I really hate that, instead of "bug fixing", kernel always introduces new bugs and things that did work fine are broken with newer versions. Behaviour of the suspend-to-disk changes with every new kernel now, sometimes, it wont even suspend, the next version, it suspends fine, but when i restart it, it hangs, next version it reboots after resuming. *Sigh*

But your documentation is still great!

[Kesereti]

Well, with a few tweaks, I managed to get the fake_ecdt patch applied to 2.6.1-love2 ... the major difference being that they totally overhauled the scheduler in 2.6, so many of the functions and methods that were used to schedule tasks in 2.4 don't work the same in 2.6 =\ It compiles cleanly, and even gives me battery status now! Only...I somehow managed to break the ACPI event model in doing so -- acpid is no longer receiving events, and by killing it and manually cat'ing /proc/acpi/event, I can see that events aren't being generated at all anymore =\ I can post a diff file so that others can test it on 2.6 if there's a desire for it, but since it just breaks ACPI in different ways, I don't know if anyone would want that =P Anyone with knowledge of the 2.6 kernel scheduler and task model want to help me out with this one? Hehe ^_^

[jetblack]

Ah, well that sounds both good and not-so-good at the same time

I wasn't able to apply the other EC patch to 2.6 - the changes to bus.c were more extensive than I had hoped that they would be, so I'll have to learn a bit more about what's actually going on before I can get that to work. Though, it does sound like they may be working on a "suitable for prime-time" version of the patch for inclusion in the 2.6 kernels. Maybe we can race - I wouldn't put my money on me

I did manage to find out just what that _WAK method DSDT fix is doing.

Code: Select all

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

If anyone is interested, I've added an explanation to section 8 of the doc. The short version - it's a dummy value.

[Kesereti]

See, the problem is, I think, that the fake_ecdt patch that is up on acpi.sourceforge.net isn't just for that -- Ducrot Bruno had mentioned that there were other miscellaneous fixes in that patch for things that needed fixing in 2.4; I'm hoping to get a response from him about which parts exactly are needed for the ECDT faking, so that I can start working on a patch myself -- just passing fake_ecdt= at boot time seems the simplest solution to this particular problem (for machines that do not have an ECDT), and I'd sure like to be the first one to the Gentoo forums with a patch that applies to 2.6 (maybe for inclusion into love-sources? Hehehe ^_^)...

[jetblack]

just passing fake_ecdt= at boot time seems the simplest solution to this particular problem (for machines that do not have an ECDT)

I agree entirely. Now that I think about it, I never did try that patch after I fixed the DSDT. It could be that it was working ok, but the DWordAcc in the ECR was causing problems anyway. Hrm.....

and I'd sure like to be the first one to the Gentoo forums with a patch that applies to 2.6 (maybe for inclusion into love-sources? Hehehe ^_^)...

You have my best wishes. I think I might be a bit out of my depth there, but I'm enjoying playing around with it

[Kesereti]

and I'd sure like to be the first one to the Gentoo forums with a patch that applies to 2.6 (maybe for inclusion into love-sources? Hehehe ^_^)...

You have my best wishes. I think I might be a bit out of my depth there, but I'm enjoying playing around with it

Hehe...I haven't done any sort of kernel programming in a LONG time, and the total overhaul of many parts of the kernel for 2.6 has me rather lost, I must admit =P I mean, I'm pretty sure I converted Bruno's fake_ecdt patch to all the new 2.6 function calls properly, but given that some of it isn't necessary (considering that a big part of the patch is dealing with task queues, which don't even exist in 2.6 anymore =P), it'll probably be at least another few days before I'm able to sort everything out...until then...battery status and no acpid events (which means no automatic fan switching on and off, no cpu throttling, no lid-closed events, etc. =\), or acpid events and no battery status (leaving me clueless about how much charge is left in my battery until the little light starts blinking red letting me know I've got about 5 minutes left =p)...*sigh*...hehehe ^_^

[jetblack]

Well, FWIW, the fake_ecdt patch is working for me now with 2.4.24 and the fixed DSDT. I get an odd error from dmesg that isn't there with the other patch, and it tells me that it can't use the ECDT, but I have all of the ACPI functionality (including my battery and ac adapter, which disappear if I comment out the fake_ecdt parameter in grub.conf), so it's clearly using something. Plus, now I don't have two H_EC subdirectories in my /proc/acpi/embedded_controller directory, and the one that I do have is reporting the proper ports, which is nice. I'll have to check the mailing lists for this error (AE_NOT_EXIST from the embedded controller _REG method, which sounds familiar), but it looks like that ByteAcc was causing more problems than I had thought.

[Moled]

if you look at:
http://developer.intel.com/technology/i ... nloads.htm
a newer version is avaliable than the one linked in your first post:
http://developer.intel.com/technology/i ... 918.tar.gz


things aren't looking good here

Compilation complete. 8 Errors, 10 Warnings, 3 Remarks, 463 Optimizations

this is not a laptop tho, and ive never had any real issues with it

[jetblack]

Thanks, Moled. I've updated the links to just point to the main download page.

If you'd like to post your errors and DSDT here, I'd be happy to give them a look. But, if you aren't noticing any problems, then maybe it isn't such a big deal.

[Moled]

thanks:
fyi, this is the mobo I have:

http://tw.giga-byte.com/MotherBoard/Pro ... -8KNXP.htm

the above errors etc were using the f6 bios
I just updated to f9 (7+8 were broken)
now I have:

Code: Select all

 
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030918 [Sep 18 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
 
dsdt9.dsl   212:     Method (\_WAK, 1, NotSerialized)
Warning  2026 -                  ^ Reserved method must return a value (_WAK)
 
dsdt9.dsl   250:             Store (Local0, Local0)
Error    1013 -                          ^ Method local variable is not initialized (Local0)
 
dsdt9.dsl   255:             Store (Local0, Local0)
Error    1013 -                          ^ Method local variable is not initialized (Local0)
 
dsdt9.dsl  2376:                         Store (Local0, Local0)
Error    1013 -                                      ^ Method local variable is not initialized (Local0)
 
dsdt9.dsl  3933:                     Method (_STM, 0, NotSerialized)
Warning  2025 -                                 ^ Reserved method has too few arguments ( _STM requires 3)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Error    1014 -                     Method argument is not initialized ^  (Arg0)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Remark   3041 -                    Not a parameter, used as local only ^  (Arg0)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Error    1014 -                           Method argument is not initialized ^  (Arg1)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Remark   3041 -                          Not a parameter, used as local only ^  (Arg1)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Error    1014 -                                 Method argument is not initialized ^  (Arg2)
 
dsdt9.dsl  3935:                         Store (\_SB.PCI0.ICHX.STM (Arg0, Arg1, Arg2), Local0)
Remark   3041 -                                Not a parameter, used as local only ^  (Arg2)
 
dsdt9.dsl  3952:                         Method (_GTF, 0, NotSerialized)
Warning  2019 -                                     ^ Not all control paths return a value (_GTF)
 
dsdt9.dsl  3952:                         Method (_GTF, 0, NotSerialized)
Warning  2026 - Reserved method must return a value ^  (_GTF)
 
dsdt9.dsl  3969:                         Method (_GTF, 0, NotSerialized)
Warning  2019 -                                     ^ Not all control paths return a value (_GTF)
 
dsdt9.dsl  3969:                         Method (_GTF, 0, NotSerialized)
Warning  2026 - Reserved method must return a value ^  (_GTF)
 
dsdt9.dsl  4017:                             If (LEqual (Local3, 0x03))
Error    1013 -      Method local variable is not initialized ^  (Local3)
 
dsdt9.dsl  4092:                             If (LEqual (Local3, 0x05))
Error    1013 -      Method local variable is not initialized ^  (Local3)
 
dsdt9.dsl  4111:                         Method (_GTF, 0, NotSerialized)
Warning  2019 -                                     ^ Not all control paths return a value (_GTF)
 
dsdt9.dsl  4111:                         Method (_GTF, 0, NotSerialized)
Warning  2026 - Reserved method must return a value ^  (_GTF)
 
dsdt9.dsl  4128:                         Method (_GTF, 0, NotSerialized)
Warning  2019 -                                     ^ Not all control paths return a value (_GTF)
 
dsdt9.dsl  4128:                         Method (_GTF, 0, NotSerialized)
Warning  2026 - Reserved method must return a value ^  (_GTF)
 
ASL Input:  dsdt9.dsl - 4570 lines, 145464 bytes, 1868 keywords
Compilation complete. 8 Errors, 10 Warnings, 3 Remarks, 448 Optimizations

i'm off for a few days and will have a look at it when I get back

have fun + thanks

[jetblack]

Thanks! I'm not sure if I'll catch you in time, but could you post the DSDT, too? Some of these will be easier to diagnose with it.

[Moled]

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

now would that be what I think it is? :/




ill sort it myself when I get back, I might learn something in the process