HOWTO Fix A Buggy DSDT File

**67GTA** · January 10th, 2009

This guide will help you fix your DSDT file to fix common ACPI problems on any Debian based OS. With Mint 6/Ubuntu 8.10, I started having a lot of problems with my laptop thermal temps, and not wanting to boot without holding down a keyboard key. This was in my case because of a buggy DSDT file. To read more about ACPI/DSDT go here: http://forums.opensuse.org/how-faq-r...uggy-dsdt.html It is the catalyst behind this how to. The process is a little different for Debian based operating systems. This how to will show you how to do it with Mint/Ubuntu.

WARNING: This might mess up your operating system. Even if you have zero errors after fixing the DSDT, it may still cause you to not be able to boot your OS. It will not harm your PC or hardware.

Before trying this tutorial, try updating your BIOS to fix bugs first. This is a last resort to try and manually fix DSDT related bugs.

The first thing we need to do is install the Intel DSDT compiler. Open a terminal and run

Code:

sudo apt-get install iasl

Then we need to get a copy of your current DSDT and save it in your home folder with this command

Code:

sudo cat /proc/acpi/dsdt > dsdt.dat

Then we will disassemble it with iasl with this command

Code:

iasl -d dsdt.dat

You should now have a file called dsdt.dsl in your home folder. This is the file you will be editing. Once you are done making changes, we will use it to make a new DSDT file. The next step is to use iasl to recompile the dsdt.dsl file to see any errors/warnings/optimizations with this command. Replace <yourusername> with your username.

Code:

iasl -tc /home/<yourusername>/dsdt.dsl

This will show you the output of the recompiling process. At this point, you can use the output to find errors in the DSDT and attempt to fix them by editing the dsdt.dsl file with your favorite text editor. Go into the preferences for your text editor and turn on "line numbering". Then open dsdt.dsl with your text editor. You can use the output of the last command to find the errors by their line number. The following is an example of a common error. "dsdt.dsl 349" means the error is on line 349 of the dsdt.dsl file. Go to that line in your dsdt.dsl file with the text editor to fix it and save.

Code:

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

Each time you make a change in the dsdt.dsl file, be sure to save it, and then recompile to see the new output with

Code:

iasl -tc /home/<yourusername>/dsdt.dsl

This will recompile it with the new changes and give you a new output to see if things look better

Below are several links with common DSDT errors and their fixes.

http://forums.opensuse.org/how-faq-r...uggy-dsdt.html
https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z
http://forums.opensuse.org/archives/...uggy-dsdt.html
http://forums.gentoo.org/viewtopic.php?t=122145

You might get lucky and find one already fixed for your make/model here: http://acpi.sourceforge.net/dsdt/view.php If so then you can skip to the last two commands.

Once you have successfully edited the dsdt.dsl file, we should have a dsdt.aml in your home folder. This was the goal of the how to.

WARNING: The commands up till this point have not made any changes to your system. You can simply delete the files that have been created. After the last two commands, you will be using a custom DSDT at boot. This is the point of no return.

These commands will rename the dsdt.aml file and copy it to your /etc/initramfs-tools folder. Then we will update the initrd image to include the DSDT override at boot. The very last command will update the initrd image. You need to replace "kernel version" with your kernel version. You can see it by running

Code:

uname -r

in a terminal.

Code:

sudo cp dsdt.aml /etc/initramfs-tools/DSDT.aml

Code:

sudo update-initramfs -u -k kernel-version

Now cross your fingers and reboot

To see if it stuck, you can look in your dmesg output. Open a terminal and run

Code:

dmesg > /home/yourusername/Desktop/dmesg

This will put your dmesg output into a text file on your desktop. You should see a line similar to this:

Code:

[    0.020495] ACPI: Checking initramfs for custom DSDT
[    0.353464] ACPI: Found DSDT in DSDT.aml.
[    0.353470] ACPI: Override [DSDT-   MCP67], this is unsafe: tainting kernel
[    0.353478] ACPI: Table DSDT replaced by host OS
[    0.353482] ACPI: DSDT 00000000, 7CB3 (r1 NVIDIA    MCP67  6040000 INTL 20061109)
[    0.353487] ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"

Places to check before and after are: dmesg output and /proc/acpi. I would especially check /proc/acpi/fan and /proc/acpi/thermal_zone to see if they are populated after this tutorial if they weren't before. Another trick I've learned during this process is to specify the operating system at boot. More about this is explained in the links I provided. I found that by adding

Code:

acpi_osi="Linux"

to the boot options, the operating system even saw my hardware differently at boot. This seems to be very affective on HP laptops with Vista preinstalled. I outlined these steps here: http://www.linuxmint.com/forum/viewt...p?f=60&t=18222 The DSDT code is very hard to read, and I myself don't understand all of it. I left my HP desktop with 0 errors, and 4 warnings. Everything works, so I left the warnings. My laptop DSDT is perfect. It is a HP dv6815nr if someone with the same model wants to use my custom DSDT file. DSDT files are PC specific. Do not try using a DSDT from another PC unless it has the same hardware as yours.

EDIT: To remove a custom DSDT, delete the DSDT.aml file with

Code:

sudo rm /etc/initramfs-tools/DSDT.aml

and reupdate the init image with

Code:

sudo update-initramfs -u -k kernel-version

This will revert your system back to the original state after a reboot.

EDIT: This will not work with kernels that are still in development. The patches that allow the custom DSDT are not included until the kernel is released as "stable".

UPDATE: The kernel dev's will no longer use the patch to enable custom DSDT files for Karmic 9.10 and beyond. Jaunty 9.04 is the last version this will work on. You are urged to file a bug report for DSDT errors.

**CylnZ** · May 8th, 2009

Code:

john@john-laptop2:~$ sudo update-initramfs -u -k kernel-version
[sudo] password for john: 
update-initramfs: Generating /boot/initrd.img-kernel-version
Cannot find /lib/modules/kernel-version
update-initramfs: failed for /boot/initrd.img-kernel-version
john@john-laptop2:~$

Duh, got it figured, replace "kernel-version" where appropriate; sheesh.

Code:

john@john-laptop2:~$ sudo update-initramfs -u -k 2.6.28-12-generic
update-initramfs: Generating /boot/initrd.img-2.6.28-12-generic
john@john-laptop2:~$

Code:

0.004000] ACPI: Core revision 20080926
[    0.006886] ACPI: Checking initramfs for custom DSDT
[    0.443822] ACPI: Found DSDT in DSDT.aml.
[    0.443828] ACPI: Override [DSDT-CRESTLNE], this is unsafe: tainting kernel
[    0.443834] ACPI: Table DSDT replaced by host OS
[    0.443838] ACPI: DSDT 00000000, 887E (r2 INTEL  CRESTLNE  6040000 INTL 20081204)
[    0.443843] ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"
[    0.452055] Setting APIC routing to flat

I'll move on to the add os to startup tip, Thanks so much

**CylnZ** · May 8th, 2009

Code:

   Scope (\_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            If (DTSE)
            {
                TRAP (0x47)
            }

            Store (0x07D0, OSYS)
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    Store (0x01, LINX)
                }

                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }

                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }
            }

Those dirty SoBs.

I'm going to try an experiment; changing :

Code:

If (_OSI ("Linux"))
                {
                    Store (0x01, LINX)

to:

Code:

If (_OSI ("Linux"))
                {
                    Store (0x07D2, OSYS)

which would be telling the bios we are running xp sp2 wouldnt it?

I'll post the results in a bit. Its gonna be real interesting to see if the things cool off.

I picked up the 965 whitepaper from intel and I may grab the compiler from m$ to compare dsdt.dsl output. Strangely, many of intels and some of acpi.info calls arnt there where acpi says they should be.

will let you know.

**CalderCoalson** · May 8th, 2009

Thank you, thank you thank you!!! My laptop can finally suspend again!

**mm0204** · May 10th, 2009

I really appreciate that someone has figured out how to fix this problem. I am really miffed that i can't get simple things to work on my laptop but I think this is the issue.

my question is: has anybody submitted a bug report to Ubuntu about this problem? Because, I am not a programer. I don't speak machine language. I have googled for the corrections to make to my dsdt.dsl file and I can't find any of the errors that I'm getting. So, I'm going to have to go back to Hardy Heron because everything (except for sound capture which still doesn't work on this laptop) worked in Hardy. Just finding a work around doesn't help the community. this needs to be fixed by someone who knows what they're doing at the source code level... right?

or am i missing something?

Grace and Peace,
Matt
matty (at) the strange land (dot) net {just put it all together

}

**67GTA** · May 10th, 2009

Originally Posted by mm0204

I really appreciate that someone has figured out how to fix this problem. I am really miffed that i can't get simple things to work on my laptop but I think this is the issue.

my question is: has anybody submitted a bug report to Ubuntu about this problem? Because, I am not a programer. I don't speak machine language. I have googled for the corrections to make to my dsdt.dsl file and I can't find any of the errors that I'm getting. So, I'm going to have to go back to Hardy Heron because everything (except for sound capture which still doesn't work on this laptop) worked in Hardy. Just finding a work around doesn't help the community. this needs to be fixed by someone who knows what they're doing at the source code level... right?

or am i missing something?

Grace and Peace,
Matt
matty (at) the strange land (dot) net {just put it all together

}

This is not a Ubuntu problem to fix. The hardware vendors are causing the trouble. The DSDT is hard coded into your BIOS when it is programed. There is nothing Ubuntu or any other OS can do except find workarounds. Even then, your hardware might not work correctly, you just don't see it as a bug within the OS. Some hardware/PC makers use the Microsoft AML compiler, and causes breakage for Linux/Mac. Follow my how to to the point of getting your dsdt.dsl file and send it to me. I will see if I can fix the errors.

**67GTA** · May 10th, 2009

Originally Posted by CylnZ

Code:

   Scope (\_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            If (DTSE)
            {
                TRAP (0x47)
            }

            Store (0x07D0, OSYS)
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    Store (0x01, LINX)
                }

                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }

                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }
            }

Those dirty SoBs.

I'm going to try an experiment; changing :

Code:

If (_OSI ("Linux"))
                {
                    Store (0x01, LINX)

to:

Code:

If (_OSI ("Linux"))
                {
                    Store (0x07D2, OSYS)

which would be telling the bios we are running xp sp2 wouldnt it?

I'll post the results in a bit. Its gonna be real interesting to see if the things cool off.

I picked up the 965 whitepaper from intel and I may grab the compiler from m$ to compare dsdt.dsl output. Strangely, many of intels and some of acpi.info calls arnt there where acpi says they should be.

will let you know.

An easier way to do this would be to add the corresponding boot argument to /boot/grub/menu.lst as I laid out at the end of my how to. Instead of

Code:

acpi_osi="Linux"

, you would add

Code:

acpi_osi="Windows 2001 SP2"

This will tell Ubuntu to load the acpi tables for XP to use in Ubuntu.

**mgolobay** · May 14th, 2009

Originally Posted by 67GTA

This is not a Ubuntu problem to fix.

Unfortunately that is not true. While the Microsoft AML compiler may be just as buggy as all the rest of their products, the end result is that many of us have dual boot machines where a Microsoft OS is able to work around the DSDT bugs to yield a running system and Linux is not.

Ubuntu is a distribution of Linux that is well positioned to be an upgrade from Windows. But as long as so many have had experiences like mine where I set a friend's laptop up for dual boot Vista/Ubuntu and only the Vista system works, Microsoft will continue to win. The vast majority who try Ubuntu with a buggy DSDT will do no research whatsoever, decide Ubuntu is sort of pretty but not ready for real work, delete it and go on never to look back.

People want to experience this:
http://www.youtube.com/watch?v=EwL0G9wK8j4

But end up with a lot of this:
http://failblog.files.wordpress.com/...pg?w=362&h=500

**67GTA** · May 14th, 2009

Unfortunately that is not true. While the Microsoft AML compiler may be just as buggy as all the rest of their products, the end result is that many of us have dual boot machines where a Microsoft OS is able to work around the DSDT bugs to yield a running system and Linux is not.

You unfortunately don't understand what you are talking about. Do you know what a DSDT is and how operating systems interact with them? The Microsoft ACPI tables in the 71 DSDT's I've fixed so far have had zero errors. All the errors have been in the Linux tables. MS and Linux don't use the same sectiuons of a DSDT. The MS sections have no errors to work around when the MS compiler is used. The Microsoft AML compiler is intentionally breaking Linux/Mac compatibility. If you send me your DSDT, I can break a few things in the Microsoft ACPI tables, the MS AML compiler won't catch the errors, and MS won't run correctly. Would it then be MS's job to fix it? When the open industry standard Intel AML compiler is used, "ALL" operating systems work as they should.

Ubuntu is a distribution of Linux that is well positioned to be an upgrade from Windows. But as long as so many have had experiences like mine where I set a friend's laptop up for dual boot Vista/Ubuntu and only the Vista system works, Microsoft will continue to win. The vast majority who try Ubuntu with a buggy DSDT will do no research whatsoever, decide Ubuntu is sort of pretty but not ready for real work, delete it and go on never to look back.

Your point here is not valid either. Any PC with Windows preinstalled is supposed to work correctly. The fact that you installed Ubuntu on a PC that has thousands of possible hardware combinations, and it didn't work as expected, is not a "fail". Try picking a PC at random that wasn't designed for Vista and try installing it. You will have just as many bad experiences. If you get a PC designed for Linux with Linux preinstalled, it will run just as perfect as Vista preinstalled on a Vista supported PC. If Vista failed to work on "said PC", would that mean Vista is not ready for work?

The vast majority who try Ubuntu with a buggy DSDT will do no research whatsoever, decide Ubuntu is sort of pretty but not ready for real work, delete it and go on never to look back.

This is the only point I agree with you on. The vast majority of people have no idea what a DSDT is, or that it even exists. I for one know Linux is a superior OS to Windows, and if something doesn't work right, I will try to find out why. Most people don't think this way. They try Linux out of curiosity, it doesn't work exactly right, and then go back to Windows where they should stay. The other small percentage of free thinkers stick with it, find out "who" is causing them trouble, and liberate themselves.

**CalderCoalson** · May 15th, 2009

Originally Posted by 67GTA

The other small percentage of free thinkers stick with it, find out "who" is causing them trouble, and liberate themselves.

Windows = The Matrix

Thread: HOWTO Fix A Buggy DSDT File

Thread Tools

Display

HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Re: HOWTO Fix A Buggy DSDT File

Bookmarks

Bookmarks

Posting Permissions