Difference between revisions of "DSDT"
(remove language suffix from Category:Power management (English), see Talk:Table of Contents#English Category Names: Capitalization and Conflict with i18n)
(remove language suffix from Category:Kernel (English), see Talk:Table of Contents#English Category Names: Capitalization and Conflict with i18n)
|Line 1:||Line 1:|
Revision as of 17:21, 23 April 2012
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. AFAICT there is no difference between using the installation method and doing it later.
- 1 Replacing the DSDT
- 2 External Links
Replacing the DSDT
"Lions and tigers and bears, oh my!"
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 clone your disk beforehand.
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"
in the kernel line in grub configuration
other strings to test for:
- "Microsoft Windows XP"
- "Microsoft Windows 2000"
- "Microsoft Windows 2000.1"
- "Microsoft Windows ME: Millennium Edition"
- "Windows 2001"
- "Windows 2006"
- and out of desperation, 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.
Step one: 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'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.
"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 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:
~ [23:03:39] > dmesg|grep DSDT ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912) ACPI: EC: Look up EC in DSDT
Mine's compiled using Intel's compiler (Phew.!). In case Microsoft's compiler had been used, words INTL would have replaced by 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.
"Some guy on the internet"
- 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
iasl -tc ''.asl/.dsl file''
on it and if it says no errors and no warnings you should be good to go.
- 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.
Step Two: Get the file loaded at startup
mkinitcpio provides a hook to use a custom dsdt table. See below for instructions.
Creating a new boot image
- Cp your compiled file to /lib/initcpio/custom.dsdt
- Add 'dsdt' to the end of HOOKs array in /etc/mkinitcpio.conf
- Run mkinitcpio as root.
# mkinitcpio -p linux
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.
Step three: Test your new image
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
- Make a note of the error messages
- Choose the fallback image option from GRUB (assuming you didn't overwrites that one too)
Recovery from a bad image
Remove the dsdt hook from /etc/mkinitcpio.conf, delete the custom.dsdt file and use mkinitcpio to create the images again:
# mkinitcpio -p linux
If you want to persist, try one of the following:
- Read the other wiki articles (really) and try again.
- Try forums (again)
- Read/edit wiki
- Leave distro in anger, vow revenge