Difference between revisions of "DSDT"

From ArchWiki
Jump to: navigation, search
(Recompiling it yourself: Some refinement)
(Before you start...: Rename subsections + grammar fixes)
Line 15: Line 15:
 
Even before attempting to fix your DSDT yourself, you can attempt a couple different venues of attack:  
 
Even before attempting to fix your DSDT yourself, you can attempt a couple different venues of attack:  
  
===Alternative #1:===
+
===Tell the kernel to report a version of Windows===
Tell the kernel to report a version of Windows.
+
 
The trick is to use the variable '''acpi_os_name''' as kernel parameter. For example:
+
Use the variable '''acpi_os_name''' as a kernel parameter. For example:
  
 
   acpi_os_name="Microsoft Windows NT"
 
   acpi_os_name="Microsoft Windows NT"
in the kernel line in grub legacy configuration
+
appended to the kernel line in grub legacy configuration
  
other strings to test for:
+
other strings to test:
 
* "Microsoft Windows XP"
 
* "Microsoft Windows XP"
 
* "Microsoft Windows 2000"
 
* "Microsoft Windows 2000"
Line 31: Line 31:
 
* when all that fails, you can even try "Linux"
 
* when all that fails, you can even try "Linux"
  
If that does not work, you can follow the steps below not to recompile or fix your DSDT but just to find out what test is made on the OS inside it and find the string to use as acpi_os_name. Just search for "Microsoft" string in the decompiled DSDT and look at the test made.
+
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file.  Just grep for "Windows" and see what pops up.
  
===Alternative #2:===
+
===Find a fixed DSDT===
Get hold of fixed DSDT.
+
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion.  If you do download a file from the world wide web, it will most likely be a compressed .asl file.  So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you'll need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion.  If you do download a file from the world wide web, it'll most likely be a compressed .asl file, so you'll need to unzip it and compile it. You should really read the Gentoo wiki for that but the upshot is that you won't have to research specific code fixes yourself.
+
  
* Arch users with the same laptop as you: are a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech wizards -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).
+
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).
* Google Is Your Friend: Try keeping it sweet and short - model name and dsdt will probably produce results.
+
Google Is Your Friend. Try keeping it short: 'model name' + 'dsdt' will probably produce results.
  
 
== Recompiling it yourself ==
 
== Recompiling it yourself ==

Revision as of 17:36, 8 July 2012

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:DSDT#)

DSDT (Differentiated System Description Table) is a part of the ACPI specification and it supplies configuration information about a base system. ACPI capable computers come with a DSDT in firmware from the manufacturer. A common Linux problem is missing ACPI functionality (fans not running, screens not turning off when the lid is closed, etc.) stemming from DSDTs made with Windows specifically in mind. The solution that this article will try to detail is replacing the default DSDT with a 'fixed' version. Note that this fix can also be accomplished during installation ("Will you need support for custom DSDT?") but requires you to have a custom DSDT ready at hand.

Note: It is possible that your hardware manufacture has released updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it can fix the problem without needing to apply a separate fix for each operating system installed.
Note: The goal of the Linux ACPI project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider submiting a bug report.

Before you start...

This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to clone your disk beforehand.

Even before attempting to fix your DSDT yourself, you can attempt a couple different venues of attack:

Tell the kernel to report a version of Windows

Use the variable acpi_os_name as a kernel parameter. For example:

 acpi_os_name="Microsoft Windows NT"

appended to the kernel line in grub legacy configuration

other strings to test:

  • "Microsoft Windows XP"
  • "Microsoft Windows 2000"
  • "Microsoft Windows 2000.1"
  • "Microsoft Windows ME: Millennium Edition"
  • "Windows 2001"
  • "Windows 2006"
  • when all that fails, you can even try "Linux"

Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.

Find a fixed DSDT

A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.

Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk). Google Is Your Friend. Try keeping it short: 'model name' + 'dsdt' will probably produce results.

Recompiling it yourself

Your best resources in this endeavor are going to be The Gentoo wiki article, ACPI Spec homepage, and Linux ACPI Project which supercedes the activity that occurred at acpi.sourceforge.net. In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the Gentoo wiki. You'll need to install iasl to modify code, and be familiar with Kernel_Compilation#Compilation to install it.

What compiled the original code? Check if your system's DSDT was compiled using Intel or Microsoft compiler:

 $ dmesg|grep DSDT 
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel  CALPELLA 06040000 INTL 20060912)
ACPI: EC: Look up EC in DSDT

In case Microsoft's compiler had been used, words INTL would instead be MSFT. In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is working the way it should.

1.) Extracting ACPI tables: cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

2.) Decompile: iasl -d dsdt.dat

3.) Recompile: iasl -tc dsdt.dsl

4.) Examine errors and fix:

e.g.:
dsdt.dsl   6727:                         Name (_PLD, Buffer (0x10)  
Error    4105 -          Invalid object type for reserved name ^  (found BUFFER, requires Package) 
 nano +6727 dsdt.dsl
(_PLD, Package(1) {Buffer (0x10)...

5.) Compile fixed code: iasl -tc dsdt.dsl (Might want option -ic for C include file to insert into kernel source)

If it says no errors and no warnings you should be good to go.