View previous topic :: View next topic |
Author |
Message |
Kesereti Guru
Joined: 07 Nov 2002 Posts: 520
|
Posted: Wed Jan 14, 2004 5:20 am Post subject: |
|
|
Moled wrote: | dmesg wrote: | ACPI: RSDP (v000 GBT ) @ 0x000f6d20
ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
ACPI: MADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7080
ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 |
now would that be what I think it is? :/
Yup...that is what you think it is...I have something similar in mine...in fact, Microsoft's shoddy AML compiler is the reason for many of the ACPI problems in Linux, because it allows manufacturers to produce hardware that behaves fine under MS's compiler, but not at all under Intel(who made the ACPI standard)'s compiler, iasl =\
ill sort it myself when I get back, I might learn something in the process |
|
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Wed Jan 14, 2004 2:23 pm Post subject: |
|
|
Thanks, Kesereti.
I have added this information about the Microsoft ASL compiler to the main doc, because I think it clarifies the description of the problem. I hope you don't mind (let me know if you do, and I'll remove it and just point to this post - you, too, Moled).
I also added some links to and information about the DSDT repository at acpi.sourceforge.net. I can't believe I left that out. If you have a buggy DSDT, check there before you start fixing it - there may already be a fixed one available for your machine.
Now the question is, will a day go by where I don't revise this thing? I swear I don't have OCD.
What? Stop looking at me like that. |
|
Back to top |
|
|
micmac l33t
Joined: 28 Nov 2003 Posts: 996
|
Posted: Thu Jan 15, 2004 5:48 pm Post subject: |
|
|
@ jetblack: Thanks for pointing me to this thread, your HowTo, and for offering your help. I'm the guy with the broken Compaq Armada E500 dsdt. With the help of your HowTo and the provided links I was able to eliminate most of the errors and warnings. Three of one kind still remain and I'm hoping that maybe these can be fixed also.
Here is what iasl says:
Code: |
micmobil iasl-linux-20030918 # ./iasl -tc dsdt.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030918 [Sep 18 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
dsdt.dsl 2163: Store (Package (0x00) {}, Local0)
Warning 2018 - Effective AML package length is zero ^
dsdt.dsl 2200: Store (Package (0x00) {}, Local0)
Warning 2018 - Effective AML package length is zero ^
dsdt.dsl 2237: Store (Package (0x00) {}, Local0)
Warning 2018 - Effective AML package length is zero ^
ASL Input: dsdt.dsl - 5121 lines, 155964 bytes, 2995 keywords
AML Output: DSDT.aml - 22660 bytes 691 named objects 2304 executable opcodes
Compilation complete. 0 Errors, 3 Warnings, 0 Remarks, 1133 Optimizations
micmobil iasl-linux-20030918 #
|
And here are the parts of interest in dsdt.dsl:
Code: |
2159 Method (_PCL, 0, NotSerialized)
2160 {
2161 If (\_SB.C005.C013.C059.C08A ())
2162 {
2163 Store (Package (0x00) {}, Local0)
2164 }
2165 Else
2166 {
2167 Store (Package (0x01)
2168 {
2169 \_SB
2170 }, Local0)
2171 }
2172
2173 Return (Local0)
2174 }
|
Code: |
2196 Method (_PCL, 0, NotSerialized)
2197 {
2198 If (\_SB.C005.C013.C059.C08A ())
2199 {
2200 Store (Package (0x00) {}, Local0)
2201 }
2202 Else
2203 {
2204 Store (Package (0x01)
2205 {
2206 \_SB
2207 }, Local0)
2208 }
2209
2210 Return (Local0)
2211 }
|
Code: |
2233 Method (_PCL, 0, NotSerialized)
2234 {
2235 If (\_SB.C005.C013.C059.C08A ())
2236 {
2237 Store (Package (0x00) {}, Local0)
2238 }
2239 Else
2240 {
2241 Store (Package (0x01)
2242 {
2243 \_SB
2244 }, Local0)
2245 }
2246
2247 Return (Local0)
2248 }
|
Because I don't really have a clue what I'm doing here I'd like to show you what else I've done to get rid of the other errors and warnings. Maybe you can take a look and hopefully tell me that I did all right.
Code: |
dsdt.dsl 32: Name (_HID, "*PNP0A03")
Error 1068 - ^ String must be entirely alphanumeric (*PNP0A03)
|
I got lots of these, so I just removed the '*' from the line:
Code: |
Name (_HID, "*PNP0A03")
|
changed to
Code: |
Name (_HID, "PNP0A03")
|
The next one I got was
Code: |
dsdt.dsl 735: Return (^C08E (Arg0, Arg1, Arg2))
Error 1029 - ^ Called method returns no value
|
I read something about about "Return(Package(0x02){0x00, 0x00})" and thought "Hey, I gotta have one of these"
Code: |
Method (C08E, 3, NotSerialized)
{
Acquire (^C082, 0xFFFF)
Acquire (\_GL, 0xFFFF)
^C08B ()
Store (0x07, C05B)
Store (Arg0, C05C)
Store (Arg1, C05B)
Store (Arg2, C05C)
^C08C ()
Release (\_GL)
Release (^C082)
}
Method (C08F, 2, NotSerialized)
{
Return (^C08D (Arg0, Arg1))
}
Method (C090, 3, NotSerialized)
{
Return (^C08E (Arg0, Arg1, Arg2))
}
|
changed to
Code: |
Method (C08E, 3, NotSerialized)
{
Acquire (^C082, 0xFFFF)
Acquire (\_GL, 0xFFFF)
^C08B ()
Store (0x07, C05B)
Store (Arg0, C05C)
Store (Arg1, C05B)
Store (Arg2, C05C)
^C08C ()
Release (\_GL)
Release (^C082)
Return(Package(0x02){0x00, 0x00})
}
Method (C08F, 2, NotSerialized)
{
Return (^C08D (Arg0, Arg1))
}
Method (C090, 3, NotSerialized)
{
Return (^C08E (Arg0, Arg1, Arg2))
}
|
Last
Code: |
dsdt.dsl 1126: Method (C0B3, 2, Serialized)
Warning 2019 - ^ Not all control paths return a value (C0B3)
|
Again same procedure:
Code: |
Method (C0B3, 2, Serialized)
{
Store (C0B2, Local0)
Not (Local0, Local0)
If (LEqual (Arg0, 0x02))
{
And (Local0, Arg1, Local0)
Return (Local0)
}
Else
{
And (Local0, Not (Arg1), Local0)
If (Arg0)
{
Or (Local0, Arg1, Local0)
}
Store (Local0, C0B2)
}
}
|
changed to
Code: |
Method (C0B3, 2, Serialized)
{
Store (C0B2, Local0)
Not (Local0, Local0)
If (LEqual (Arg0, 0x02))
{
And (Local0, Arg1, Local0)
Return (Local0)
}
Else
{
And (Local0, Not (Arg1), Local0)
If (Arg0)
{
Or (Local0, Arg1, Local0)
}
Store (Local0, C0B2)
}
Return(Package(0x02){0x00, 0x00})
}
|
Are my fixes OK?
Thanks for your time!
mic |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Thu Jan 15, 2004 6:24 pm Post subject: |
|
|
Gald it helped some, micmac. I'm not really a DSDT expert either, but from what I've read while fighting with my laptop, your warning fixes seem ok. The one thing that I would keep in mind is that the return value that the HOWTOs recommend really doesn't do anything, it just returns zero. This is enough to get the warnings to be quiet, but if there is functionality that actually relies on a real return value from those methods, it still won't work. Just something to keep in mind.
However, the one error fix, for the C08E method, concerns me a bit.
Code: | Method (C08E, 3, NotSerialized)
{
Acquire (^C082, 0xFFFF)
Acquire (\_GL, 0xFFFF)
^C08B ()
Store (0x07, C05B)
Store (Arg0, C05C)
Store (Arg1, C05B)
Store (Arg2, C05C)
^C08C ()
Release (\_GL)
Release (^C082)
Return(Package(0x02){0x00, 0x00})
}
Method (C08F, 2, NotSerialized)
{
Return (^C08D (Arg0, Arg1))
}
Method (C090, 3, NotSerialized)
{
Return (^C08E (Arg0, Arg1, Arg2))
}
|
If you check the bottom of this, method C090 actually calls method C08E, and returns its return value. That's why you're getting the "Called method returns no value" error, instead of just the "Not all control paths return a value" warning. So, this seems to be a case where the return value might actually be important. I can't say for sure, because I'm not sure what either of those methods does. I think I'd defer to the acpi-devel mailing list on that one.
The same goes for your remaining warnings. I couldn't find any documentation on that particular warning from googling around. From the package declarations in the methods, they are definitely creating zero-length, empty packages. I'm not sure if that is a big deal, though. You'd only ever actually run into those packages if the "if" condition is fulfilled, and again I'm not really sure whether that would be the case.
I would suggest sending both of these along to the acpi-devel mailing list, and see if anyone there can shed some light. Mention as well that the thing that prompted you to look into this was the fact that your fan is always on.
If you want to test the fixes you have made so far, I would suggest taking the Return fix out of the C08E method first (just in case something is actually looking for it). You seem to have eliminated a lot of errors just by giving the methods valid names. Who knows? Maybe that is enough to help your fan. |
|
Back to top |
|
|
Kesereti Guru
Joined: 07 Nov 2002 Posts: 520
|
Posted: Mon Jan 19, 2004 6:45 pm Post subject: |
|
|
...thought I would drop a line in this topic to note that this patch seems to fix ACPI for machines running the 2.6 kernel series that lack an ECDT in their BIOS (such as Gateway laptops) ... just patch, recompile, reboot, and ACPI functionality is yours! (barring buggy DSDT's, and whatever else =P) |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Sun Jan 25, 2004 6:37 pm Post subject: |
|
|
Added a blurb about the acpi_os_name boot parameter to the beginning of Section 8. You can use this parameter to trick your DSDT into thinking you are running a version of Windows if it enables certain functionality only for that OS. |
|
Back to top |
|
|
wizzzard Tux's lil' helper
Joined: 31 Mar 2003 Posts: 116 Location: Bonn, Germany
|
Posted: Sun Jan 25, 2004 7:17 pm Post subject: |
|
|
a little addition: there is another way to get ACPI thinking you were running windoze, by changing a line in <your kernel>/include/acpi/platform/aclinux.h:
Code: | Line 47:
#define ACPI_OS_NAME "Linux" |
Change this to "Microsoft Windows XP" would have the same effect as adding a line to your kernel boot parameter.
Disadvantage: everytime you compile a new kernel from new sources you will have to change this again
Hmmm, thinking it over, the boot parameter is more time-saving, just wanted to mention the other way.
Edit: If you want to do it the way of editing this file, you might even change "Linux" to something with just 20 chars, don't need to be "Microsoft Windows XP" or something. For example, what about "Runnning Gentoo Linux", fells so much better! |
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Sun Jan 25, 2004 9:55 pm Post subject: |
|
|
Code: |
Maximum error count (200) exceeded.
ASL Input: dsdt.dsl - 5298 lines, 173571 bytes, 1966 keywords
Compilation complete. 201 Errors, 0 Warnings, 0 Remarks, 422 Optimizations
|
wow, this will be fun...
I get lots of error 1022:
Code: |
dsdt.dsl 1949: Store (Arg2, SMD0)
Error 1022 - Object does not exist ^ (SMD0)
|
(new Asus M6800N Laptop)
Code: |
ACPI: RSDP (v000 ACPIAM ) @ 0x000f5da0
ACPI: RSDT (v001 A M I OEMRSDT 0x12000312 MSFT 0x00000097) @ 0x1ff40000
ACPI: FADT (v001 A M I OEMFACP 0x12000312 MSFT 0x00000097) @ 0x1ff40200
ACPI: OEMB (v001 A M I OEMBIOS 0x12000312 MSFT 0x00000097) @ 0x1ff50040
ACPI: DSDT (v001 1ABSP 1ABSP000 0x00000000 MSFT 0x0100000d) @ 0x00000000
|
_________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Mon Jan 26, 2004 12:29 am Post subject: |
|
|
I added a few non-DSDT related ACPI fixes, and I renamed the HOWTO, because it's not really strictly a DSDT HOWTO anymore. |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Mon Jan 26, 2004 5:54 pm Post subject: |
|
|
Instinct82 wrote: | Code: |
Maximum error count (200) exceeded.
ASL Input: dsdt.dsl - 5298 lines, 173571 bytes, 1966 keywords
Compilation complete. 201 Errors, 0 Warnings, 0 Remarks, 422 Optimizations
|
wow, this will be fun...
I get lots of error 1022:
Code: |
dsdt.dsl 1949: Store (Arg2, SMD0)
Error 1022 - Object does not exist ^ (SMD0)
|
(new Asus M6800N Laptop) |
Ugh. That sounds like great fun. It looks like they may not be declaring their variables? Do you have any lines like this:
If not, you may want to try adding them to initialize the variables before the DSDT tries to set them, to see if those errors go away. Of course, if there are over 200, that could get tedious. Hopefully it's a few variables that are being used repeatedly.
Anyhow, it's a guess... |
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Mon Jan 26, 2004 11:28 pm Post subject: |
|
|
If you want to have a look at my files, you can download
dsdt.dsl
dsdt.dat
The one I could correct, was the
Code: | /*** Missing EndDependentFunctions descriptor */ | in line 656
this just has to be replaced by
(pay attention to the at the end of the line, this should not be replaced since it is needed to be syntactically correct
At the beginning of the compilation output there's a line that does not look like all the other error messages:
Code: | nsaccess-0682: *** Warning: NsLookup: Type mismatch on SMBS (RegionField), searching for (Device) |
I don't really know how to interpret that
Then another thing that cought my attention is the Checking for the Operating System:
Code: | Name (OSFG, 0x00)
Name (OS9X, 0x01)
Name (OS98, 0x02)
Name (OSME, 0x04)
Name (OS2K, 0x08)
Name (OSXP, 0x10)
Method (OSVR, 0, NotSerialized)
{
If (CondRefOf (\_OSI, Local0))
{
Store (OSXP, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft Windows"))
{
Store (OS98, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft WindowsME: Millennium Edition"))
{
Store (OSME, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft Windows NT"))
{
Store (OS2K, OSFG)
}
Else
{
Store (OSXP, OSFG)
}
}
}
}
Return (OSFG)
}
|
But this should not be a problem since it defaults to Windows XP - maybe it disables some functions for the older Microsoft OSes _________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Tue Jan 27, 2004 12:05 am Post subject: |
|
|
Instinct82 wrote: | If you want to have a look at my files, you can download
dsdt.dsl
dsdt.dat |
Hm, well this is a bit out of my depth, but it looks like at least that SMD0 variable is declared in your Embedded Controller region, here:
Code: | OperationRegion (ECOR, EmbeddedControl, 0x00, 0x80)
Field (ECOR, ByteAcc, Lock, Preserve)
{
Offset (0x04),
CMD1, 8,
CDT1, 8,
CDT2, 8,
CDT3, 8,
Offset (0x18),
PRTC, 8,
SSTS, 8,
ADDR, 8,
SCMD, 8,
SMD0, 8,
SMD1, 8,
DATB, 240,
BCNT, 8,
ALRM, 8,
ALR0, 8,
ALR1, 8,
Offset (0x43),
P50S, 1,
, 1,
, 1,
P43S, 1,
P54S, 1,
P55S, 1,
Offset (0x48),
P54C, 8,
P55C, 8,
P50C, 8,
P43C, 8,
Offset (0x50),
P60C, 8,
P61C, 8,
P62C, 8,
P63C, 8,
P64C, 8,
P65C, 8,
P66C, 8,
P67C, 8,
P68C, 8,
Offset (0x78),
P60S, 1,
P61S, 1,
P62S, 1,
P63S, 1,
P64S, 1,
P65S, 1,
P66S, 1,
P67S, 1
}
|
My hunch would be that many of those other variables will look familiar from your errors, too. Perhaps they have fallen out of scope by the time the compiler gets to those "Store" statements. I'll have to do a little more reading and investigating to find out. If you'd rather check it out for yourself, the ACPI spec will have the information you want.
Instinct82 wrote: | At the beginning of the compilation output there's a line that does not look like all the other error messages:
Code: | nsaccess-0682: *** Warning: NsLookup: Type mismatch on SMBS (RegionField), searching for (Device) |
I don't really know how to interpret that |
Hm. I'm not exactly sure about that either, but I think that SMBS is the Smart Battery System, which also depends on the Embedded Control.
Could you let me know what exactly isn't working? Does any of the ACPI functionality work on your machine?
Instinct82 wrote: | Then another thing that cought my attention is the Checking for the Operating System:
Code: | Name (OSFG, 0x00)
Name (OS9X, 0x01)
Name (OS98, 0x02)
Name (OSME, 0x04)
Name (OS2K, 0x08)
Name (OSXP, 0x10)
Method (OSVR, 0, NotSerialized)
{
If (CondRefOf (\_OSI, Local0))
{
Store (OSXP, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft Windows"))
{
Store (OS98, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft WindowsME: Millennium Edition"))
{
Store (OSME, OSFG)
}
Else
{
If (MCTH (\_OS, "Microsoft Windows NT"))
{
Store (OS2K, OSFG)
}
Else
{
Store (OSXP, OSFG)
}
}
}
}
Return (OSFG)
}
|
But this should not be a problem since it defaults to Windows XP - maybe it disables some functions for the older Microsoft OSes |
Yeah, it probably does something like that (I didn't check too closely). It's nice that in your case it seems to enable things by default if you're not running a bad version of windows (insert easy joke here ) |
|
Back to top |
|
|
Moled l33t
Joined: 09 Jul 2003 Posts: 635
|
Posted: Tue Jan 27, 2004 1:34 am Post subject: |
|
|
Code: | Method (\_SB.PCI0._INI, 0, NotSerialized)
{
If (STRC (\_OS, "Microsoft Windows"))
{
Store (0x56, SMIP)
}
Else
{
If (STRC (\_OS, "Microsoft Windows NT"))
{
Store (0x58, SMIP)
Store (0x00, OSFL)
}
Else
{
Store (0x57, SMIP)
Store (0x02, OSFL)
}
}
|
got to find out what that means :\ |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Tue Jan 27, 2004 1:38 am Post subject: |
|
|
Hm - look around for things that are testing the value of SMIP and/or OSFL. |
|
Back to top |
|
|
Moled l33t
Joined: 09 Jul 2003 Posts: 635
|
Posted: Tue Jan 27, 2004 2:47 am Post subject: |
|
|
Code: | Method (\_WAK, 1, NotSerialized)
{
Store (0xFF, DBG1)
If (LEqual (Arg0, 0x04))
{
If (LEqual (OSFL, 0x00))
{
Store (0x58, SMIP)
|
etc for each value
looks like what to do when it resumes, work arounds for each os I guess
Code: |
Device (PSMR)
{
Name (_HID, EisaId ("PNP0C02"))
Name (_UID, 0x03)
Method (_STA, 0, NotSerialized)
{
If (LEqual (KBDI, 0x00))
{
Return (0x00)
}
If (LEqual (PS2F, 0x00))
{
If (LEqual (OSFL, 0x02))
{
Return (0x0F)
}
If (LEqual (OSFL, 0x01))
{
Return (0x0F)
}
|
etc
it also poped up with some usb stuff
no idea with that? |
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Tue Jan 27, 2004 11:01 am Post subject: |
|
|
well, someone was faster than me and got the dsdt compiling without errors
http://www.isis.de/members/~messersch/files/asus_m6800n_dsdt_test.dsl.gz
I think some acpi stuff does work since i get those messages at bootup
Code: |
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 4
|
you can also view
all lines of dmesg containing "ACPI"
or
my complete dmesg output _________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Tue Jan 27, 2004 3:02 pm Post subject: |
|
|
Instinct82 wrote: | well, someone was faster than me and got the dsdt compiling without errors |
Ah, well I hope that helps some.
Is that with the original DSDT or with the fixed one from that site?
All of the errors you have in dmesg have ECFL at their root:
Code: | ACPI-0352: *** Error: Looking up [ECFL] in namespace, AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ECAV] (Node c1570cc0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ACS_] (Node c1570ca0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.AC__._INI] (Node c1570a80), AE_NOT_FOUND
ACPI-0352: *** Error: Looking up [ECFL] in namespace, AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ECAV] (Node c1570cc0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.BATS] (Node c1570c80), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node c156e900), AE_NOT_FOUND
...
ACPI-0352: *** Error: Looking up [ECFL] in namespace, AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ECAV] (Node c1570cc0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.BATS] (Node c1570c80), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node c156e900), AE_NOT_FOUND
...
ACPI-0352: *** Error: Looking up [ECFL] in namespace, AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ECAV] (Node c1570cc0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.ACS_] (Node c1570ca0), AE_NOT_FOUND
ACPI-1120: *** Error: Method execution failed [\_SB_.AC__._PSR] (Node c1570aa0), AE_NOT_FOUND
|
They go on to affect AC__ (which I imagine is the AC Adapter) and BAT0 (the first battery). That would make sense, since neither of these is recognized later. Though I'm intrigued, because BAT1 does seem to be recognized. Hrm...
Code: | ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Fan [FN00] (off)
ACPI: Processor [CPU1] (supports C1)
ACPI: Thermal Zone [THRM] (49 C)
|
In your DSDT, the ECFL variable is defined in the Embedded Controller region (the _HID of "PNP0C09" is the identifier for that region).
Code: | Device (EC0)
{
Name (ECFL, Ones)
Mutex (MUEC, 0x00)
Name (FAKE, 0x00)
Method (ECAV, 0, NotSerialized)
{
If (LEqual (ECFL, Ones))
{
If (LNot (LLess (_REV, 0x02)))
{
Return (One)
}
Else
{
Return (Zero)
}
}
Return (ECFL)
}
Name (_HID, EisaId ("PNP0C09"))
...
|
So, it sounds like the drivers aren't yet aware of the Embedded Controller region of your DSDT when they try to initialize your AC adapter and battery. That is consistent with the beahvior that was caused by the missing ECDT on my system. If you haven't already, you may want to try applying this ECDT initialization patch to your kernel. That fixed my ECDT errors. |
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Tue Jan 27, 2004 3:57 pm Post subject: |
|
|
applying the patch did not change anything (compared dmesg output with diff... nothing)
To be sure: I do have to apply the patch
Code: |
cat acpi_patch.diff | patch -p0 -E
|
and then recompile the kernel? which options are important? _________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Tue Jan 27, 2004 4:02 pm Post subject: |
|
|
I always just use "patch -p1".
Code: | patch -p1 < /path/to/acpi_patch.diff |
or
Code: | cat /path/to/acpi_patch.diff | patch -p1 |
|
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Tue Jan 27, 2004 4:19 pm Post subject: |
|
|
well, patch asked me if I wanted to undo the patching
so it must have been applied correctly. any ideas? _________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Tue Jan 27, 2004 5:08 pm Post subject: |
|
|
Hm. At this point, the only ideas I have are:
1. You didn't copy the new kernel to /boot after recompiling
2. You are missing the ECDT, but this patch doesn't fix your ECDT problems
3. I've misdiagnosed it, and it isn't an ECDT problem at all
Of the three, I think #3 is the most likely. I'm still working my way through all this. However, I can say this much:
- BAT0._STA definitely calls BATS, which in turn calls ECAV, which relies on ECFL having been defined.
- AC__._PSR definitely calls ACS, which then calls ECAV, which again relies on ECFL
- ECFL is initialized to Ones at the beginning of the EC0 definition, and gets set to the value of the second parameter passed to the Embedded Control's _REG method if its first argument is 0x03.
A value of 0x03 in the first argument of the _REG method indicates that it is running in the Embedded Controller's operation region. I would think that that should always be the case, but I don't know for sure. The second argument is either 0 or 1. 0 means that the handler is being disconnected, 1 means that it is being connected.
I guess you could fudge this by always returning 1 from ECAV, instead of returning the value of ECFL, just to see if the errors on boot go away. But that would only be useful to diagnose the problem, and may be dangerous. I think that you would want those functions to return the proper value based on the status of the Embedded Control.
Anyhow, the only way that I can see that variable not being found is if the Embedded Control Region hasn't been parsed at the time when those functions are called, which sure sounds like an ECDT issue, but I could be missing something. Sorry I don't have anything more definitive at the moment. I hate to say this, but perhaps you should send an email to acpi-devel@lists.sourceforge.net. Someone there may be able to shed a little more light on the problem. |
|
Back to top |
|
|
Svlad n00b
Joined: 27 Jan 2004 Posts: 4
|
Posted: Tue Jan 27, 2004 7:20 pm Post subject: |
|
|
Hi,
I did the changes to the DSDT table for the M6800N and I just wanted to mention that I'm not sure if the DSDT table correct. To make it compile I had to change some objects that looked ok.
Code: |
OperationRegion (IO, SystemIO, DPRT, 0x05)
Field (IO, ByteAcc, Lock, Preserve)
{
DAT0, 8,
Offset (0x04),
CMD0, 8
}
Field (IO, ByteAcc, Lock, Preserve)
{
Offset (0x04),
OUTS, 1,
INPS, 1
}
|
Here I changed the IO to SMBX (which I saw in a table for an M2400N) and most compilation errors were gone.
Maybe someone with insights can take a look at this part and tell me how to really fix it or at least what might be the problem.
regards
S. |
|
Back to top |
|
|
Instinct82 n00b
Joined: 16 Aug 2003 Posts: 42 Location: Trier, Germany
|
Posted: Wed Jan 28, 2004 1:03 pm Post subject: |
|
|
I mailed a developer of acpi4asus and he told me that my laptop model will be supported in the next version of acpi4asus _________________ my gentoo boxes
Desktop:
AMD Athlon XP 2000+
512MB DDR
GeForce3 Ti200
Samsung SyncMaster 193T
Laptop:
Asus M6800N 1,5GHz
768MB DDR
Radeon 9600 Mobility
Router:
Intel Pentium 90, 128MB RAM, True Headless |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Wed Jan 28, 2004 2:02 pm Post subject: |
|
|
D'oh! Sorry about that - I completely forgot about acpi4asus
Glad to hear that support is coming, though. |
|
Back to top |
|
|
jetblack Guru
Joined: 15 Jan 2003 Posts: 340 Location: Evanston, IL, USA
|
Posted: Wed Jan 28, 2004 2:04 pm Post subject: |
|
|
Moled wrote: | it also poped up with some usb stuff
no idea with that? |
Hm - not sure about that, either. Though, I have seen some emails about problems with USB on suspend/resume. As I recall, if the USB modules are loaded, resumes fail. If they aren't loaded, resume works, but you can't reload the modules. So maybe it's all related to suspend/resume. |
|
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
|
|