DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.

DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.

+

+

Basically a DSDT table is the code run on ACPI (Power Management) events.

{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ 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 [[Reporting Bug Guidelines|submiting a bug report]]. }}

{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ 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 [[Reporting Bug Guidelines|submiting a bug report]]. }}

Line 16:

Line 24:

acpi_os_name="Microsoft Windows NT"

acpi_os_name="Microsoft Windows NT"

+

+

Or

+

+

acpi_osi="!Windows2012"

appended to the kernel line in grub legacy configuration

appended to the kernel line in grub legacy configuration

Line 26:

Line 38:

* "Windows 2006"

* "Windows 2006"

* "Windows 2009"

* "Windows 2009"

+

* "Windows 2012"

* when all that fails, you can even try "Linux"

* when all that fails, you can even try "Linux"

Line 47:

Line 60:

ACPI: EC: Look up EC in DSDT

ACPI: EC: Look up EC in DSDT

}}

}}

−

In case Microsoft's compiler had been used, words INTL would instead be MSFT.

+

In case Microsoft's compiler had been used, abbreviation 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.

+

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

Basically a DSDT table is the code run on ACPI (Power Management) events.

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.

Contents

Before you start...

It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.

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 of different shortcuts:

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"

Or

acpi_osi="!Windows2012"

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"

"Windows 2009"

"Windows 2012"

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).
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.

In case Microsoft's compiler had been used, abbreviation 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.