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

Message

SDark · Post by **SDark** » Tue Mar 06, 2007 11:53 pm

lcld wrote:
SDark wrote:I guess the notification is looped elsewhere.
I see nothing so

Could line 449 have something to do with the notifications? Do you have any idea what I could change this to and test if something changes?

I'm testing the stuff you mentioned before, will post the results in some minutes...

lcld · Post by **lcld** » Wed Mar 07, 2007 12:13 am

Yes, this line is related to lid events but it seems correct. On my laptop, with:

Code: Select all

                    Method (_L12, 0, Serialized)
                    {
                        Notify (\_SB.LID, 0x80)
                    }
                    ...
                        Method (_LID, 0, NotSerialized)
                        {
                            Return (One)
                        }

I don't have repeated events.

If you delete the Notify line, you should have no event at all.

SDark · Post by **SDark** » Wed Mar 07, 2007 2:06 am

According to your code It seems that you have "Serialized" Method. Here is:

Code: Select all

Method (_L1B, 0, NotSerialized)
        {
            Notify (\_SB.LID, 0x80)
        }

Is this the answer?

lcld · Post by **lcld** » Wed Mar 07, 2007 2:17 am

I didn't notice. The difference is explained at page 503 of the specs but that doesn't help me a lot.
I think you can try Serialized without any risk.

SDark · Post by **SDark** » Wed Mar 07, 2007 2:31 am

Some results:

The "present rate:" seems fixed

charging:

Code: Select all

present:                 yes
capacity state:          ok
charging state:          charging
present rate:            1213 mA
remaining capacity:      1081 mAh
present voltage:         15782 mV

discharging:

Code: Select all

present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1713 mA
remaining capacity:      1083 mAh
present voltage:         14629 mV

Now for the lid parts:

Code: Select all

Method (_LID, 0, NotSerialized)
            {
                Return (LIDS)
            }

Results:
When not pressing, no event is logged and state is closed
When pressing, the flooding starts and the state changes to open
Basically state is reversed but the events are still only when pressing the lid key.

Code: Select all

Method (_LID, 0, NotSerialized)
            {
                Return (LIDP)
            }

When not pressing, no event is logged and state is open
When pressing, the flooding starts and the state remains open
Basically state doesn't change but the events are still flooding when pressing the lid key.

Code: Select all

Method (_LID, 0, NotSerialized)
            {
                Store (One, LIDS)
                Return (LIDS)
            }

Same as 1st case.

Next will try the Serialized with the original code and then with the Return 1

lcld · Post by **lcld** » Wed Mar 07, 2007 3:09 am

Interesting. Here is a possible fix:

Code: Select all

            Method (_LID, 0, NotSerialized)
            {
                If (LIDS)
                {
                    Not (LIDP, LIDP)
                }
                Return (LIDP)
            }

About the 'Not (LIDP, LIDP)' instruction, be aware that we don't know if writing to LIDP is safe.

SDark · Post by **SDark** » Wed Mar 07, 2007 4:05 am

Ok tried the Serialized stuff, but nothing worked.

I'm going to try what you suggested about LIDP.

What could be the results by writing to something that "is not safe" ? Hardware damage?

lcld · Post by **lcld** » Wed Mar 07, 2007 4:51 am

What could be the results by writing to something that "is not safe" ?

The million-dollar question... I mean that LIDP and LIDS aren't simple variables. The 'Store (0x01, LIDS); If/Return (LIDS)' show this well: even if a 1 has been written, reading it may return 0.
I suppose LIDS and LIDP are ports and they may command/read electrical levels (of what?). In that case, this is not computer science anymore, but electronics.
So what could be the results if my code is wrong? I don't know.

Hardware should be designed so that it can't be destroyed by software but sometimes, conceptors/constructors do their job badly. I read several people killed their machine (or only a component) after having modified their dsdt incorrectly. I wonder which kind of error they did.

My intuition (and nothing else) is that writing to LIDP is safe. I would have post that piece of code otherwise.

SDark · Post by **SDark** » Wed Mar 07, 2007 5:14 am

Ok I trust in your expertise

however explain this

Did the changes about LIDP and what happened was:

Computer starts. ACPI logs are clean, i.e. no events generated. Lid state is open.

1- Tap the key. Lid state changes to closed and a few of events showed up in acpid (no fix yet).

2- After releasing the key the Lid state becomes open and events stopped.

3- Hold the key for a few seconds. Events flood while pressing the key. lid shows closed.

4- Release the key. lid shows open. however events keep coming and continue even when the key is not pressed.

I tried to release and press again but nothing changed. It "seems" that the events where generated at a slower rate while not pressing the button, but the fact that they show up when not pressing seems the opposite to what we want.

I noticed one thing that haven't noticed before. Every event in lid increments 1 to the last number count. This does not happen with AC events. In fact AC with value 0 means unplugged and AC with value 1 means plugged.
LID just keeps counting 1,2,3 ...

I also tried to toggle that Serialize part but nothing changed either.

I uploaded an acpid log with the events generated in the last tests. Link here

I'm off for today, will be back tomorrow around 4pm (GMT)

lcld · Post by **lcld** » Wed Mar 07, 2007 11:21 pm

What can I conclude from such a random behaviour? That's not encouraging.

I don't know what to tell apart from suggesting you to test more rigorously. I mean that even if a piece of code is not the solution, we should learn something from it.
I would stop acpid during tests and, for example, use the following command:

Code: Select all

/proc/acpi/button/lid/LID# acpi_listen | while read a; do echo -e "`cat state`\t$a"; done

and the following actions:
- close the lid
- open the lid
- press an acpi key while it is closed, several times (at a higher rate than the lid events, if possible)
- press an acpi key while it is open, several times (...)

The reason is when _LID has side effects (that's the case for my suggested fix), it is important to see the results of consecutive calls.

Oh and use the following code instead, to prevent a possible bouncing effect:

Code: Select all

            Method (_LID, 0, NotSerialized)
            {
                Sleep (16)
                If (LIDS)
                {
                    Not (LIDP, LIDP)
                    Sleep (16)
                }
                Return (LIDP)
            }

Note that for my laptop, I have given up. I found a workaround but it stops working after a suspend/resume.

Edit: Oops, acpi_listen doesn't work if acpid is stopped.

SDark · Post by **SDark** » Thu Mar 08, 2007 4:27 pm

Used the code with the Sleep entries. Tried to do several tests but the results aren't very clear because there seems to be a lot of randomness here.

I added a time stamp to the command to better check how fast the events are and the relation between events and time. Time is in format: date +%T.%N

log downloads here

I tried to include echos in the file to show the moment when I stopped or changed an action.

On some logs I released the keys and there where events still coming up. I ended the logs only when the events stopped.

Files:

Code: Select all

hold_and_nothing - Just holding the lid button and then release
hold_and_sleep - Holding the button and tapping the sleep key during the process
tap_and_nothing_else - Tapping the lid button and then stop tapping
tap_and_sleep - Tapping the lid and the sleep button (tried to tap them both at the same time)
tap_hold_release_with_comments - Tapped the lid, then hold and after a while released. Added comments every time I changed an action.

Hope this helps... To me this makes no sense as I don't see direct relations from events.

lcld · Post by **lcld** » Thu Mar 08, 2007 5:17 pm

however events keep coming and continue even when the key is not pressed

On some logs I released the keys and there where events still coming up. I ended the logs only when the events stopped.

Do you mean that when the lid is open, there's always a moment when events stop coming? Or (still when it's open), does it happen that flooding never stops?

Just to be sure... what's the difference between "tap" and "hold"? Is the lid switch not "internal" to the laptop? Is it a sort a key? On mine, if I want to test what happened if I close the lid, I really have to close it: not very handy for the tests, because I see nothing.

hold_and_nothing:
I see that when it's closed, the state toggles between 'closed' and 'open'.
Same thing when it's open, as long as events keep coming.

tap_and_sleep:
16:02:58 -> 16:03:13: There is no lid event for 15 seconds whereas it's closed? Do that mean that reading the state may inhibit flooding?

For the moment, I have no idea of which code could be tested to understand LIDS/LIDP better.

SDark · Post by **SDark** » Sat Mar 10, 2007 12:38 am

The lid button is on the LCD lid but is accessible and I can press it. Its a small key under the LID. This way I managed to press or tap it and the sleep button during the process.

By tap I mean I press and release several times in the same second.
By hold I mean that I press and hold the lid button until "release".

lcld wrote:Do you mean that when the lid is open, there's always a moment when events stop coming? Or (still when it's open), does it happen that flooding never stops?

As far as I tested the events eventually stop. In this case I stopped the logging when the events ended. And yes, the events happen when the lid is open after a close period, like they are delayed and shown after some time... I did notice that they come in packs of 2 seconds after the release or the tapping:

Code: Select all

Time: 16:05:21.614780445  state:      closed    button/lid LID 00000080 000008b9
Time: 16:05:23.495548519  state:      closed    button/lid LID 00000080 000008ba
Time: 16:05:25.496927602  state:      closed    button/lid LID 00000080 000008be

lcld wrote:hold_and_nothing:
I see that when it's closed, the state toggles between 'closed' and 'open'.
Same thing when it's open, as long as events keep coming.

That is part of the randomness that I don't understand. When I hold or when I release shouldn't you expect always the same event? always close or always open?

lcld wrote:tap_and_sleep:
16:02:58 -> 16:03:13: There is no lid event for 15 seconds whereas it's closed? Do that mean that reading the state may inhibit flooding?

Did you mean the hold_and_sleep log? I can't find that timestamp in the log you mentioned.

hold_and_sleep:
It looks that way, I held the lid key and kept tapping the sleep key. I dunno what conclusion can be made about this.
I had another log that I held the lid key (and pressed no sleep key) and no event came out during about 15 seconds. After that time I released the lid key and some "delayed" events came out...

I can do some more tests but I dunno what to test nor how to be more precise... The events are mass triggered in nanoseconds, and sometimes randomized...

Anyway, thanks for all your help, If you have any ideas I will be glad to test them.

SDark · Post by **SDark** » Fri Mar 16, 2007 1:02 am

lcld I thought of something that will not fix the problem but could remove the unwanted flooding.

Instead of removing the Notifications code, would it be possible to use a big Sleep() number and reduce the number of events?
I haven't understood the Sleep() command. Does it causes the cycle to only happen from time to time or simply delays the event X seconds since the event entered the cycle?

If the case is the 1st option, then by using the Sleep inside the notify cycle I could reduce the number of events... That is one of the goals!

If the case is the 2nd, then nothing changes as the flooding would still be there, with the only difference of being delayed X seconds...

If you understand better how this works, and can answer this question I could try that... If not, I think I will remove the notification part so that no events pop up at all!

EDIT: Need to know what is the maximum value I can use in the Sleep setting ... I think a big number can take it to my goal and keep the lid events...

EDIT2: Yup Sleep can do the job, unlike Stall it holds the processor and so blocks the flooding. By using something like Sleep(300000) I have only 1 event every 5 minutes. I still need to test if opening the lid reports the event right away or if everything is stopped ... I don't want the sleep button to only report the event once in 5 minutes :\

SDark · Post by **SDark** » Fri Mar 16, 2007 9:10 pm

Ok no go

It seems that the Sleep event holds the whole process and Sleep keys are delayed until timeout.

I'm giving up on this ... Commenting out the notification code!
No lid events but at least no high CPU loads nor huge logs.

Thanks for all the help you gave me.

Animatrix · Post by **Animatrix** » Thu Apr 19, 2007 7:24 pm

Hello,

I would like to set a custom DSDT file directly in the kernel.
I am using a 2.6.20-r6 kernel.
Do you know where I can find a patch to add this option ?

Or, do you know how to create a *.aml file, and how to correct it.
Thanks

SDark · Post by **SDark** » Thu Apr 19, 2007 8:15 pm

Animatrix wrote:I would like to set a custom DSDT file directly in the kernel.
I am using a 2.6.20-r6 kernel.
Do you know where I can find a patch to add this option ?

If you are using the gentoo-sources, the patch is already included. If you are using plain vanilla-sources, you will have to patch it yourself. Please have a look at the 1st post in this thread. It has all the info you need.

Animatrix · Post by **Animatrix** » Thu Apr 19, 2007 8:57 pm

SDark wrote:
Animatrix wrote:I would like to set a custom DSDT file directly in the kernel.
I am using a 2.6.20-r6 kernel.
Do you know where I can find a patch to add this option ?
If you are using the gentoo-sources, the patch is already included. If you are using plain vanilla-sources, you will have to patch it yourself. Please have a look at the 1st post in this thread. It has all the info you need.

I am using the gentoo-sources, but I don't see the option.
Are-you sure it is included ?

SDark · Post by **SDark** » Tue Apr 24, 2007 9:28 pm

It should ... I've got this in my config

CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/etc/acpi/dsdt_table.h"

emmerp · Post by **emmerp** » Mon May 07, 2007 8:16 am

I have a Acer Travelmate, and was fighting with DSTD and sbs-linux to get it all work. But now I see on their site (http://sourceforge.net/projects/sbs-linux/) that smart battery system is supported from kernel 2.6.18.
The strange thing is that I can't find any SBS modules or whatsover in the .config (possibly it's just really really built in even without module

), but secondly, I see people on this forum wrambling with the DSTD things where it should be all supported in the kernel now...

Also, I can't find any release notes for the kernel which mention Smart Battery system support..

Can someone explain?

Edit: found the experimental sbs driver, now building new kernel, but still wondering why people don't use this...or is it a very unknown option?

SDark · Post by **SDark** » Mon May 07, 2007 10:21 pm

emmerp wrote:I have a Acer Travelmate, and was fighting with DSTD and sbs-linux to get it all work. But now I see on their site (http://sourceforge.net/projects/sbs-linux/) that smart battery system is supported from kernel 2.6.18.
The strange thing is that I can't find any SBS modules or whatsover in the .config (possibly it's just really really built in even without module ), but secondly, I see people on this forum wrambling with the DSTD things where it should be all supported in the kernel now...

Also, I can't find any release notes for the kernel which mention Smart Battery system support..

Can someone explain?

Edit: found the experimental sbs driver, now building new kernel, but still wondering why people don't use this...or is it a very unknown option?

I may be wrong but I think the smart battery stuff is deprecated, and now everything is going towards ACPI. I read somewhere that smart battery was something in the middle of APM and ACPI and was dropped since ACPI offered it all and with better organization.

beatryder · Post by **beatryder** » Fri May 11, 2007 4:13 pm

Hello,

I didn't have time to read all 13 pages of this thread but I have a Dell D620 with the following DSDT Errors.

Has anyone seen them before?

Code: Select all

Lisa ~ # cat /proc/acpi/dsdt > dsdt.dat
Lisa ~ # iasl -d dsdt.dat

Intel ACPI Component Architecture
AML Disassembler version 20060912 [Jan 21 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt.dat
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
.........................................................................................................................................................................................
.........................................................................................................................................................................................
.........................................................................................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"
Lisa ~ # iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060912 [Jan 21 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl  2928:                             Name (_T_0, Zero)
Error    4081 -                 Use of reserved word ^  (_T_0)

dsdt.dsl  2980:                                                         Name (_T_1, "")
Error    4081 -                                             Use of reserved word ^  (_T_1)

dsdt.dsl  3012:                             Name (_T_2, Zero)
Error    4081 -                 Use of reserved word ^  (_T_2)

dsdt.dsl  3039:                         Name (_T_0, Zero)
Error    4081 -             Use of reserved word ^  (_T_0)

dsdt.dsl  3215:                             Name (_T_0, Zero)
Error    4081 -                 Use of reserved word ^  (_T_0)

dsdt.dsl  3404:                             Name (_T_1, Zero)
Error    4081 -                 Use of reserved word ^  (_T_1)

dsdt.dsl  4324:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4382:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4440:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4498:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4556:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4614:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4672:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  4730:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

dsdt.dsl  5362:                     Return (Package (0x00) {})
Remark   5070 -    Effective AML package length is zero ^

dsdt.dsl  5540:                             Wait (EJTD, 0xA000)
Warning  1103 -         Possible operator timeout is ignored ^

ASL Input:  dsdt.dsl - 6349 lines, 226760 bytes, 1989 keywords
Compilation complete. 7 Errors, 9 Warnings, 1 Remarks, 677 Optimizations

atrus123 · Post by **atrus123** » Wed May 16, 2007 4:21 am

beatryder wrote:Hello,

I didn't have time to read all 13 pages of this thread but I have a Dell D620 with the following DSDT Errors.

Has anyone seen them before?

Code: Select all

dsdt.dsl  2928:                             Name (_T_0, Zero)
Error    4081 -                 Use of reserved word ^  (_T_0)

dsdt.dsl  2980:                                                         Name (_T_1, "")
Error    4081 -                                             Use of reserved word ^  (_T_1)

dsdt.dsl  3012:                             Name (_T_2, Zero)
Error    4081 -                 Use of reserved word ^  (_T_2)

dsdt.dsl  3039:                         Name (_T_0, Zero)
Error    4081 -             Use of reserved word ^  (_T_0)

dsdt.dsl  3215:                             Name (_T_0, Zero)
Error    4081 -                 Use of reserved word ^  (_T_0)

dsdt.dsl  3404:                             Name (_T_1, Zero)
Error    4081 -                 Use of reserved word ^  (_T_1)
sdt.dsl  4614:                         And (Local0, 0x0F)
Warning  1104 -                                   ^ Result is not used, operator has no effect

I'm currently working on the 'Use of reserved word' issue in my own file. You're getting that error because leading a word with an underscore isn't permitted apparently. Just take out the underscore and you're golden (I think -- still testing it myself.)

atrus123 · Post by **atrus123** » Wed May 16, 2007 8:36 pm

I've managed to clear up all but one of my thirteen errors and warnings. This one remains:

Code: Select all

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20061109 [May 15 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl  7288:             Method (EVNT, 1, NotSerialized)
Warning  1086 -                        ^ Not all control paths return a value (EVNT)

ASL Input:  dsdt.dsl - 8698 lines, 322281 bytes, 3478 keywords
AML Output: /home/atrus/Desktop/acpitests-unix-20061109/tests/dsdt.aml - 32133 bytes 782 named objects 2696 executable opcodes

Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 1235 Optimizations

And the code itself reads:

Code: Select all

            Method (EVNT, 1, NotSerialized)
            {
                While (VZOK)
                {
                    If (LEqual (VZOK, 0x01))
                    {
                        Store (Arg0, VZOK)
                        Notify (\_SB.VALZ, 0x80)
                        Return (Zero)
                    }
                    Else
                    {
                        Sleep (0x05)
                    }
                }
            }

Any suggestions? I'm not a coder so hacking this stuff does not come natural to me.

SDark · Post by **SDark** » Thu May 17, 2007 12:10 am

Guys can anyone clear this out for me, I'm a bit confused.

I'm using a debugged dsdt on my default gentoo instalation and the main reason why I (and those who helped) started messing with the dsdt was the lack of battery status. No info on current charge status.

Today I tried a liveCD of the latest kubuntu series, and I was surprised to see that the battery display was working just fine there... Same goes for slax (another liveCD). So it kinda hit me... How did they do it? I think that including custom dsdt's in the kernel would be impossible so how did they managed to make it work just like that?

Anyone has any ideas?