| View previous topic :: View next topic |
| Author |
Message |
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
 Posted: Thu Jan 29, 2004 9:59 pm Post subject: |
 |
|
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: | dsdt.dsl 255: Method (_BTP, 1, NotSerialized)
Warning 2019 - ^ Not all control paths return a value (_BTP) |
The code in question is this:
| Code: | 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 |
|
| Back to top |
|
 |
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Thu Jan 29, 2004 10:27 pm Post subject: |
|
|
| 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: | dsdt.dsl 255: Method (_BTP, 1, NotSerialized)
Warning 2019 - ^ Not all control paths return a value (_BTP) |
The code in question is this:
| Code: | 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. |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Fri Jan 30, 2004 12:12 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Fri Jan 30, 2004 12:17 am Post subject: |
|
|
yikes! This is new:
| Code: | 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? |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Fri Jan 30, 2004 12:44 am Post subject: |
|
|
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: | | {"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] |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Fri Jan 30, 2004 2:50 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Fri Jan 30, 2004 2:59 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Fri Jan 30, 2004 6:33 am Post subject: |
|
|
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 
Good luck to everyone else who is still working on their ACPI!!!
_________________
Yesterday was the deadline for all complaints |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Fri Jan 30, 2004 3:57 pm Post subject: |
|
|
How do I make my laptop "sleep"?
_________________
Yesterday was the deadline for all complaints |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Fri Jan 30, 2004 4:12 pm Post subject: |
|
|
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: | | 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:
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! |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Sun Feb 01, 2004 3:51 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Mon Feb 02, 2004 6:10 pm Post subject: |
|
|
| Added a couple of new sections for issues that have come up over the last week or so (acpi4asus, blacklisted BIOSes, etc). |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Mon Feb 02, 2004 6:18 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Mon Feb 02, 2004 6:26 pm Post subject: |
|
|
| 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! |
|
| Back to top |
|
|
tkoster
n00b
Joined: 26 May 2003
Posts: 46
|
| Posted: Mon Feb 09, 2004 5:21 am Post subject: |
|
|
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? |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Mon Feb 09, 2004 5:37 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
theonlymcc
Apprentice
Joined: 16 Sep 2003
Posts: 274
Location: NC
|
| Posted: Mon Feb 09, 2004 9:03 am Post subject: |
|
|
| Anyone with a Dell i5150 w/ 2.6 kernel got ACPI working? Fixed all my DSDT warnings but changed nothing. |
|
| Back to top |
|
|
tkoster
n00b
Joined: 26 May 2003
Posts: 46
|
| Posted: Mon Feb 09, 2004 1:08 pm Post subject: |
|
|
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) |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Mon Feb 09, 2004 2:11 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Mon Feb 09, 2004 2:12 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
tkoster
n00b
Joined: 26 May 2003
Posts: 46
|
| Posted: Mon Feb 09, 2004 8:44 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Mon Feb 09, 2004 8:57 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
tkoster
n00b
Joined: 26 May 2003
Posts: 46
|
| Posted: Mon Feb 09, 2004 11:48 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
sleek
n00b
Joined: 09 Jan 2003
Posts: 71
|
| Posted: Wed Feb 11, 2004 5:56 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
jetblack
Guru
Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA
|
| Posted: Wed Feb 11, 2004 12:54 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
