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

[Moderato]

This could be possible, but I'd rather wouldn't say "yes" at this time.

[cradlebin]

Hmm I tried all the things outlined in this tutorial, and on the official page of the DSDT-patch, but I always get this when I boot with the changed initrd file (created using the tool on the official page (initrd-add-dsdt.sh):

Code: Select all

UDF-fs: no partition found
XFS: bad magic number
XFS: SB validate failed
No filesystem could mount rout, tried: reiserfs ext3 ... (a whole list)
kernel panic - not syncing: VFS: Unable to mount root fs on unknown_block(1,0)

My grub conf looks like this:

Code: Select all

title=Gentoo Linux (kernel 2.6.17-r4)
root (hd0,1)
kernel (hd0,1)/boot/kernel-genkernel-x86-2.6.17-gentoo-r4 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda2 doscsi video=vesafb:ywrap,mtrr:3,1280x800-32@75
initrd (hd0,1)/boot/initramfs-genkernel-x86-2.6.17-gentoo-r4

My kernel is 2.6.17-r4 (gentoo-sources), I applied the acpi-dsdt-initrd-v0.8.2-2.6.17.patch found at http://gaugusch.at/kernel.shtml, I also tried patching the kernel with the acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch patch, but that didn't help.
I even tried to add DSDT.aml the old way, with the echo thing, but to no avail as well.

In Dmesg i do get:

Code: Select all

ACPI: DSDT (v001  255EI 255EI008 0x00000008 INTL 0x02002026) @ 0x00000000
ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.

So the patch should be applied just fine.


Anyone has any thoughts on how I can put it in my initrd?

[juangamnik]

I have the following output of iasl:

Code: Select all

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060512 [Aug  4 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl  4220:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4234:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4249:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4264:             Acquire (MUTE, 0x0FFF)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4278:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4293:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4308:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

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

dsdt.dsl  4521:                 Return (Stall (0x0F))
Error    4094 -                             ^ syntax error, unexpected PARSEOP_STALL

ASL Input:  dsdt.dsl - 4793 lines, 147191 bytes, 2014 keywords
Compilation complete. 1 Errors, 8 Warnings, 0 Remarks, 638 Optimizations

Ideas how to solve? I have an MSI S262 with T2500 core duo processor. Are there any fixed DSDTs out there?

[cradlebin]

The warnings can be easily solved by replacing all the 0xXXXX (with XXXX different from FFFF) by 0xFFFF.
The reason is that when one wants to release a Mutex, one has to be sure he got it, and that's only going to happen if the wait-loop-time is set to infinity (=FFFF).
That's the explanation I've got from some google page anyhow.

With the "Not all control paths return a value (WFZF)", you should just check for things like if-else-clauses that don't return a value.

[juangamnik]

Thank you very much. Do you know what the syntax error means? There is no method called Stall, so it must be somehow part of the environment? If it is a method, there's no syntax error, is there? It might be a macro... I removed the Stall(0xXXXX) and the syntax error was gone, but I don't know if that's right...!

[anz]

[SOLVED] Before my useless stumble begins: Thank you for that fine howto!

Dear juangamnik,

I also have a MSI S262, patched the kernel (2.6.17-gentoo-r4) with the acpi-patch from gaugusch.
The dsdt.sdl outputs are similar - I also removed the Stall(0x0F), put the DSTD.aml in the initramfs.

But: after rebooting, dmesg shows me:

dmesg | grep DSDT
ACPI: DSDT (v001 MSI 1057 0x06212006 INTL 0x02002026) @ 0x00000000
ACPI: Looking for DSDT in initramfs... successfully read 16642 bytes from /DSDT.aml.
ACPI (tbget-0290): Table [DSDT] replaced by host OS [20060127]

... but no battery, AC-adaptor, power button, sleep states etc. are found ...
Any hints?

a very usefull link:
howto decompress/compress initramfs - Thanks alot to widan


-----------------------------

UPDATE:
I am such an idiot - I forgot to compile "AC Adaptor" and "Battery" into the kernel (not as module).
Now a

Code: Select all

dmesg | grep ACPI | grep batter

shows

ACPI: Battery Slot [BAT1] (battery present)

[justcme]

Does this look, umm... problematic?

Code: Select all

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

ACPI Error (nsaccess-0531): ACPI path has too many parent prefixes (^) - reached beyond root node [20060912]

Maximum error count (200) exceeded
dsdt.dsl    24:     External (^^^PEGP.EGFX._PSC)
Error    4014 -         From ACPI CA Subsystem ^  (AE_NOT_FOUND Failure from lookup %s
)

dsdt.dsl    26:     OperationRegion (XNTI, SystemMemory, 0x000F3261, 0x0062)
Error    4062 -   Object does not exist ^  (XNTI)


...
... * lots more "Object does not exist ^ (FOO)" *
...


dsdt.dsl   294:         RP2D,   1,
Error    4062 -            ^ Object does not exist (RP2D)


Maximum error count (200) exceeded
ASL Input:  dsdt.dsl - 9061 lines, 320827 bytes, 3510 keywords
Compilation complete. 201 Errors, 0 Warnings, 0 Remarks, 7 Optimizations

201 Errors? error count exceeded???

any have any ideas?
in particular, this error:
ACPI Error (nsaccess-0531): ACPI path has too many parent prefixes (^) - reached beyond root node [20060912]

hope someone has a solution / potential solution.

thanks

[colchaodemola]

I have a pavillion dv8230us and i get only one warning when i try to compile dsdt

# iasl -tc dsdt.dsl

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

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

ASL Input: dsdt.dsl - 5881 lines, 231305 bytes, 2171 keywords
AML Output: dsdt.aml - 25312 bytes 504 named objects 1667 executable opcodes

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


Anyone know how to fix that ?

Is it possible that just one warning lead to so much errors like

Jan 6 00:30:19 localhost kernel: ACPI Error (psargs-0355): [PBST] Namespace lookup failure, AE_NOT_FOUND
Jan 6 00:30:19 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node c1910770), AE_NOT_FOUND
Jan 6 00:30:19 localhost kernel: ACPI Exception (acpi_battery-0207): AE_NOT_FOUND, Evaluating _BST [20060707]


in the syslog... I have big problems in battery power detection

[SDark]

Hi guys.

I've been using using a custom DSDT table for Acer Aspire 1694LMi for quite some time.

So far everything works fine but one thing seems to be working "way too fine".

The problem is the LID button. It is working but it generates about 4~5 events per second. This is a pain for cpufreq if the configuration is to read the acpid socket (the default behaviour) causing huge CPU loads when the lid is closed (definitely not idle). This can be solved by setting a non existing address for the socket but can also prevent other features...

But this is not the main problem. The fact is that if I keep my lid closed for some time the acpid logs get huge. +10~15Mb per hour.

My questions to the more experienced ones are:

Does the DSDT table has something to do with this

if so,

Is it possible to change the number of events to something like 1 event per 10 seconds or so, instead of the 4~5 per second

Thanks in advance to everyone.

[Crono81]

same lid problem here, with an asus a6tc.

[Crono81]

Ok, i'm trying to fix it. I really know nothing about acpi, dsdt, but it seems that i can still do better than the asus crew.

1) You have to edit the DSDT, search for the LID device definitions and similar things, and.. DELETE them

2) Compile it. After you've fixed all the stupid syntax errors.

3) You have to just ignore all that bullshit about simply copying the dsdt in /boot etc, and use cpio to create the image, here is an example: (thanks to widan)

Code: Select all

# find . -print | cpio -o -H newc > ../initramfs
# cd ..
(if you want)
# gzip initramfs

In our case, we only have the DSDT.aml (caps) file.

4) add the initrd=/boot/initramfs in grub.
5) Useless lid events bye bye (useless because in my laptop the screen is turned off by hardware)

[SDark]

That can be a solution, but I would prefer keeping the LID events to activate some scripts like toggle for ATI POWERplay...

I just want to reduce the number of events generated... The ideal would be 1 event on LID close and 1 event on LID open.

The sleep button generates only 1 event, but it's only on keypress, not on release. So copying this part wouldn't be enough.

The AC adapter is probably the closest to the behavior I want. It generates 1 AC_adapter event and 2 Battery events (1 for BAT1 and 1 for BAT2). It does this only once on AC unplugging and again on AC plugging. With a total of 6 events on a possible power failure .

I want that with the LID too. 1 for close and 1 for open...

Is it possible? by messing around with the DSDT? I haven't tried it yet because I don't know if this can be arranged by changing the DSDT...

[Crono81]

I really don't know what i'm doing, but it seems to work.

I replaced

Code: Select all

Device (LID)
                    {
                        Name (_HID, EisaId ("PNP0C0D"))
                        Method (_LID, 0, NotSerialized)
                        {
                            Store (0x00, LIDP)
                            Sleep (0x0A)
                            Store (LIDS, Local0)
                            Store (0x08, LIDP)
                            Return (Local0)
                        }
                    }

with (sorry for bad indenting)

Code: Select all

Device (LID)
                    {
                        Name (_HID, EisaId ("PNP0C0D"))
                        Method (_LID, 0, NotSerialized)
                        {
				Store (0x01, LIDS)
              			If (LIDS)
                		  {
                    		     If (LIDP)
                    		       {
	                                 Store (0x00, Local0)
        		                }
		                     Else
		                       {
	        	                Store (0x01, Local0)
	               		        }
		                   }
		                Else
	        	          {
	                	    Store (LIDP, Local0)
		                  }
	                Return (Local0)
                        }
                    }

And now i get a SINGLE lid event when i open and when i close. I still have to figure out if i get the same lid event, or two different lid events.

[lcld]

Code: Select all

Method (_LID, 0, NotSerialized)
{
	Store (0x01, LIDS)
	If (LIDS)
	{
		If (LIDP)
		{
			Store (0x00, Local0)
		}
		Else
		{
			Store (0x01, Local0)
		}
	}
	Else
	{
		Store (LIDP, Local0)
	}
	Return (Local0)
}

Ouch! Did you copy this code from SDark's dsdt? That won't help him.
Anyway, this code is strange. And I think that on A6T(c) laptops, the LIDS variable is read-only.

In fact, your code does nothing else but returning 1:

Code: Select all

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

I still have to figure out if i get the same lid event, or two different lid events.

There's /proc/acpi/button/lid/LID/state for that, but its value is the value returned by _LID: you have lid events but state will always be 'open'.

Note that if _LID returns 0, acpi hot keys are disabled.

I tried a lot of things but without success. The LIDP variable is a mystery.

[SDark]

Actually after messing around with the dsdt that I linked above I simply got boot hangs. I thought that was the custom dsdt I was using but it's not. After diffing this dsdt with the original one there where a lot of differences. So I gave up on this one.

I tried to apply manually some of the dsdt entries to the original one and got better results, however the LID saw no changes. I did the changes based on some links I found in the web that related to my laptop model (acer aspire 1694 LMi or WLMI).

Here you can get a copy of what I've been working on...

The current dsdt solves the BAT issues, as well as the noapic at boot need. Not using this usually hanged the system at boot. However the LID problem is still there.

lcld you seem a bit more experienced that us, could you take a look at the custom dsdt file and see if something jumps out of the code and you put some light in this darkness?

Thanks

[lcld]

I am just discovering AML (ACPI Machine Language) and I have the feeling that even if I knew the ACPI specs by heart, I couldn't help because of the lack of hardware documentation. Anyway, I read several people destroyed their machines by making mistakes in the dsdt so there are modifications I won't try.

About the lid, to summary the situation of my laptop :
- With the original dsdt, I have the same problem as you (with a higher rate: 37Hz) and /proc/acpi/button/lid/LID/state gives correct values ('open' when it's open and 'closed' when it's closed).
- With the modified dsdt, I have a single lid event when I close it, and another one when I open it, but /proc/acpi/button/lid/LID/state always returns 'open'.

In both cases, the lid events aren't really usable, but the modified dsdt is still better since it minimizes the CPU usage.

The same change should be possible for your laptop: replace

Code: Select all

            Method (_LID, 0, NotSerialized)
            {
                ...
            }

by

Code: Select all

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

Otherwise, for acpid, you can disable logging and tell it to ignore lid events (on Debian, I rename '/etc/acpi/events/lid' to '/etc/acpi/events/#lid') to reduce CPU usage a little.

BTW, iasl 20060127 and iasl 20060912 produces different outputs so it's difficult to compare with diff.

[Crono81]

Ouch! Did you copy this code from SDark's dsdt? That won't help him.

i got that piece of code from the dsdt of an Acer laptop...

[SDark]

Guys have a look at this.

There seems to be a full suite to test the ACPI behavior on your machine ... I just found out that my acpi thermal throttling support is "passive"... Same goes for fan stuff. A lot is missing here (not sure if in windows this is present).

I'm going to start at the linux-acpi mailing lists to see if someone "inside" can tip me on this.

I've been reading a lot about this and I have a bunch of questions.

1- Ok so the MS compiler is in fact one of the problems when it comes to original buggy dsdt right

2- However in Windows the ACPI works fine... Does that means they use some sort of custom dsdt too

3- From what I understood, if things work under windows, it means that the hardware is there. However is not being correctly addressed under Linux (right)

4- Does this means that ALL the problems or unsupported features about ACPI in Linux are due to bugged or incorrect ACPI tables (not only DSDT)

5- If one of the problems is knowing what to address when it comes to the hardware, isn't there any way to figure this out (even if it means trying to get info from within windows)

6- And finally, ACPI is supposed to have standards, however things aren't always addressed as they should partially due to Microsoft faulty compiler, then what and how can a user solve this problem or should this be left for the kernel team

About the 6th question, I did what the howto pointed and got a dsdt with only one warning that I don't know how to fix:

Code: Select all

dsdt.custom.lid-hack.dsl  7598:                             And (0xFE, Local7)
Warning  1104 -          Result is not used, operator has no effect ^ 

But even after fixing the errors there are still missing features.

About the lid, I did what lcld suggested but haven't tested it yet.

[lcld]

Code: Select all

dsdt.custom.lid-hack.dsl  7598:                             And (0xFE, Local7)
Warning  1104 -          Result is not used, operator has no effect ^ 

The line belongs to the _BST method. If you look at the ACPI specs at page 321, you'll see:

_BST: Returns the current battery status (in other words, dynamic information about the battery, such as whether the battery is currently charging or discharging, an estimate of the remaining battery capacity, and so on).

So fixing this warning may only improve battery monitoring. If it already works perfectly, ignore it (or remove the line since it doesn't do anything). Otherwise, you can try:

Code: Select all

-                            And (0xFE, Local7)
+                            And (Local7, 0xFE, Local7)

Without understanding what _BST does, that's all I can suggest.

Edit: I should have wait a little before posting. Local7 is the 1st value returned by _BST, and according to the specs, bit 0 means 'discharging', bit 1 'charging' and bit 2 'critical energy state'. Line 7598 is executed if and only if the battery is in the critical energy state (see the following line: Or (Local7, 0x04, Local7) ; there is no other reference of Local7.2 elsewhere). Therefore, 'And (0xFE, Local7)' must be removed (or left as is).

[SDark]

Actually I do have a small issue with the battery monitor, but it isn't that harsh. The issue only happens when the battery is charging, reporting a "present rate:" value that is way off scale.
This was a problem with conky battery monitor, and the estimate time to fully charged.

But that was never a real problem because the percentage is still correct.

About the Edit, you mean that in this case, I should keep that line untouched or remove it?

[lcld]

you mean that in this case, I should keep that line untouched or remove it?

I don't understand. If that line does nothing, it is obvious that leaving it untouched or removing it are exactly the same thing.
And what I was writing in my previous post is that this warning is a false alert: there is nothing wrong there.

The issue only happens when the battery is charging, reporting a "present rate:" value that is way off scale.

The value is computed in Local3. An example of value way off scale would help.

[SDark]

Discharging state:

Code: Select all

present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1208 mA
remaining capacity:      3429 mAh
present voltage:         1 mV

Charging state:

Code: Select all

present:                 yes
capacity state:          ok
charging state:          charging
present rate:            63699 mA   <----
remaining capacity:      2544 mAh
present voltage:         2 mV

[lcld]

Huh?? I wasn't expecting such a value. I don't understand how _BST can return a rate of 63699 mA. Note that the correct value is probably 64k-63699 ~ 1837 mA.

The DSDT supports 2 batteries. I suppose it's BAT1. I think the present rate is ajusted at lines 7348-7356:

Code: Select all

                    If (LAnd (Local3, 0x8000))
                    {
                        If (LNot (LEqual (Local3, 0xFFFF)))
                        {
                            Not (Local3, Local3)
                            Increment (Local3)
                            And (Local3, 0xFFFF, Local3)
                        }
                    }

It might be interesting to delete them.

A part from that, there's an error for the present voltage (1&2 mV). Here is a fix (lines 7345 and 7611):

Code: Select all

-                        Store (Local7, Index (PBST, 0x03))
+                        Store (Local2, Index (PBST, 0x03))

[SDark]

Tried the lid patch, to return always 1. But that didn't solve the event number. In fact the lid always showed up as open, but the high number of events was still generated while the lid was closed. I guess the notification is looped elsewhere.

Applied the BAT patch and removed that part as suggested and here are the results:

discharging_BAT1_info

Code: Select all

present:                 yes
design capacity:         4300 mAh
last full capacity:      3470 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 300 mAh
design capacity low:     132 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            ZL08
serial number:           20617
battery type:            LION
OEM info:                SONY

discharging_BAT1_state

Code: Select all

present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            62961 mA
remaining capacity:      3043 mAh
present voltage:         15049 mV

charging_BAT1_info

Code: Select all

present:                 yes
design capacity:         4300 mAh
last full capacity:      3470 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 300 mAh
design capacity low:     132 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            ZL08
serial number:           20617
battery type:            LION
OEM info:                SONY

charging_BAT1_state

Code: Select all

present:                 yes
capacity state:          ok
charging state:          charging
present rate:            1285 mA
remaining capacity:      2968 mAh
present voltage:         16374 mV

With these values conky's estimate time for empty bat was about 2m 53s.
When charging conky showed up about 22 min to full.

I must say that it seems that the behavior was inverted. I remember conky doing the opposite. The time calculations when charging was incorrect and when discharging was correct. Now with the dsdt patch the time when charging seems correct but when discharging isn't.

Any ideas?

Thanks for all the help and effort

EDIT: Inserting back the code that was removed makes everything like was before. i.e. like in the previous post.

[lcld]

At least, there's something fixed: present voltage

I guess the notification is looped elsewhere.

I see nothing so perhaps that a variable needs to be ajusted, as in the example of the ACPI specs. So: LIDS or LIDP ? If the variables of well-named, the example would say LIDP. But according to the original code, only LIDS would be writeable. Another strange thing
Unfortunately, we don't know if writing to LIDP, or clearing LIDS are safe.

We only know that setting LIDS and reading LIDS/LIDP are safe. You can still debug safely in _LID and try to understand LIDS and LIDP better. Here are several examples :

Code: Select all

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

Code: Select all

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

Code: Select all

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

These pieces of code might help to simplify the original code.

To test the lid, I usually use the following command:

Code: Select all

# acpi_listen | while read; do cat /proc/acpi/button/lid/LID/state; done

For the present rate, I think I'm blind Try this (lines 7348 and 7614):

Code: Select all

-                    If (LAnd (Local3, 0x8000))
+                    If (And (Local3, 0x8000))