HOWTO: Fix Common ACPI Problems (DSDT, ECDT, etc.)

Message

sleek · Post by **sleek** » Wed Feb 11, 2004 7:25 pm

craig@sleekdesign craig $ cat /proc/acpi/battery/CMB0/info 
present:                 yes
design capacity:         unknown
last full capacity:      unknown
battery technology:      rechargeable
design voltage:          unknown
design capacity warning: 800 mWh
design capacity low:     800 mWh
capacity granularity 1:  100 mWh
capacity granularity 2:  100 mWh
model number:            BAT1
serial number:           00000000
battery type:            LION
OEM info:                COMPAQ

jetblack · Post by **jetblack** » Wed Feb 11, 2004 7:37 pm

Hm, then I'm going to go ahead and guess that gkrellm isn't using that information at all.

On a more serious note, you should have some information there. Is that what it says while the battery is discharging?

sleek · Post by **sleek** » Wed Feb 11, 2004 7:42 pm

Code: Select all

craig@sleekdesign craig $ cat /proc/acpi/battery/CMB0/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            65176 mW
remaining capacity:      4246 mWh
present voltage:         16439 mV

sleek · Post by **sleek** » Wed Feb 11, 2004 7:46 pm

Although my battery seems to be getting charged, etc, I'm still wondering if I made the correct changes to my DSDT. Although if this stuff all works except some small details, then I'm not sure what it could be.

jetblack · Post by **jetblack** » Wed Feb 11, 2004 8:32 pm

A lot of people have reported issues with the battery info in 2.6.1 and 2.6.2. There is apparently a bug in the acpi code in those kernels, which could be affecting you. Do you have a 2.4 kernel (or 2.6.0) lying around that you could try, just to see if you get values to show up in those files?

sleek · Post by **sleek** » Wed Feb 11, 2004 8:48 pm

Actually, this is 2.4.23 that I'm working with right now. I suppose I could try a 2.6.x kernel to test stuff out.

tkoster · Post by **tkoster** » Thu Feb 12, 2004 12:43 am

Here's another question that may be on the silly side. I was poking through the online package database and discovered that there were two packages acpi and acpid listed there. My impression from the various howto's were that with the kernel patched and modules included in it, there was no need for other programs, daemons or drivers to get the acpi to work. Especially since many of the elements in the /proc/acpi/ files are registering and working fine. Did I misunderstand? Are the extra packages something that I need as well?

jetblack · Post by **jetblack** » Thu Feb 12, 2004 1:21 am

Those apps won't do anything to restore missing information, but you may want to install at least acpid at some point to get your system to respond to acpi events. Basically, acpi just prints out some of the information from /proc/acpi. acpid watches for events, and allows you to put together scripts to respond to them. This is nice if you want to do things like shut the system down when the battery reaches a certain level, or put it to sleep when you close the lid.

jetblack · Post by **jetblack** » Thu Feb 12, 2004 1:42 am

tkoster wrote:I don't have a webpage to post the file and it is quite a few lines to include here.

I haven't had a chance to look at it yet, but I have posted it, in case someone else would like to give it a look. I hope to have some time to check it out tomorrow. In the meantime:

tkoster's DSDT

jetblack · Post by **jetblack** » Thu Feb 12, 2004 2:13 am

tkoster wrote:I'm willing to try the vanilla, if you think it will work better (ndiswrapper requires 2.4.23 or better). I'm also willing - even a little eager - to try 2.6, but I've been a little more uncertain there which sources to use or how to filter/masque to get the one I want. Which kernel has been working best with acpi?

Of the 2.6 kernels, 2.6.0 seems to have had the best ACPI support. You may want to give that a shot first. Any flavor should do. Also, be sure to apply the latest ACPI patch for whichever kernel you choose from acpi.sourceforge.net.

tkoster · Post by **tkoster** » Sat Feb 14, 2004 3:13 am

You don't have to bother trying to hash out the dsdt file for me. They just posted a new patch for the 2.4.25 kernel which fixed the problem. The battery levels now register. Thanks for your help.

fear_lag · Post by **fear_lag** » Wed Feb 25, 2004 10:34 am

sleek wrote: So I think that it's safe to say that we can now add the Compaq Presario 1700 (17XL2) laptop to the list of ACPI hacked success stories

Good luck to everyone else who is still working on their ACPI!!!

I'm having some trouble with ACPI on the same computer and was wondering if you might be able to send your DSDT version to me or post it to the ACPI4Linux site on sourceforge

sleek · Post by **sleek** » Wed Feb 25, 2004 5:08 pm

Sure, I'd be happy to share my stuff with you. To make it REALLY worth your time though, what kernel version will you be using? Personally I have had a lot of success with the 2.4.24 kernel. I have patched it with the latest ACPI stuff, bootsplash, software suspend, and of course a couple of the patches from this post.

Let me know what you need and I'll hook you up.

federico · Post by **federico** » Fri Mar 05, 2004 5:31 pm

How can I patch kernels 2.6.x where x>1 ??
How can I patch 2.6.2, 2.6.3 kernels ?
Fede

sleek · Post by **sleek** » Fri Mar 05, 2004 11:29 pm

I use 2.6.3 and I had no problems patching it with the newest ACPI patch, the DSDT Override patch, and the ECDT patch. I get the same ACPI support with 2.6.3 that I did when I patched my 2.4.24 kernel.

Have you tried these patches? If so, what did you have problems with?

federico · Post by **federico** » Fri Mar 12, 2004 11:49 pm

I've got my patch

But the problem I have, also with mi DSDT fixes is that, I want to show it to you
http://www.sideralis.net/blackman/battery.png

I can see the status of my battery two times ans stop..

Jefklak · Post by **Jefklak** » Thu Mar 18, 2004 8:42 pm

Very nice guide!
I'm having the same errors as tkoster,
" Unknown reserved name ^ (_S0D)" upon 4 times... I don't have any idea how to fix them... Did you figure out what it means jetblack? I did a google but couldn't find anything usefull... Every ACPI aspect "works" but my cpu temprature is WAYY to hot (in linux over 50° even is idle, in windows idle around 33) so I tought it's the DSDT... I solved 1 error (except the 4 warnings) but still no go

apeitheo · Post by **apeitheo** » Thu Mar 18, 2004 9:21 pm

Hello,

I have recently bought a new compuer, its a HP Pavilion a205w with a 2.7GHz celeron processor. Upon booting it up into Windows for the first time, the CPU fan was loud at first but then once at the login prompt it got quiet. I installed Gentoo the next day, and the CPU fan stays loud (It goes fast all the time instead of slowing down, and then speeding up when hot) I can run echo 3 > /proc/acpi/fan/FAN1/state and have it turn down, but then I can not get it back up again. I have discovered that it is most likely my DSDT. So I did what I found, and I get 1 error

Code: Select all

dsdt.dsl    64: If (\FCEN) {
Error    1037 -  ^ parse error, unexpected PARSEOP_IF

So then I went into the dsdt.dsl file and found the line, and the code around it, here it is:

Code: Select all

If (\FCEN) {
        Scope (\_TZ)
        {
            PowerResource (FN01, 0x00, 0x0000)
            {
                Method (_STA, 0, NotSerialized)
                {
                    Return (0x01)
                }

                Method (_ON, 0, NotSerialized)
                {
                    \_SB.PCI0.LPC0.SIO.WR00 (0x07, 0x0A)
                    \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x01)
                    Store (0x7E, \FAN1)
                    Store (0x7E, \FAN2)
                    Store (0x01, \_TZ.THRM.FNON)
                    Notify (\_TZ.THRM, 0x81)
                    Store (0xCC, DBGP)
                    \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x00)
                }

                Method (_OFF, 0, NotSerialized)
                {
                    \_SB.PCI0.LPC0.SIO.WR00 (0x07, 0x0A)
                    \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x01)
                    Store (0x04, \FAN1)
                    Store (0x6A, \FAN2)
                    Store (0x00, \_TZ.THRM.FNON)
                    Notify (\_TZ.THRM, 0x81)
                    Store (0xDD, DBGP)
                    \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x00)
                }
            }

            Device (FAN1)
            {
                Name (_HID, EisaId ("PNP0C0B"))
                Name (_UID, 0x01)
                Name (_PR0, Package (0x01)
                {
                    FN01
                })
            }

I see that there is some code in there that talks about FAN1, so I think this is the problem, anyone know how I can fix this? (Note: I'm on a desktop, NOT a laptop) Please help anyone?

dogshu · Post by **dogshu** » Wed Mar 24, 2004 1:15 am

I have a Toshiba 7140CT laptop, made in 1999. There were 30+ warnings, but all I had to do for every single one of them is change:

Method (_STA, 0, NotSerialized)
{
STAL (0x60)
}

to:

Method (_STA, 0, NotSerialized)
{
Return (STAL (0x60))
}

STA is just an example, there were other methods which needed changing, but in every case it just took adding Return () around the one line of the method.

So easy! Now ACPI is working perfectly on this half-decade-old laptop.

confusion · Post by **confusion** » Thu Mar 25, 2004 7:35 pm

I have an asus A7N8X-X motherboard and ive recently been trying to get ACPI working. I tried disassembling the DSDT and found one error; i "fixed" it.

The problem remains the same. I wanted ACPI functionality in order to set processor states from C1 to C2 to bring the temperature down at idle times. This seems to work fine in windows, but not in linux. i have /proc/acpi/processor/CPU0/info, limit, power, and throttling, but info and power contain the following.

Code: Select all

processor id:            0
acpi id:                 0
bus mastering control:   no
power management:        no
throttling control:      no
limit interface:         no

Code: Select all

active state:            C1
default state:           C1
bus master activity:     00000000
states:
   *C1:                  promotion[--] demotion[--] latency[000] usage[00000000]
    C2:                  <not supported>
    C3:                  <not supported>

As you can see it states that C2 is not supported. Surely it must be if i have experienced processor sleep states in windows? Am i missing some kind of configuration stage here or something? I tried setting acpi_os_name to win but theres little or no _OS related code in the DSDT anyway.

Slightly miffed, exponentially baffled, awaiting any response

Cheers,
-John

Jefklak · Post by **Jefklak** » Sun Apr 04, 2004 9:16 am

*bump*
Anyone knows how to solve my problem {see my reply above}?
Thanks!

TinheadNed · Post by **TinheadNed** » Thu Apr 08, 2004 12:42 pm

Any idea on how to solve "Table [DSDT] replaced by host OS" problems? I've got it every time I've tried to fix DSDTs on various computers over the years. I'm assuming it means my DSDT was rejected by the laptop. Is that right?

And, confusion, I'm assuming you have a desktop chip, and as such is unlikely to support changing performance profiles.

dogshu · Post by **dogshu** » Fri Apr 09, 2004 7:21 pm

"Table [DSDT] replaced by host OS" means that the host OS (Linux) replaced the system's DSDT. That is exactly what you want to happen, and is the entire point of this thread.

TinheadNed · Post by **TinheadNed** » Sat Apr 10, 2004 6:51 am

Well that's good then. Unfortunately it means the new one doesn't make any difference on the old - and neither does changing the _OS variable.

There is definitely OS specific code in there, similar to what's been in this thread, but trying different string lengths made little difference

[/quote]

psyeye · Post by **psyeye** » Thu May 27, 2004 9:41 pm

Hello, maybe someone is still watching this thread...
(I have posted it in its own thread, no answer so far, this is my second try):

I'd like to switch to 2.6.6; kernel from kernel.org, patched with swsusp2 and acpi-dsdt-initrd

My (self-corrected) DSDT is not loaded for reasons I do not understand... I even re-did the correction, with no luck.
It all runs well with 2.6.1! Odd, isn't it?

dmesg output:

Code: Select all

ACPI: Using customized DSDT
    ACPI-0196: *** Warning: Invalid checksum in table [DSDT] (E8, sum 61 is not
zero)
    ACPI-0299: *** Info: Table [DSDT] replaced by host OS
    ACPI-0307: *** Error: ns_search_and_enter: Bad character in ACPI Name: 5F
    ACPI-0279: *** Error: Looking up [0x005F] (NON-ASCII)
 in namespace, AE_BAD_CHARACTER
    ACPI-1133: *** Error: [NULL NAME], AE_BAD_CHARACTER
    ACPI-0125: *** Error: acpi_load_tables: Could not load namespace: AE_BAD_CHARACTER
    ACPI-0134: *** Error: acpi_load_tables: Could not load tables: AE_BAD_CHARACTER
ACPI: Unable to load the System Description Tables

What could I do? ACPI and kernel 2.6.6 fails completely with the very same DSDT that runs flawlessly with 2.6.1. Without provided DSDT, I have no battery-stat and other things fail too...
Any help is really appreciated!

greets,
psyeye