Skip to contentSkip to conversation

ACPI/ECDT on gateway 200x notebook

DISCUSSION Rich Ibbotson 4 participants 9 messages Jan 4, 2004 – Jan 7, 2004 7 messages not in the archive ACPI

lore
Share & tools
lore

Rich Ibbotson

author
#0 lore raw

Dear ACPI Gurus,

I'm trying to get ACPI working on a Gateway 200X (200ARC) notebook running Linux with kernel 2.4.23 (built from sources). The specs for this notebook claim that it has APM 1.2 and ACPI 2.0 support. However, when I run a kernel with ACPI enabled (as a module) the /proc/acpi/battery and /proc/acpi/ac_adapter directories are both empty and I see these messages at boot time:

kernel: ACPI-1120: *** Error: Method execution failed
[\_SB_.ADP1._STA] (Node c12f88c0), AE_AML_NO_RETURN_VALUE
kernel: ACPI-1120: *** Error: Method execution failed
[\_SB_.BAT1._STA] (Node c12f89c0), AE_AML_NO_RETURN_VALUE

I see that this has been discussed here before, and it looks like the consensus is that I need to manually install an ECDT at boot time.

The latest discussions of this problem that I've seen are here:
http://sourceforge.net/mailarchive/forum.php?thread_id=3451648&forum_id=6102
http://sourceforge.net/mailarchive/forum.php?thread_id=3479606&forum_id=6102

After reading those threads, I've tried two things to get ACPI working:

1) Patch the latest 2.4.23 kernel sources with acpi-20031203-2.4.23.diff and the "fake_ecdt" patch from Ducrot Bruno, passing the string "ecdt_fake=0x66:0x62:28:1:\\_SB_.PCI0.LPCB.H_EC" to the kernel at boot time (my _GPE is 0x1c and the _UID reported by acpidmp under Device H_EC is 0x01)

I see that the fake ecdt does not work, but I am not sure why. I see nothing between the following two logs:

kernel: ACPI: Faking ECDT
kernel: ACPI: Could not use ECDT

If I specify the path as "\_SB_.PCI0.LPCB.H_EC" (only one "\") in my grub.conf, I see the following:

kernel: ACPI: Faking ECDT
kernel: evregion-0347: *** Error: Handler for [EmbeddedControl]
returned AE_BAD_PARAMETER
kernel: dswexec-0435 [11] ds_exec_end_op : [Store]: Could not
resolve operands, AE_BAD_PARAMETER
kernel: psparse-1120: *** Error: Method execution failed
[\_SB_.PCI0.LPCB.H_EC._REG] (Node c13f6c68), AE_BAD_PARAMETER
kernel: ACPI: Could not use ECDT

I do see an entry for "\_SB_.PCI0.LPCB.H_EC._REG" in the DSDT, though:

000028c5: Method _REG (\_SB_.PCI0.LPCB.H_EC._REG)
000028cb: ArgCount 2; NotSerialized
000028cc: If
000028ce: LAnd
000028cf: LEqual
000028d0: Arg0
000028d1: 0x03
000028d3: LEqual
000028d4: Arg1
000028d5: 0x01
000028d7: Store
000028d8: 0x01
000028da: ECON (0000024e)
000028de: Store
000028df: \_SB_.PCI0.LPCB.H_EC.ACEX (00002844)
000028f6: \PWRS (00000160)

I'm not sure if this means that it got a little further, or if this is an error because I should have used both backslashes.

2) I would like to try actually supplying an ECDT, using the information below (I got much of this from the DSDT, but I'm not sure if the Creator ID/Creator Revision matter). Is there a suggested way to put this into a char[] or some form that can be used in acpi_os_table_override? If I can get it into a char[] then I guess I can calculate the checksum and length, but if not then how do I compute these?

ECDT: Length=?, Revision=1, Checksum=?,

         OEMID=INTEL, OEM Table ID=MONTARAG, OEM Revision=0x06040000,
         Creator ID=fake, Creator Revision=0x1
         EC_CONTROL=0x66:0[8] (IO)
         EC_DATA=0x62:0[8] (IO)
         UID=1, GPE_BIT=0x1c
         EC_ID=\_SB_.PCI0.LPCB.H_EC

thanks for any advice,
Rich

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

I think its now been determined that the problem is not from a missing ECDT. Check out the bugzilla entry where work is being done to solve this problem. I'm hoping to test the patch on one of our 400VTX's this week.

http://bugzilla.kernel.org/show_bug.cgi?id=1744

-casey

Quoted 92 lines · Rich Ibbotson

Dear ACPI Gurus,

I'm trying to get ACPI working on a Gateway 200X (200ARC) notebook running Linux with kernel 2.4.23 (built from sources). The specs for this notebook claim that it has APM 1.2 and ACPI 2.0 support. However, when I run a kernel with ACPI enabled (as a module) the /proc/acpi/battery and /proc/acpi/ac_adapter directories are both empty and I see these messages at boot time:

kernel: ACPI-1120: *** Error: Method execution failed
[\_SB_.ADP1._STA] (Node c12f88c0), AE_AML_NO_RETURN_VALUE
kernel: ACPI-1120: *** Error: Method execution failed
[\_SB_.BAT1._STA] (Node c12f89c0), AE_AML_NO_RETURN_VALUE

I see that this has been discussed here before, and it looks like the consensus is that I need to manually install an ECDT at boot time.

The latest discussions of this problem that I've seen are here:
http://sourceforge.net/mailarchive/forum.php?thread_id=3451648&forum_id=6102
http://sourceforge.net/mailarchive/forum.php?thread_id=3479606&forum_id=6102

After reading those threads, I've tried two things to get ACPI working:

1) Patch the latest 2.4.23 kernel sources with acpi-20031203-2.4.23.diff and the "fake_ecdt" patch from Ducrot Bruno, passing the string "ecdt_fake=0x66:0x62:28:1:\\_SB_.PCI0.LPCB.H_EC" to the kernel at boot time (my _GPE is 0x1c and the _UID reported by acpidmp under Device H_EC is 0x01)

I see that the fake ecdt does not work, but I am not sure why. I see nothing between the following two logs:

kernel: ACPI: Faking ECDT
kernel: ACPI: Could not use ECDT

If I specify the path as "\_SB_.PCI0.LPCB.H_EC" (only one "\") in my grub.conf, I see the following:

kernel: ACPI: Faking ECDT
kernel: evregion-0347: *** Error: Handler for [EmbeddedControl]
returned AE_BAD_PARAMETER
kernel: dswexec-0435 [11] ds_exec_end_op : [Store]: Could not
resolve operands, AE_BAD_PARAMETER
kernel: psparse-1120: *** Error: Method execution failed
[\_SB_.PCI0.LPCB.H_EC._REG] (Node c13f6c68), AE_BAD_PARAMETER
kernel: ACPI: Could not use ECDT

I do see an entry for "\_SB_.PCI0.LPCB.H_EC._REG" in the DSDT, though:

000028c5: Method _REG (\_SB_.PCI0.LPCB.H_EC._REG)
000028cb: ArgCount 2; NotSerialized
000028cc: If
000028ce: LAnd
000028cf: LEqual
000028d0: Arg0
000028d1: 0x03
000028d3: LEqual
000028d4: Arg1
000028d5: 0x01
000028d7: Store
000028d8: 0x01
000028da: ECON (0000024e)
000028de: Store
000028df: \_SB_.PCI0.LPCB.H_EC.ACEX (00002844)
000028f6: \PWRS (00000160)

I'm not sure if this means that it got a little further, or if this is an error because I should have used both backslashes.

2) I would like to try actually supplying an ECDT, using the information below (I got much of this from the DSDT, but I'm not sure if the Creator ID/Creator Revision matter). Is there a suggested way to put this into a char[] or some form that can be used in acpi_os_table_override? If I can get it into a char[] then I guess I can calculate the checksum and length, but if not then how do I compute these?

    ECDT: Length=?, Revision=1, Checksum=?,
          OEMID=INTEL, OEM Table ID=MONTARAG, OEM Revision=0x06040000,
          Creator ID=fake, Creator Revision=0x1
          EC_CONTROL=0x66:0[8] (IO)
          EC_DATA=0x62:0[8] (IO)
          UID=1, GPE_BIT=0x1c
          EC_ID=\_SB_.PCI0.LPCB.H_EC

thanks for any advice,
Rich

Quoted 10 lines

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Acpi-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44.0401032005180.7785-100000-j0XSImJ06nG869pVMd/[email protected]

#4 lore raw
Quoted 6 lines · Casey Harkins

I think its now been determined that the problem is not from a missing ECDT. Check out the bugzilla entry where work is being done to solve this problem. I'm hoping to test the patch on one of our 400VTX's this week.

http://bugzilla.kernel.org/show_bug.cgi?id=1744

The patch initiazile EC(s) as the really first device(s) (but I am perhaps wrong, since I read it really quickly though), which break acpi "spirit" imnsho. The EC is a child of other devices and you have to be sure that those devices are initialized before EC (even though that is done by BIOS at POST already, due to legacy access in some laptops).

Quoted 3 lines · Rich Ibbotson
Quoted 2 lines

Dear ACPI Gurus,

[...]

Quoted 11 lines
Quoted 11 lines

I do see an entry for "\_SB_.PCI0.LPCB.H_EC._REG" in the DSDT, though:

000028c5: Method _REG (\_SB_.PCI0.LPCB.H_EC._REG)
000028cb: ArgCount 2; NotSerialized
000028cc: If
000028ce: LAnd
000028cf: LEqual
000028d0: Arg0
000028d1: 0x03
000028d3: LEqual
000028d4: Arg1

Quoted 8 lines
Quoted 8 lines

000028d5: 0x01
000028d7: Store
000028d8: 0x01
000028da: ECON (0000024e)
000028de: Store
000028df: \_SB_.PCI0.LPCB.H_EC.ACEX (00002844)
000028f6: \PWRS (00000160)

Please do not use acpidmp, but iasl instead, or send a raw dsdt.

Look at http://acpi.sf.net/ for how to get iasl.

Cheers,

Signature · 11 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#6 lore raw

Thanks for the reply. I've attached the disassembled dsdt from
"iasl -d dsdt.dat". I notice that the iasl output has "\_SB.PCI0" whereas the acpidmp output has "\_SB_.PCI0". I'll try that with your fake_ecdt patch.

I do see an error and two warnings when I let iasl compile the dsdt:

Compiling "dsdt.dsl"
dsdt.dsl 163: Method (_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_WAK)

dsdt.dsl 2620: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access

dsdt.dsl 2666: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0)

thanks,
Rich

Quoted 52 lines · Ducrot Bruno
Quoted 5 lines · Casey Harkins

I think its now been determined that the problem is not from a missing ECDT. Check out the bugzilla entry where work is being done to solve this problem. I'm hoping to test the patch on one of our 400VTX's this week.

http://bugzilla.kernel.org/show_bug.cgi?id=1744

The patch initiazile EC(s) as the really first device(s) (but I am perhaps wrong, since I read it really quickly though), which break acpi "spirit" imnsho. The EC is a child of other devices and you
have to be sure that those devices are initialized before EC (even
though that is done by BIOS at POST already, due to legacy access
in some laptops).

Quoted 4 lines · Rich Ibbotson
Quoted 3 lines

Dear ACPI Gurus,

[...]

Quoted 11 lines
Quoted 11 lines

I do see an entry for "\_SB_.PCI0.LPCB.H_EC._REG" in the DSDT, though:

000028c5: Method _REG (\_SB_.PCI0.LPCB.H_EC._REG)
000028cb: ArgCount 2; NotSerialized
000028cc: If
000028ce: LAnd
000028cf: LEqual
000028d0: Arg0
000028d1: 0x03
000028d3: LEqual
000028d4: Arg1

Quoted 8 lines
Quoted 8 lines

000028d5: 0x01
000028d7: Store
000028d8: 0x01
000028da: ECON (0000024e)
000028de: Store
000028df: \_SB_.PCI0.LPCB.H_EC.ACEX (00002844)
000028f6: \PWRS (00000160)

Please do not use acpidmp, but iasl instead, or send a raw dsdt.

Look at http://acpi.sf.net/ for how to get iasl.

Cheers,

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 7 lines · Rich Ibbotson

Thanks for the reply. I've attached the disassembled dsdt from "iasl -d dsdt.dat". I notice that the iasl output has "\_SB.PCI0" whereas the acpidmp output has "\_SB_.PCI0". I'll try that with your fake_ecdt patch.

I do see an error and two warnings when I let iasl compile the dsdt:

...

Quoted 3 lines

dsdt.dsl 2620: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region
requires ByteAcc access

The problem you encounter is here. You have to update your dsdt by replacing that DWordAcc by ByteAcc. You can see something for doing that via http://www.poupinou.org/acpi/.

Signature · 11 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw

Ducrot,

Thanks for the help. I have updated the DSDT as you suggested and applied the patch to load it. I had to make a small change to the patch to get it to compile with 2.4.23. I changed the #include from this:

	#include "dsdt_table.h"

to this:

#include <acpi/dsdt_table.h>

Once I did that, everything worked like a charm. Using kernel 2.4.23, the latest acpi patch from acpi.sourceforge.net, this DSDT override patch and the fixed DSDT, I am back to the point where I was when I had just applied the bit_width patch. However, the behavior is now improved, because the lid now correctly reports its state. Before, when I was only using the bit_width patch, I had a lid button, and it generated events, but it always reported its state as "closed".

I haven't yet applied Lumings EmbeddedControl patch to see if the battery info improves. I'll do that now and report what I find.

I have attached the updated patch and my "fixed" DSDT. It is still giving the two warnings, but at least the Error is gone.

Thanks,
Greg

Quoted 11 lines · On Wed, 7 Jan 2004 11:49:41 +0100 Ducrot Bruno…
Quoted 7 lines · Rich Ibbotson

Thanks for the reply. I've attached the disassembled dsdt from "iasl -d dsdt.dat". I notice that the iasl output has "\_SB.PCI0" whereas the acpidmp output has "\_SB_.PCI0". I'll try that with your fake_ecdt patch.

I do see an error and two warnings when I let iasl compile the dsdt:

...

Quoted 25 lines
Quoted 3 lines

dsdt.dsl 2620: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region
requires ByteAcc access

The problem you encounter is here. You have to update your dsdt by replacing that DWordAcc by ByteAcc. You can see something for doing that via http://www.poupinou.org/acpi/.

Signature · 15 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Acpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel
drivers/acpi/osl.c +3 -1
@@ -25,6 +25,7 @@
  *
  */
 
+#include <acpi/dsdt_table.h>
 #include <linux/config.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>

@@ -208,7 +209,8 @@
 	if (!existing_table || !new_table)
 		return AE_BAD_PARAMETER;
 
-	*new_table = NULL;
+	*new_table = (strncmp(existing_table->signature, DSDT_SIG, 4)) ? NULL \
+			: (struct acpi_table_header *) AmlCode;
 	return AE_OK;
 }

A message that is not in the archive (sent off-list or not yet received): 20040107114742.1f2de5b1.greg-QNIYhHqVzB9kr2E5YSwMOQ@public.gmane.org

#12 lore raw
Quoted 4 lines · Greg Sarjeant

Ducrot,

Thanks for the help. I have updated the DSDT as you suggested and applied the patch to load it. I had to make a small change to the patch to get it to compile with 2.4.23. I changed the #include from this:

Quoted 8 lines
	#include "dsdt_table.h"

to this:

	#include <acpi/dsdt_table.h>

    Once I did that, everything worked like a charm. Using kernel 2.4.23, the latest acpi patch from acpi.sourceforge.net, this DSDT override patch and the fixed DSDT, I am back to the point where I was when I had just applied the bit_width patch. However, the behavior is now improved, because the lid now correctly reports its state. Before, when I was only using the bit_width patch, I had a lid button, and it generated events, but it always reported its state as "closed".

Interresting. I had to add a patch made by another guy (Shaohua Li IIRC), and I guess that part give you correct events.
So it's not my fault if your lid work now, sorry :)

Signature · 11 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#14 lore raw

Ah, I see. Well, thanks all around then :)

Quoted 9 lines · On Wed, 7 Jan 2004 18:17:08 +0100 Ducrot Bruno…
Quoted 8 lines · Greg Sarjeant

Ducrot,

Thanks for the help. I have updated the DSDT as you suggested and applied the patch to load it. I had to make a small change to the patch to get it to compile with 2.4.23. I changed the #include from this:

	#include "dsdt_table.h"

to this:

Quoted 26 lines
Quoted 4 lines
	#include <acpi/dsdt_table.h>

    Once I did that, everything worked like a charm. Using kernel 2.4.23, the latest acpi patch from acpi.sourceforge.net, this DSDT override patch and the fixed DSDT, I am back to the point where I was when I had just applied the bit_width patch. However, the behavior is now improved, because the lid now correctly reports its state. Before, when I was only using the bit_width patch, I had a lid button, and it generated events, but it always reported its state as "closed".

Interresting. I had to add a patch made by another guy (Shaohua Li IIRC), and I guess that part give you correct events.
So it's not my fault if your lid work now, sorry :)

Signature · 15 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Acpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

#15 lore raw
In reply to a message not in the archive

Hi Ducrot,

I've got an email that is pending moderator approval because I misbehaved and attached too many things to it, so this may seem slightly out of context. However, I applied the following patches to a 2.4.23 kernel:

latest ACPI patch from acpi.sourceforge.net
DSDT override patch from www.poupinou.org/acpi (slightly modified) Luming's Embedded Control patch from bugzilla.kernel.org (bug 1744)

Now everything works! The battery gives me state info and charging/discharging rate. The lid correctly reports its state. It all looks hunky-dory.

I had attached the updated patch and my fixed DSDT to my prior email, which is why it is getting hung up. I'll go ahead and attach them to bug 1744, and update with these results, too. Thanks!

Greg

Quoted 11 lines · On Wed, 7 Jan 2004 11:49:41 +0100 Ducrot Bruno…
Quoted 7 lines · Rich Ibbotson

Thanks for the reply. I've attached the disassembled dsdt from "iasl -d dsdt.dat". I notice that the iasl output has "\_SB.PCI0" whereas the acpidmp output has "\_SB_.PCI0". I'll try that with your fake_ecdt patch.

I do see an error and two warnings when I let iasl compile the dsdt:

...

Quoted 25 lines
Quoted 3 lines

dsdt.dsl 2620: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region
requires ByteAcc access

The problem you encounter is here. You have to update your dsdt by replacing that DWordAcc by ByteAcc. You can see something for doing that via http://www.poupinou.org/acpi/.

Signature · 15 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Acpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html