Difference between revisions of "DSDT"

From ArchWiki
Jump to: navigation, search
m
(41 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 
[[Category:Boot process]]
 
[[Category:Boot process]]
[[Category:Kernel (English)]]
+
[[Category:Kernel]]
[[Category: Power management (English)]]
+
[[Category:Power management]]
{{Poor writing}}
+
{{Article summary start}}
{{Out of date}}
+
{{Article summary text|Describes DSDT, part of ACPI specification.}}
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|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. AFAICT there is no difference between using the installation method and doing it later.
+
{{Article summary heading|Related}}
 +
{{Article summary wiki|ACPI modules}}
 +
{{Article summary wiki|acpid}}
 +
{{Article summary end}}
 +
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.
  
{{Note|It is possible that your hardware manufacture has released updated firmware which fixes ACPI related problems.  Installing an updated firmware is often perfected over this method because it can fix the problem without needing to apply a separate fix for each operating system installed.}}
+
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]]. }}
  
==Replacing the DSDT==
+
==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 [[Disk cloning | clone your disk]] beforehand.
 +
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts:
  
==="Lions and tigers and bears, oh my!"===
+
===Tell the kernel to report a version of Windows===
This fix does mess about with some fairly fundamental stuff on your Arch install. However, note that ''as long as you can restart your Arch install (e.g. using the fallback image), nothing about what this howto describes is irreversible''. See the section 'Recovery' for details. If you're very unsure, you might wish to [[Disk cloning | clone your disk]] beforehand.
+
  
=== Step zero ===
+
Use the variable '''acpi_os_name''' as a kernel parameter. For example:
Even before attempting to fix your DSDT, you can attempt a simple trick: tell the kernel to report a Windows system to the ACPI subsystem to work around test made inside the DSDT that check for a Windows system and else use some broken code and/or parameter.
+
 
+
The trick is to use the variable '''acpi_os_name''' as kernel parameter. For example:
+
  
 
   acpi_os_name="Microsoft Windows NT"
 
   acpi_os_name="Microsoft Windows NT"
in the kernel line in grub configuration
 
  
other strings to test for:
+
Or
 +
 
 +
  acpi_osi="!Windows2012"
 +
appended to the kernel line in grub legacy configuration
 +
 
 +
other strings to test:
 
* "Microsoft Windows XP"
 
* "Microsoft Windows XP"
 
* "Microsoft Windows 2000"
 
* "Microsoft Windows 2000"
Line 30: Line 37:
 
* "Windows 2001"
 
* "Windows 2001"
 
* "Windows 2006"
 
* "Windows 2006"
* and out of desperation, you can even try "Linux"
+
* "Windows 2009"
 +
* "Windows 2012"
 +
* 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.
  
===Step one: Get hold of fixed DSDT===
+
===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'll need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some guy on the Internet is up to you.
+
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.
==== "Compiling it yourself" ====
+
In short, you can use Intel's ASL compiler (in the repos) to turn your systems DSDT table (residing in /sys/firmware/acpi/tables/DSDT) into source code, locate and fix the errors (the compiled files will typically have been made using Microsoft's compiler rather than Intel's more stringent one... need we say more?), and recompile. This process is detailed far more comprehensively and better at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki]. It's well written and the process is a lot easier than it sounds and far faster than reading about it.
+
  
First check if your system's DSDT was compiled using Intel or Microsoft compiler:
+
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).
<pre> ~ [23:03:39] > dmesg|grep DSDT
+
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.
 +
 
 +
== Recompiling it yourself ==
 +
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems  The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ 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 [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].
 +
You'll need to install {{Pkg|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:
 +
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |
 
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel  CALPELLA 06040000 INTL 20060912)
 
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel  CALPELLA 06040000 INTL 20060912)
 
ACPI: EC: Look up EC in DSDT
 
ACPI: EC: Look up EC in DSDT
</pre>
+
}}
Mine's compiled using Intel's compiler (Phew.!). In case Microsoft's compiler had been used, words INTL would have replaced by MSFT.
+
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.
I still got 5 errors on decompiling/recompiling the DSDT. 2 were easy to fix after a bit of googling and delving into the ACPI specification. 3 of them were due to different versions of compiler used and are, as I found out later, 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 if 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''.
 +
 
 +
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}
 +
 
 +
2.) Decompile: {{ic|iasl -d dsdt.dat}}
 +
 
 +
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}
 +
 
 +
4.) Examine errors and fix. e.g.:{{bc|
 +
dsdt.dsl  6727:                        Name (_PLD, Buffer (0x10) 
 +
Error    4105 -          Invalid object type for reserved name ^  (found BUFFER, requires Package) }}
 +
{{hc| nano +6727 dsdt.dsl|
 +
(_PLD, Package(1) {Buffer (0x10)...}}
 +
 
 +
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try 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.
 +
 
 +
== Using modified code ==
 +
{{Expansion| Detail each method}}
 +
 
 +
There are 2 ways to use a custom DSDT Table:
 +
* compiling the custom DSDT into the kernel
 +
* loading the custom DSDT at runtime (not supported)
 +
 
 +
=== Compile into kernel ===
 +
You'll want to be familiar with [[Kernels | compiling your own kernel]].  The most straightforward way is with the "traditional" approach.
 +
After compiling DSDT, iasl produce two files: {{ic|dsdt.hex}} and {{ic|dsdt.aml}}.
 +
 
 +
'''Using {{ic|menuconfig}}:'''
 +
* Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".
 +
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file ({{ic|dsdt.hex}}, not {{ic|dsdt.aml}}). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".
 +
 
 +
 
 +
'''Check if you running custom DSDT'''
 +
 
 +
Simply type
 +
{{ic|<nowiki>dmesg | grep DSDT</nowiki>}}
 +
 
 +
You will see something like that:
 +
{{bc|<nowiki>[    0.000000] ACPI: Override [DSDT-  A M I], this is unsafe: tainting kernel
 +
[    0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0
 +
[    0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA    A M I 000000F3 INTL 20130517)</nowiki>}}
 +
If you see {{ic|...ACPI: Override...}}, you're running custom DSDT.
 +
 
  
==== "Some guy on the internet" ====
+
=== Loading at runtime ===
* There is a database of sorts of user produced fixes on sourceforge: http://acpi.sourceforge.net/dsdt/. Sadly, this is not very well maintained and more than half the entries are just weird noise spam. If you do download a file from there, 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: get iasl from the community repo, unzip the file into a directory of its own and run
+
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}
<pre>iasl -tc ''.asl/.dsl file''</pre>
+
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:
on it and if it says no errors and no warnings you should be good to go.
+
/boot/dsdt.aml
* 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 (Ubuntu) or because they're tech wizards (Gentoo?) 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.
+
  
Remember, regardless of how you get a file, you'll need a compiled ACPI Machine Language file for the next step.
+
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.
 +
Copy the following to '''/etc/grub.d/01_acpi'''
  
===Step Two: Get the file loaded at startup===
+
#!/bin/sh
mkinitcpio provides a hook to use a custom dsdt table. See below for instructions.
+
set -e
  
==== Creating a new boot image ====
+
# Uncomment to load custom ACPI table
* Cp your compiled file to /lib/initcpio/custom.dsdt
+
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"
* Add 'dsdt' to the end of HOOKs array in /etc/mkinitcpio.conf
+
* Run mkinitcpio as root.
+
  # mkinitcpio -p linux
+
# DON'T MODIFY ANYTHING BELOW THIS LINE!
will create both the standard and the fallback image. If you're feeling less adventurous, you might wish to first try
+
  # mkinitcpio -g /boot/initramfs-linux.img
+
which will only create the standard image, so you can... well fall back on the other one in case things do not work out. If/when they do work out, you can always run the command with the -p option after the first test.
+
prefix=/usr
 +
exec_prefix=${prefix}
 +
libdir=${exec_prefix}/lib
 +
 +
 +
. /usr/share/grub/grub-mkconfig_lib
 +
  #. ${libdir}/grub/grub-mkconfig_lib
 +
 +
 +
  # Load custom ACPI table
 +
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \
 +
        && is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then
 +
    echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2
 +
    prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"
 +
    cat << EOF
 +
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`
 +
EOF
 +
fi
  
=== Step three: Test your new image ===
+
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''
If mkinitcpio succesfully created an image, you should be ready to reboot now. If things go well, you'll boot into your ordinary Arch setup, the only difference being a properly working fan, lid, whatever misbehaved. If they do not
+
chmod +x /etc/grub.d/01_acpi
* Make a note of the error messages
+
* Restart
+
* Choose the fallback image option from GRUB (assuming you didn't overwrites that one too)
+
  
====Recovery from a bad image====
+
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).
Remove the dsdt hook from /etc/mkinitcpio.conf, delete the custom.dsdt file and use mkinitcpio to create the images again:
+
Next you will need a new boot image. If you use GRUB run:
  # mkinitcpio -p linux
+
  grub-mkconfig -o /boot/grub/grub.cfg
  
If you want to persist, try one of the following:
+
Lastly, recreate your initrd
* Read the other wiki articles (really) and try again.
+
mkinitcpio -p linux
* Try forums (again)
+
and reboot. Done!
* Read/edit wiki
+
* Leave distro in anger, vow revenge
+
  
== External Links ==
+
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}
* [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems  The Gentoo wiki article]
+
and decompile it with {{ic|iasl -d dsdt.dat}}
* [http://acpi.sourceforge.net/dsdt/index.php The sourceforge database]
+

Revision as of 09:28, 27 July 2013

Summary help replacing me
Describes DSDT, part of ACPI specification.
Related
ACPI modules
acpid

DSDT (Differentiated System Description Table) is a part of the 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 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...

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

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

1.) Extract ACPI tables (as root): # 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 to try 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.

Using modified code

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Detail each method (Discuss in Talk:DSDT#)

There are 2 ways to use a custom DSDT Table:

  • compiling the custom DSDT into the kernel
  • loading the custom DSDT at runtime (not supported)

Compile into kernel

You'll want to be familiar with compiling your own kernel. The most straightforward way is with the "traditional" approach. After compiling DSDT, iasl produce two files: dsdt.hex and dsdt.aml.

Using menuconfig:

  • Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".
  • Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file (dsdt.hex, not dsdt.aml). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".


Check if you running custom DSDT

Simply type dmesg | grep DSDT

You will see something like that:

[    0.000000] ACPI: Override [DSDT-   A M I], this is unsafe: tainting kernel
[    0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0
[    0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA    A M I 000000F3 INTL 20130517)

If you see ...ACPI: Override..., you're running custom DSDT.


Loading at runtime

Warning: Loading at runtime don't supports. DSDT hook removed due to bug, see FS#27906 bug

Luckily the Arch stock kernel supports using a custom DSDT so, first copy the .aml file compiled by iasl to:

/boot/dsdt.aml

The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image. Copy the following to /etc/grub.d/01_acpi

#!/bin/sh
set -e
# Uncomment to load custom ACPI table
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"


# DON'T MODIFY ANYTHING BELOW THIS LINE!


prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib


. /usr/share/grub/grub-mkconfig_lib
#. ${libdir}/grub/grub-mkconfig_lib


# Load custom ACPI table
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \
        && is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then
    echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2
    prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/  /"
    cat << EOF
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`
EOF
fi

Make sure to make this file executable, or it will be ignored by grub-mkconfig

chmod +x /etc/grub.d/01_acpi

This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file). Next you will need a new boot image. If you use GRUB run:

grub-mkconfig -o /boot/grub/grub.cfg

Lastly, recreate your initrd

mkinitcpio -p linux

and reboot. Done!

To check if you are really using your own DSDT read your table again # cat /sys/firmware/acpi/tables/DSDT > dsdt.dat and decompile it with iasl -d dsdt.dat