HOWTO Fix A Buggy DSDT File

[jmhdj]

Hello guys. I am really impressed to see how much you can about dsdt repairing. I have problems with my dsdt file, and if anyone can see and help me here please do so. here sre warnigs i get and dsdt file. Thanks forward


Intel ACPI Component Architecture
ASL Optimizing Compiler version 20100121 [Feb 8 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0

DSDT.dsl 2752: Method (WMBA, 3, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (WMBA)

DSDT.dsl 2840: Method (_WED, 1, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_WED)

DSDT.dsl 3150: Method (WMBE, 3, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (WMBE)

DSDT.dsl 4367: P8XH (Zero, 0x0F)
Warning 1100 - Statement is unreachable ^

DSDT.dsl 4430: Method (_BQC, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_BQC)

DSDT.dsl 4430: Method (_BQC, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_BQC)

DSDT.dsl 4616: Method (_BQC, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_BQC)

DSDT.dsl 4616: Method (_BQC, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_BQC)

DSDT.dsl 4851: P8XH (Zero, 0x1F)
Warning 1100 - Statement is unreachable ^

DSDT.dsl 4895: P8XH (Zero, 0xF9)
Warning 1100 - Statement is unreachable ^

DSDT.dsl 4908: P8XH (Zero, 0xFC)
Warning 1100 - Statement is unreachable ^

DSDT.dsl 8352: Method (_GTM, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTM)

DSDT.dsl 8352: Method (_GTM, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTM)

DSDT.dsl 8513: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 8513: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 8581: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 8581: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 8654: Method (_GTM, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTM)

DSDT.dsl 8654: Method (_GTM, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTM)

DSDT.dsl 8815: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 8815: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 8883: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 8883: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 8988: Method (_GTM, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTM)

DSDT.dsl 8988: Method (_GTM, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTM)

DSDT.dsl 9148: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 9148: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 9216: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 9216: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 9289: Method (_GTM, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTM)

DSDT.dsl 9289: Method (_GTM, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTM)

DSDT.dsl 9449: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 9449: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

DSDT.dsl 9517: Method (_GTF, 0, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (_GTF)

DSDT.dsl 9517: Method (_GTF, 0, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (_GTF)

ASL Input: DSDT.dsl - 9592 lines, 326219 bytes, 4071 keywords
AML Output: dat.aml - 37175 bytes, 1024 named objects, 3047 executable opcodes

Compilation complete. 0 Errors, 35 Warnings, 0 Remarks, 36 Optimizations

[67GTA]

I just looked at this post again after a long absence. I guess I didn't visit the thread after the last email notification. The forums won't notify you again until you visit the thread. I didn't realize all of the activity here. I have moved to Opensuse. The Novell devs fixed the dsdt patch that allows you to use a custom dsdt and apply it. EVERY other distro has just dropped it per Linus's wishes including Ubuntu. With 9.10 and beyond, you can no longer apply a custom dsdt without compiling your own kernel. The idea was to make people file bugs against the kernel instead of fixing them through the dsdt. This is fine in most cases and is what I recommend you do first. If at that point you are one of the lucky people like me that has an ACPI bug due to a buggy dsdt that the kernel devs won't fix, then I will try to help you fix your dsdt, but do not want to try and help walk everyone through compiling a custom kernel to be able to apply the dsdt. I'm not trying to be a butt, but this can be very tricky with hundreds of pitfalls, and would be impossible to help you from here if you make a mistake and your OS won't boot. Anyone using 9.04 and older can still use this how to without problems. My ultimate suggestion would be to give Opensuse a try. I use KDE, so I can't vouch for the Gnome version. If anyone still wants help with their dsdt after reading this, and I haven't answered you, then you can reach me by email from my profile.

[67GTA]

Update: There is now an argument going on over the inclusion of the dsdt patch in the Opensuse kernel. Version 2.6.31.8 had the patch. Another kernel dev removed it with the 2.6.31.12 update. So, as of right now, no distro supports a custom dsdt without rolling your own kernel. I guess the best avenue now is just to file a bug against the kernel and hope they can fix it.

[cyberey66]

Update: There is now an argument going on over the inclusion of the dsdt patch in the Opensuse kernel. Version 2.6.31.8 had the patch. Another kernel dev removed it with the 2.6.31.12 update. So, as of right now, no distro supports a custom dsdt without rolling your own kernel. I guess the best avenue now is just to file a bug against the kernel and hope they can fix it.

I was wondering about suse and that's a shame to hear since many laptops ship with DSDTs compiled by the MS compiler.

Do you happen to know if the latest patch suse used is posted anywhere? It would be interesting to try and get it to work on an Ubuntu kernel. It would only take one person to get it to work and many will benefit.

[67GTA]

It was a private patch supplied by one of the Novell kernel devs and not officially supported (hence the removal by a higher rank). I actually asked if I could get the patch to use with Ubuntu, but never got a reply. I don't think they liked the request

[Favux]

Hi 67GTA,

Thank you for your HOW TO and the associated thread!

I've been following it for about a year now, ever since I used your HOW TO to fix my DSDT (which I'm using right now).

I am sorry about losing the DSDT patch in OpenSUSE. I followed that and it seemed like it only took the dev. a few days to fix the memory issue with it. Sort of set to rest some of the arguments you were getting, didn't it?

I understand the argument about the community needing the error(s) in the DSDT submitted so that everyone benefits. Rather than folks having 'private' patched DSDT's.

What really irritates me is that not once did anyone give you a time-line. Or did I miss it? I follow the kernel news a little so here is my guess. I'm sure you have a more accurate idea.

1 month - avg. time for user to discover bug, trace it to bios, decompile DSDT, recompile and discover error(s), and find where to submit the DSDT.
1 month - time for review of the buggy DSDT, develop quirk and submission to kernel
1 month - time for kernel to review quirk and accept it.
3 months - minimum time for distro. to pick up kernel with quirk. (I suppose quicker with a rolling distribution or if you import the kernel)

6 months - total elapsed time. That would seem close to the minimum. It wouldn't surprise me if the typical scenario is double that.

Does that sound close?

[cyberey66]

Hi 67GTA,

Thank you for your HOW TO and the associated thread!

I've been following it for about a year now, ever since I used your HOW TO to fix my DSDT (which I'm using right now).

I am sorry about losing the DSDT patch in OpenSUSE. I followed that and it seemed like it only took the dev. a few days to fix the memory issue with it. Sort of set to rest some of the arguments you were getting, didn't it?

I understand the argument about the community needing the error(s) in the DSDT submitted so that everyone benefits. Rather than folks having 'private' patched DSDT's.

What really irritates me is that not once did anyone give you a time-line. Or did I miss it? I follow the kernel news a little so here is my guess. I'm sure you have a more accurate idea.

1 month - avg. time for user to discover bug, trace it to bios, decompile DSDT, recompile and discover error(s), and find where to submit the DSDT.
1 month - time for review of the buggy DSDT, develop quirk and submission to kernel
1 month - time for kernel to review quirk and accept it.
3 months - minimum time for distro. to pick up kernel with quirk. (I suppose quicker with a rolling distribution or if you import the kernel)

6 months - total elapsed time. That would seem close to the minimum. It wouldn't surprise me if the typical scenario is double that.

Does that sound close?

If it's a common laptop, the correct DSDT is likely available as it is probable at least one person out of all the linux using owners fixed it. Total time to locate and download DSDT, 1 day. It still takes that long now, but you have to compile the kernel.

So for the bug reporting, what happens in the case of DSDT compiled with the microsoft compiler?

[bruderjakob]

Hey,

there is a problem in the dsdt of various acer timeline/travelmate notebooks as you can see there:
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/405120

it would be great when someone can help us out, if there is a patched dsdt i can test it.
what do you think where i should submit a patched dsdt that it can be build in the upcoming kernel releases?

thanks in advance! (and sorry for bad english)

jakob

[67GTA]

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 50 Optimizations

That was a buggy dsdt. This will only work with 9.04 and earlier. 9.10 and after will no longer allow you to use a custom dsdt. A dsdt file can not be put in the kernel. Hopefully the devs can see what I've fixed (assuming it helps you) and create a kernel fix. You can test this dsdt with 9.04 to see if your trouble is dsdt specific. If it is, then add the old and new dsdt's to your bug report. You might also want to go over the Ubuntu kernel devs head and also file one at the source: http://www.kernel.org/pub/linux/docs...ting-bugs.html

http://bugzilla.kernel.org/

DSDT.aml.zip

[bruderjakob]

Can't say how thankful i am!

I will start testing now and report later.

I think i try to compile own kernel with dsdt patch (i think i saw a 'how to' in my researches about dsdt); isn't it possible to take the same kernel in 9.04 from mainline kernels? otherwise i have to test with 9.04.