Howto Fix Your Buggy DSDT.

(For SuSE10.1 jump to post #45)
And, I'm no expert. but if I can do it, so can you!

Notes:
AMD uses powernow
Intel uses Speedstep
My system is AMD -k8 both laptop & desktop = powernow-k8

See any acpi errors or warnings in dmesg? Does your system hang when shutting down? Can't suspend to RAM or disk? Computer won't wakeup? Battery functions not working? Losing an IRQ? Can't get wireless to work even though you are following exact directions? You probably have a buggy DSDT thanks to Microsoft. Let's fix it!


This all started when I installed Suse 9.3 on my new Sager NP4750 64-bit laptop. You may recall that in an earlier post I reported:

"With my new Sager NP4750 AMD 64-bit laptop with Suse 9.3, autologin is dumping me to a
login page with an xconsole with these 2 msgs:
ACPI-400: Warning: invalid active threshold [0], and
cpu_init done, current fid 0x0, vid 0x0.

After 2 to 3 logins I can't get past it, i.e. login.

DMESG reads:
ACPI: cpu0 power states: c1 (c1 c2 (c2)
ACPI-400 ***Warning: invalid active threshold [0]"


Well, I now have it fixed! And, while I was learning -- on my desktop Nforce3-250Gb on which Suse 9.2 32- & 64-bit had been running perfectly ( I thought)-- found acpi errors and warnings there also I have the Nforce3 desktop Suse 9.3 32-bit DSDT fixed also. My plan is to fix my desktop suse 9.3 64-bit DSDT and share that with you as I progress along.


First let's do some reading:

The best & most helpful howto I found is "HOWTO: Fix Common ACPI Problems (DSDT, ECDT, etc.) " here:
http://forums.gentoo.org/viewtopic.php?t=122145

"DSDT files" is very helpful in correcting errors & warnings. Here:
http://users.pandora.be/PrittyFlemishPages...pire1800_3.html

The acpi source is here:
http://acpi.sourceforge.net/dsdt/index.php
Browse thru their repository & they may just have a "fixed" DSDT for your computer here:
http://acpi.sourceforge.net/dsdt/view.php

"Linux ACPI Howto (Advanced Configuration and Power Interface)" is most helpful. Here:
http://www.cpqlinux.com/acpi-howto.html
There is a Chapter "Fixing your broken DSDT Table" here:
http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt

The acpi Spec here:
http://www.acpi.info/spec.htm

And lastly, "The Suse 9.3 Admin Guide"Chapter 16.


If your dmesg contains a line that looks like this:
ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
then almost surely you have a buggy DSDT unless your OEM happened to have fixed it for you -- MSFT 0x0100000c) @ 0x00000000 means M$ buggy compiler to me.



Next, go to your OEM; get the latest bios; and install it. It may contain a fixed DSDT for you or at least turn on some missing functions.



Next take a look at "dmesg" & see if you have any acpi errors, warnings, dropped IRQs, or just things that acpi didn't accomplish.
"dmesg | grep -2i acpi" will simplify looking @ acpi lines, but I recommend looking at the full dmesg output.
Now let's reboot with: acpi_os_name="Microsoft Windows XP" typed in on boot line.
See any differences in "dmesg"?
Repeat using: acpi_os_name="Microsoft Windows 2000"
Repeat using: acpi_os_name="Microsoft Windows 2000.1"
Repeat using: acpi_os_name="Microsoft Windows ME: Millennium Edition"
You can even try: acpi_os_name="Linux"
What we are exploring is seeing if this action triggers some switches & helps the bios build a better DSDT for acpi to use. This is explained here:
http://forums.gentoo.org/viewtopic.php?t=122145
Pick the one that gives you the least flags. I use acpi_os_name="Microsoft Windows 2000".






Now let's find our errors and warnings in our buggy DSDT.

Get the DSDT (written for Suse 9.3 file structure). Note: Suse 9.3 provides all the tools that we will need -- no need to go looking for intel/ibm files named in the readings.
The DSDT resides in /proc/acpi/dsdt and the file will be locked.
So, as root, "cat /proc/acpi/dsdt > /home/yourname/dsdt.dat"
Disassemble the DSDT
The iasl tools reside in /usr/sbin.
So, cd /usr/sbin Note: for SuSE10.1 users, this now resides in /usr/bin, so, the command is "cd /usr/bin"
"./iasl -d /home/yourname/dsdt.dat"
This will create a file called dsdt.dsl, which contains the disassembled DSDT.
Copy this file from /usr/sbin to /home/yourname as we are going to work on it.
Open kwrite; open /home/yourname/dsdt.dsl; click on view and select line numbers.
The acpi numbered errors and warning from dmesg should showup with the same number line here -- but it won't show the errors

But, we are not done.
Recompile the DSDT.
still in /usr/sbin Note: for SuSE10.1 users, see 8 lines above = /usr/bin
./iasl -tc /home/yourname/dsdt.dsl
If you have a buggy DSDT; you will get errors & warnings. If you don't have a buggy DSDT it will compile and create 2 files: dsdt.hex and DSDT.aml.
The DSDT.aml is our goal & we will use it with a simple mkintrid command later.


Here are some of the errors and warnings I got:

Sager Np4750 64-bit laptop with Suse 9.3:

dsdt.dsl 226: Method(\_WAK,1,notserialized)
Warning 2026 Reserved Method must return a Value (_WAK)

dsdt.dsl 2592 Field (Rom,AnyAcc,Lock, Preserve Precxx)
Error 1048 Host operation Region requires ByteAcc

dsdt.dsl 3486 Method (_PSR,0,Not Serialized)
Warning 2019 Not all control Paths return a value (_PSR)

dsdt.dsl 3486 Method (_PSR,0,Not Serialized)
Warning 2026 Not all control Paths return a value (_PSR)

I might add that when I fixed these and recompiled; there was no end-of-file marker either.


The solution to the first 2 is here: http://forums.gentoo.org/viewtopic.php?t=122145.
The next 2 required somw trial and error, but I'll have to get on my laptop to say just what I did to fix it.


Nforce3-250-Gb 64-bit desktop with Suse 9.3 32-bit:

DSDT.DSL 248 Notify (\_SB.LID,0X02)
Error 1022 Object does not exixt (_SB.LID)

DSDT.DSL 2710 Notify (\_SB.LID,0X80)
Error 1022 Object does not exixt (_SB.LID)

dsdt.dsl 3578 Return (DACO)
Error 1021 Object not Accessible from this Scope (DACO)

I'll have to get onto 32-bit system to know exactly what I did to fix these errors, else I would be guessing.

Look at your errors and warnings in kwrite as before. Use Find and Find Next to search throughout i.e., (DACO) from above error 1021.

remember google is your friend: google for: yourbox fixed dsdt, fixed dsdt, dsdt. acpi error 1022, Method (_PSR,0,Not Serialized), etc.
We are looking for someone who has fixed a similar problem.

More to come, but I have to cease for tonight.
By the way, my boxes boot one h__l of a lot faster!
And yes, I know that I have some filling in to do.

Snakedriver

Good stuff SnakeDriver. Here's my output, at least what I would consider to be problems. Any tips before I get into this? None of the acpi_os_name boot options made any difference. I am thinking that I have a larger problem?

harryc@linux:~> dmesg | grep -2i acpi
 ACPI: Looking for DSDT in initrd... not found!
 not found!

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e)
 * *ACPI-0283: *** Warning: Error evaluating _PSS
powernow-k8: BIOS error - no PSB
powernow: This module only works with AMD K7 CPUs
 * *ACPI-0283: *** Warning: Error evaluating _PSS

harryc,
Quote
harryc@linux:~> dmesg | grep -2i acpi
ACPI: Looking for DSDT in initrd... not found!
not found!
quote
That is acpi reporting what it has done; no problem
When we get our product = fixed dsdt.dsl -- we are going to place it where initrd will find it & use "mkinitrd" so it will be added during boot like here:

from my nforce3-250Gb suse 9.3 fixed dsdt dmesg:
ACPI: Looking for DSDT in initramfs... found /DSDT.aml ... successfully read 19095 bytes from /DSDT.aml
ACPI: Using customized DSDT
ACPI-0293: *** Info: Table [DSDT] replaced by host OS



I'm still getting:
powernow-k8: BIOS error - no PSB
powernow: This module only works with AMD K7 CPUs
ACPI-0283: *** Warning: Error evaluating _PSS
even with fixed dsdt.
Obviously there's more work to be done. When I get the chance, I'll use "find & find next" in kwrite to see if this is in dsdt or another table -- such as ECDT.
Note: this may require a kernel work-around patch, more on this later.
Better yet, maybe a real guru will pitch in & help us solve this issue.

Got to go check my moma cows. I'll be back.

SnakeDriver, this didn't quite work for me -

The iasl tools reside in /usr/sbin.
So, cd /usr/sbin
"./iasl -d /home/yourname/dsdt.dat"
This will create a file called dsdt.dsl, which contains the disassembled DSDT.

It created a file called dsdt.dat, not dsdt.dsl, at least in my home directory. It did create a /usr/sbin/dsdt.dsl though.

Aha! I *knew* it was the evil MSFT line responsible for those problems! </end sarcasm>

Ok, I had to manually copy files from usr/sbin to /home/user, but I got things to compile after fixing (2) errors.
(Method(\_WAK,1,notserialized)
...and one other that was looking for alphanumeric only in Name (_HID, "_NVRAIDBUS"). I just made it Name (_HID, "NVRAIDBUS") and it worked.

So now I have a /home/user/dsdt.hex, DSDT.aml, and a dsdt.dat. What's next?

Edit: Never mind, found the answer in the SuSE Admin Guide. Pg. 308.

Nice. It looks like power functions are working. Suspend to disk does not recover though. It looks like that will need another thread...Thanks SnakeDriver.

ACPI: Looking for DSDT in initramfs... found /DSDT.aml ... successfully read 17030 bytes from /DSDT.aml
ACPI: Using customized DSDT
ACPI-0293: *** Info: Table [DSDT] replaced by host OS

Harryc,
quote
It did create a /usr/sbin/dsdt.dsl though.
quote

You are correct again; knew I shouldn't do all that from memory & spread across three installs.

"Suspend to disk does not recover though." From what Ive read, it's suspend to RAM that's not up to speed -- although there are experts hard at work on it.

Hey, I'm just glad that someone else got another function or two to work like the spec says they are susposed to work. At least there's a starting point for someone like me when in the beginning when I didn't have a clue how to get around my new latest & greatest laptop freezing after a couple of reboots.

Originally posted by Snakedriver@May 18 2005, 06:24 PM
Hey, I'm just glad that someone else got another function or two to work like the spec says they are susposed to work.*

Thanks for pulling this together. It's one more thing fixed and a good education to boot. It's all good .

Let's talk about tech support for a learning experience.

I have used Suse since 9.0. I tried mandrake on a HP ZE5385 laptop & it didn't find everything -- of course, I was a total neewb. Suse 9.0 found everything & I was off & running. I have bought all the latest Suse releases ever since & have never had to or tried tech support. I did this time and my experience was something to write home about.

In Yast there is a button to ask for tech support. All you need is a number off your Suse invoice & email address. Yast will provide a box for you to pose you problem; but the neat thing is that it will gather all the necessary files, compress them and fire them off to Suse and all you have to do is sit back and wait. This is a good feature. However...........

Here is the response that I received per my request for help:

Thank you for your enquiry to SUSE LINUX installation support.

You wrote:


>> DMESG reads:
>> ACPI: cpu0 power states: c1 (c1 c2 (c2)
>> ACPI-400 ***Warning: invalid active threshold [0]
>> ACPI: Thermal Zone [THRM] 53degC (note: this was immediately after
>> install.)

That is a problem with the ACPI support. You find the following article about that in our SUSE Support Knowledgebase within the SUSE LINUX Portal
(http://portal.suse.de/sdb/en/index.html) with the keyword "ACPI".

http://portal.suse.com/sdb/en/2002/10/81_acpi.html

Unfortunately, the ACPI issues is not coverd within the free installation support scope.

Regarding the terms of our free support, please read the enclosed
information brochure "Support from SUSE LINUX", which is also available
online at:

http://www.novell.com/products/linuxprofes...port/index.html

However, I recommend you to join some user mailing lists and ask there your
questions. It is possible that some other users have had your problems and
could help you to fix your problem. SuSE Linux provides some of these lists.
If you wish, you can join them from:

http://www.suse.de/us/business/mailinglists.html

A detailed list of topics handled by free or advanced support can be found
at
http://www.novell.com/products/linuxprofes...t_overview.html




Yours sincerely,

SUSE LINUX Support-Team



I did a similar tech support request to SAGER. I don't need to post their response; I'll paraphrase:
"We don't support Linux. How is you Winxp install running?"
I should have said, "Winxp is not running in 64-bits; If I install winxp64 beta, there's no software for it; So if I just spent 2 big ones on your 64-bit machine why won't you help me run a real 64-bit Operating System that comes complete with everything I need."

Sager would be suprised at how well my suse 9.3 x86-64 is running on their box now.

I offer this info because it seems that the Linux developers and the major Distros ( like Suse) do their systems based on the Specifications -- like the acpi spec. If it met Spec every thing would work out of the box.

If it doesn't; we are going to have to help each other.

Finally, and maybe the most important, the real Linux developers don't like to do work-arounds -- they would like for us to put pressure on the OEMs to meet Spec.