Forums

Skip to content

Advanced search
  • Quick links
    • Unanswered topics
    • Active topics
    • Search
  • FAQ
  • Login
  • Register
  • Board index Discussion & Documentation Documentation, Tips & Tricks
  • Search

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

Unofficial documentation for various parts of Gentoo Linux. Note: This is not a support forum.
Post Reply
Advanced search
394 posts
  • Page 3 of 16
    • Jump to page:
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • …
  • 16
  • Next
Author
Message
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Thu Jan 29, 2004 9:59 pm

First of all, thanks for this great article. I've been having many problems getting ACPI to work, so I'm hopeful that this is a possible solution to fixing it. I have successfully fixed all errors and warnings in my dsdt.dsl except for 1 warning:

Code: Select all

dsdt.dsl   255:             Method (_BTP, 1, NotSerialized)
Warning  2019 -                        ^ Not all control paths return a value (_BTP)
The code in question is this:

Code: Select all

Device (CMB0)
{
    Name (_HID, EisaId ("PNP0C0A"))
    Name (_UID, 0x01)
    Name (BATP, Ones)
    Name (_PCL, Package (0x01)
    {
        \_SB
    })
    ...
    ...
    ...
    Method (_BTP, 1, NotSerialized)
    {
        If (LEqual (\ECFL, Zero))
        {
            Return (0x0F)
        }
        Else
        {
            Store ("_SB.CMB0._BTP", Debug)
        }
    }
    ...
    ...
    ...
}
I know that I need to return a value at the end of this method, but what exactly would that be? Thanks!
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Thu Jan 29, 2004 10:27 pm

sleek wrote:First of all, thanks for this great article. I've been having many problems getting ACPI to work, so I'm hopeful that this is a possible solution to fixing it.
You're welcome. I hope it actually helps you; it seems to have been hit-or-miss so far.
sleek wrote:I have successfully fixed all errors and warnings in my dsdt.dsl except for 1 warning:

Code: Select all

dsdt.dsl   255:             Method (_BTP, 1, NotSerialized)
Warning  2019 -                        ^ Not all control paths return a value (_BTP)
The code in question is this:

Code: Select all

Device (CMB0)
{
    Name (_HID, EisaId ("PNP0C0A"))
    Name (_UID, 0x01)
    Name (BATP, Ones)
    Name (_PCL, Package (0x01)
    {
        \_SB
    })
    ...
    ...
    ...
    Method (_BTP, 1, NotSerialized)
    {
        If (LEqual (\ECFL, Zero))
        {
            Return (0x0F)
        }
        Else
        {
            Store ("_SB.CMB0._BTP", Debug)
        }
    }
    ...
    ...
    ...
}
I know that I need to return a value at the end of this method, but what exactly would that be? Thanks!
Well, it actually does return a value (0x0f) if ECFL=0. So, you'll only run into trouble here when ECFL != 0. In that case, it looks like it's just setting a debug message. So, the first thing to check would be where and how ECFL is set in your DSDT. I assume that it has something to do with the Embedded Controller. The _BTP method sets the battery trip point. So, I'm guessing that your battery depends on the embedded controller, so this checks to make sure that the Embedded Controller has been initialized before setting the battery trip point.

So, the short version is that this is probably OK. This method does have to return a value, but it's probably doing a test to make sure that everything that it depends on has been initialized first. If the Embedded Controller isn't there when you get to this, then you'll probably have bigger battery problems than just the trip point. ;)

You could probably make the Warning go away by returning 0x0F (which is what it seems to want to set the trip point to) after the "Store ..." bit, but I'd try it as is and see what happens first. Or dig around and see what causes ECFL to get set. If you want to post the bits of your DSDT that involve the ECFL variable, that would be fine.
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Fri Jan 30, 2004 12:12 am

So after I did all the stuff from your docs (i used the DSDT initrd patch), I rebooted and ACPI didn't work. It says my BIOS is from 2000 and is too old. So I then try with acpi=force on my kernel= line in grub.conf. ACPI still doesn't work. Here is the dmesg after booting with acpi=force:

http://sleek.solidbox.com/acpi.dmesg
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Fri Jan 30, 2004 12:17 am

yikes! This is new:

Code: Select all

ACPI: Vendor "PTLTD " System "  DSDT  " Revision 0x6040000 has a known ACPI BIOS problem.
ACPI: Reason: Multiple problems. This is a non-recoverable error
ACPI: BIOS listed in blacklist, disabling ACPI support
Not sure how to get around that. Is there a more recent BIOS that you could try upgrading to?
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Fri Jan 30, 2004 12:44 am

Ok, maybe this will help. I'm not sure what kernel you're running, but I found this in /usr/src/linux-2.6.1/drivers/acpi/blacklist.c:

Code: Select all

	{"PTLTD ", "  DSDT  ", 0x06040000, ACPI_DSDT, less_than_or_equal, "Multiple problems", 1},
I'm sure there's something similar in 2.4. Since it seems like it's saying the problem is with the DSDT, and since you have, in theory, fixed the DSDT, you could always try removing that line and recompiling. That should at least prevent the ACPI code from short-circuiting when it detects your BIOS version.

[EDIT]That line is in static struct acpi_blacklist_item acpi_blacklist[] [/EDIT]
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Fri Jan 30, 2004 2:50 am

I have made leaps and bounds! I'm using the 2.6.1 kernel still and commented out my blacklisted BIOS from the blacklist.c file. I still needed to keep the acpi=force in my kernel line, but lots of good things happened! Here is my updated dmesg:

http://sleek.solidbox.com/acpi.dmesg

Now I just need to fix the Embedded Controller errors and I think that I might be good to go! I'll keep you updated on my progress.
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Fri Jan 30, 2004 2:59 am

Great! I hope that ECDT patch helps you. It doesn't seem to be quite the silver bullet that I had hoped it was, but it does help a lot of the time for Embedded Controller issues.
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Fri Jan 30, 2004 6:33 am

Just wanted to say thanks! I have applied all the patches and am using the static DSDT. I have 2.4.23 with full ACPI support as well as framebuffer/bootsplash support fully operational!

I haven't tried to see if my battery will charge, etc., but everything shows up in /proc/acpi with no problems whatsoever.

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 8)

Good luck to everyone else who is still working on their ACPI!!!
Yesterday was the deadline for all complaints
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Fri Jan 30, 2004 3:57 pm

How do I make my laptop "sleep"?
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Fri Jan 30, 2004 4:12 pm

That's the million-dollar question.

Sleep support is *very* spotty. I've heard that suspend-to-disk works with the 2.4 kernels reasonably well, but I didn't have a whole lot of success.

The basic methodology is to echo values into /proc/acpi/sleep. To suspend to disk in 2.6, you would do this:

Code: Select all

echo 4 > /proc/acpi/sleep
You also need to tell it where to resume from on boot. To do that, add this to the kernel line in grub.conf:

Code: Select all

resume=/dev/<swap>
where <swap> is your swap partition.

With 2.4, I think you have to use swsusp.

There are other sleep states, too. There's a bit more documentation here. You may want to try it first without running X. People have much more success from console than X. Good luck!
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Sun Feb 01, 2004 3:51 am

Kick ASS. Those are two words that can very simply describe the usefulness and insight into this common problem with laptops. I use a Compaq Presario 1700 (17XL2) laptop. After hacking the DSDT and other power management code, I was able to enable ACPI support.

After following this guide and also installing swsusp (software suspend software), I was able to check my battery power, lid status, CPU temperature (thermal_zone), and other various information.

The best thing about this setup is the "Suspend to disk" feature where swsusp can provide functionallity equivalent to the Windows XP "hibernate" option.
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Mon Feb 02, 2004 6:10 pm

Added a couple of new sections for issues that have come up over the last week or so (acpi4asus, blacklisted BIOSes, etc).
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Mon Feb 02, 2004 6:18 pm

jetblack wrote:Added a couple of new sections for issues that have come up over the last week or so (acpi4asus, blacklisted BIOSes, etc).
One note that you might want to add to the blacklisted BIOS section is that the kernel line in grub or lilo will probably also require that "acpi=force" be included. This was the case for my laptop at least.
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Mon Feb 02, 2004 6:26 pm

sleek wrote:One note that you might want to add to the blacklisted BIOS section is that the kernel line in grub or lilo will probably also require that "acpi=force" be included. This was the case for my laptop at least.
Got it. Thanks!
Top
tkoster
n00b
n00b
Posts: 46
Joined: Mon May 26, 2003 2:30 am

  • Quote

Post by tkoster » Mon Feb 09, 2004 5:21 am

I'm running into a couple of problems as I try to smooth out my ACPI woes. In terms of the computer (Dell Inspiron 8600), I've got it all working except the battery levels and the sleep states. It can detect whether I'm running on battery or ac just not what the levels are.

The DSDT file comes up with five warnings when compiled. 1 is with the _WAK setting. I saw your earlier description of your fix but couldn't figure out where to put it. My two attempts just made it worse, though one of them made the other warnings disappear. The other 4 are _SOD settings which create a warning number 2003 "unknown reserved name".

Any clues for me?
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Mon Feb 09, 2004 5:37 am

If you post the compilation errors you get, then we might be able to assist you in how to fix them.
Yesterday was the deadline for all complaints
Top
theonlymcc
Apprentice
Apprentice
Posts: 274
Joined: Tue Sep 16, 2003 7:49 am
Location: NC

  • Quote

Post by theonlymcc » Mon Feb 09, 2004 9:03 am

Anyone with a Dell i5150 w/ 2.6 kernel got ACPI working? Fixed all my DSDT warnings but changed nothing.
Top
tkoster
n00b
n00b
Posts: 46
Joined: Mon May 26, 2003 2:30 am

  • Quote

Post by tkoster » Mon Feb 09, 2004 1:08 pm

Here are the warnings I get:

dsdt.dsl 627 Method (\_WAK, 1, NotSerialized)
warning: 2026 Reserved method must return a value (_WAK)

dsdt.dsl 1902 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 1945 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 2001 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 2045 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Mon Feb 09, 2004 2:11 pm

tkoster wrote:Here are the warnings I get:

dsdt.dsl 627 Method (\_WAK, 1, NotSerialized)
warning: 2026 Reserved method must return a value (_WAK)

dsdt.dsl 1902 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 1945 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 2001 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)

dsdt.dsl 2045 Method (_SOD, 0, NotSerialized)
warning: 2033 unknown reserved name (_SOD)
The _WAK method isn't causing your battery problem, and I wouldn't worry too much about it anyhow, since the ACPI drivers don't check the return value of the _WAK method. That _SOD method could be causing some trouble, but it's hard to say without seeing the DSDT. Could you post a link to it?

Also, which kernel are you using? There were a lot of issues with the battery in 2.6.1. A lot of people started seeing all zeroes for the capacity information. I think they may have fixed it in 2.6.2 (or in one of the 2.6.2 mm kernels). If you're using 2.6.1, you may want to try 2.6.0. and/or 2.6.2 to see if you get the battery info back.

As far as sleep states are concerned, they are still a work in progress. People seem to be having the most success with swsusp, but even that has some issues.
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Mon Feb 09, 2004 2:12 pm

theonlymcc wrote:Anyone with a Dell i5150 w/ 2.6 kernel got ACPI working? Fixed all my DSDT warnings but changed nothing.
What isn't working? Could you post your dmesg?
Top
tkoster
n00b
n00b
Posts: 46
Joined: Mon May 26, 2003 2:30 am

  • Quote

Post by tkoster » Mon Feb 09, 2004 8:44 pm

The kernel is 2.4.25-pre7. (gs-sources) I don't have a webpage to post the file and it is quite a few lines to include here. Is there a particular section you would like to see?
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Mon Feb 09, 2004 8:57 pm

It's most helpful to see the whole thing. You could send it to me in a PM if you like. I can post it somewhere for more general access at that point.

I don't really know much about gs-sources. Have you tried it with a vanilla 2.4.24? Could be worth a shot.
Top
tkoster
n00b
n00b
Posts: 46
Joined: Mon May 26, 2003 2:30 am

  • Quote

Post by tkoster » Mon Feb 09, 2004 11:48 pm

I tried gentoo-sources first, but it wasn't a high enough edition of the kernel to handle the ndiswrapper for my wireless. So I tried gs-sources after that. I chose both of them because they are supposed to have the latest patches for ACPI in them already.

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?

Tim
Top
sleek
n00b
n00b
User avatar
Posts: 71
Joined: Thu Jan 09, 2003 5:24 am

  • Quote

Post by sleek » Wed Feb 11, 2004 5:56 am

OK, so I've been having great luck with my battery, thermal zone info, ac state, lid state, suspend-to-disk, etc. The one thing that's bothering me is this.

I use gkrellm2 for monitoring my system. One of the plugins I use is to monitor my battery. It is clearly showing whether my AC adaptor is plugged in and it also increases/decreases my battery power percentage depending on the situation. BUT, the highest that my battery power displays is 85%. I know this battery is fully charged, however, because when I reboot into Windows XP it shows as 100% full.

Is this problem something that I could have fixed when I recompiled my DSDT? Or could this be a problem with how the battery percentage is calculated?

Thanks in advance for any help that can be provided.
Yesterday was the deadline for all complaints
Top
jetblack
Guru
Guru
User avatar
Posts: 340
Joined: Wed Jan 15, 2003 4:38 pm
Location: Evanston, IL, USA

  • Quote

Post by jetblack » Wed Feb 11, 2004 12:54 pm

I'm not sure how gkrellm does this, but it could just be a problem with the way it is calculated. If you check /proc/acpi/battery/BAT0/info, you'll see two "full" capacities. There is a "design capacity" and a "last full capacity". Since the battery will lose charge over time, the last full capacity will often be lower than the design capacity. If the remaining percentage is calculated with respect to the design capacity, then it will never get back to 100%. It should be calculated with respect to the last full capacity. If the ratio of your last full capacity to your design capacity is 85%, then that's probably what you're seeing.
Top
Post Reply

394 posts
  • Page 3 of 16
    • Jump to page:
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • …
  • 16
  • Next

Return to “Documentation, Tips & Tricks”

Jump to
  • Assistance
  • ↳   News & Announcements
  • ↳   Frequently Asked Questions
  • ↳   Installing Gentoo
  • ↳   Multimedia
  • ↳   Desktop Environments
  • ↳   Networking & Security
  • ↳   Kernel & Hardware
  • ↳   Portage & Programming
  • ↳   Gamers & Players
  • ↳   Other Things Gentoo
  • ↳   Unsupported Software
  • Discussion & Documentation
  • ↳   Documentation, Tips & Tricks
  • ↳   Gentoo Chat
  • ↳   Gentoo Forums Feedback
  • ↳   Duplicate Threads
  • International Gentoo Users
  • ↳   中文 (Chinese)
  • ↳   Dutch
  • ↳   Finnish
  • ↳   French
  • ↳   Deutsches Forum (German)
  • ↳   Diskussionsforum
  • ↳   Deutsche Dokumentation
  • ↳   Greek
  • ↳   Forum italiano (Italian)
  • ↳   Forum di discussione italiano
  • ↳   Risorse italiane (documentazione e tools)
  • ↳   Polskie forum (Polish)
  • ↳   Instalacja i sprzęt
  • ↳   Polish OTW
  • ↳   Portuguese
  • ↳   Documentação, Ferramentas e Dicas
  • ↳   Russian
  • ↳   Scandinavian
  • ↳   Spanish
  • ↳   Other Languages
  • Architectures & Platforms
  • ↳   Gentoo on ARM
  • ↳   Gentoo on PPC
  • ↳   Gentoo on Sparc
  • ↳   Gentoo on Alternative Architectures
  • ↳   Gentoo on AMD64
  • ↳   Gentoo for Mac OS X (Portage for Mac OS X)
  • Board index
  • All times are UTC
  • Delete cookies

© 2001–2026 Gentoo Foundation, Inc.

Powered by phpBB® Forum Software © phpBB Limited

Privacy Policy

 

 

magic