public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* ACPI/ECDT on gateway 200x notebook
@ 2004-01-04  2:01 Rich Ibbotson
       [not found] ` <3FF773E5.5070102-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Rich Ibbotson @ 2004-01-04  2:01 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

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

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: ACPI/ECDT on gateway 200x notebook
@ 2004-01-07  1:04 Li, Shaohua
       [not found] ` <571ACEFD467F7749BC50E0A98C17CDD8E84E7B-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Li, Shaohua @ 2004-01-07  1:04 UTC (permalink / raw)
  To: Ducrot Bruno; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Yes, the patch may resolve some problems, but it is just a workaround. I guess a possible solution is if ECDT is lacked, scan namespace to get EC device's info, such as GPE, IO ports, then use these info to automatically make a fake ECDT. Because getting info doesn't involve any operating on EC device, it's feasible. A problem is if a system has more than 1 EC, how do we?

Thanks,
Shaohua


> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Ducrot Bruno
> Sent: 2004年1月7日 2:34
> To: Casey Harkins
> Cc: Rich Ibbotson; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] ACPI/ECDT on gateway 200x notebook
> 
> On Sat, Jan 03, 2004 at 08:07:26PM -0600, Casey Harkins wrote:
> >
> > 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).
> 
> > On Sat, 3 Jan 2004, Rich Ibbotson wrote:
> > > Dear ACPI Gurus,
> > >
> 
> [...]
> 
> > > 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)
> > >
> 
> 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,
> 
> --
> 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
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> 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\x1278&alloc_id371&op=click

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: ACPI/ECDT on gateway 200x notebook
@ 2004-01-07 11:57 Yu, Luming
       [not found] ` <3ACA40606221794F80A5670F0AF15F8401720C89-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Yu, Luming @ 2004-01-07 11:57 UTC (permalink / raw)
  To: Ducrot Bruno, Casey Harkins
  Cc: Rich Ibbotson, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

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

One point is that my patch don't want to fully initialize EC devices.
It just want to get EC resource to init EC addresspace handler ,
Although the patch looks ugly.

The motivation is just to have EC address space 
handler ready for devices that get initialized before EC devices on
laptop without ECDT.   If this attempt is failed due to what you
said,  then ECDT is necessary.

At least, it seems to work for gateway laptop. Of cause, it need to be
refined.








-------------------------------------------------------
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\x1278&alloc_id371&op=click

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: ACPI/ECDT on gateway 200x notebook
@ 2004-01-12  5:39 Yu, Luming
  0 siblings, 0 replies; 17+ messages in thread
From: Yu, Luming @ 2004-01-12  5:39 UTC (permalink / raw)
  To: Ducrot Bruno; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

> 1- your approach,
That patch need more work to make it more generic and cleaner.

>2- make a kind of setup option, like the patch I send some time ago, in
>   order to fake an ECDT, but simplified (the IO ports should be
>   the only options).  But that require another boot option.

There are two problems:
1.  How to get the IO ports?
2.  How to handle cases, in which there are more than 1 EC, and they
have different IO ports?

>3- an error runtime handler, which initialize the address space handler
for
>   the EC if not already done, and then retry.

This sounds like a good idea , and could be a generic mechanism for
solving this kind of problem.



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

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: ACPI/ECDT on gateway 200x notebook
@ 2004-01-14  2:23 Yu, Luming
       [not found] ` <3ACA40606221794F80A5670F0AF15F8401720CCA-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Yu, Luming @ 2004-01-14  2:23 UTC (permalink / raw)
  To: Greg Sarjeant, Ducrot Bruno
  Cc: Li, Shaohua, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Greg,

Thanks for your information. I think It's important to append your
conclusion to 
bug 1744.  To any new issue, you can just file a new one, But it should
be
Linux ACPI bug.

Thanks,
Luming

> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> Greg Sarjeant
> Sent: Tuesday, January 13, 2004 11:27 PM
> To: Ducrot Bruno
> Cc: Li, Shaohua; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] ACPI/ECDT on gateway 200x notebook
> 
> 
> Hi,
> 
>    I just wanted to send along an update on this, rather than 
> continue to clutter bug 1744 with potentially unrelated issues.
> 
>    First off, the AE_BAD_PARAMETER issue is defiintely caused 
> by the DWordAcc in the _GPE method. Using the bit_width patch 
> from bug 1744 masks this error. Overriding the DSDT with the 
> new Gateway 200X DSDT on acpi.sourceforge.net fixes it. Both 
> of these options restore fan, thermal and button 
> functionality. The lid is not fully supported with the 
> bit_width patch, but the fixed DSDT restores the lid fully. 
> The adapter and battery are still missing after applying 
> either solution. This is apparently because of the missing ECDT.
> 
>    To fix the ECDT problem, I have now tried both this patch 
> and the fake_ecdt patch that can be found somewhere in this 
> thread: http://sourceforge.net/mailarchive/message.php?msg_id=6514510
> 
>    I have used them with kernel 2.4.23 and 2.4.24. As far as 
> I know, neither will apply to 2.6.x. Both patches restore the 
> ac adapter and the battery, which is terrific. The parameter 
> to pass to the kernel for the fake_ecdt patch is:
> 
>    ecdt_fake=0x66:0x62:0x1c:0x01:\_SB_.PCI0.LPCB.H_EC
> 
>    There are two differences between the approaches. The 
> fake_ecdt patch yields a single H_EC subdirectory under 
> /proc/acpi/embedded_controller, while the bugzilla patch 
> gives me two. However, using the fake_ecdt patch gives me an 
> error in dmesg which is not present with the other patch. The 
> relevant section is:
> 
> ACPI: Faking ECDT
> schedule_task(): keventd has not started
> evregion-0249 [21] ev_address_space_dispa: no handler for 
> region(df6d0188) [SystemMemory]
>  exfldio-0282 [20] ex_access_region      : Region 
> SystemMemory(0) has no handler
>  psparse-1120: *** Error: Method execution failed 
> [\_SB_.PCI0.LPCB.H_EC._REG] (Node c15dfae8), AE_NOT_EXIST
> ACPI: Could not use ECDT
> 
> 
>    Note that it says that it couldn't use the ECDT, but I do 
> have my battery and adapter info, so I think it is. I'm not 
> exactly sure what this error means, or if it is anything to 
> be concerned about, since I dont see it with the other patch. 
> Any ideas?
> 
>    Also, please let me know if I should append this to bug 
> 1744. I think that we already have two unrelated problems 
> being covered there (buggy DSDT and missing ECDT), and I 
> didn't want to introduce a third ;)
> 
>    Thanks,
>     Greg
> 
> 
> 
> On Wed, 7 Jan 2004 11:54:24 +0100
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> 
> > On Wed, Jan 07, 2004 at 09:04:25AM +0800, Li, Shaohua wrote:
> > > Yes, the patch may resolve some problems, but it is just 
> a workaround. I guess a possible solution is if ECDT is 
> lacked, scan namespace to get EC device's info, such as GPE, 
> IO ports, then use these info to automatically make a fake 
> ECDT. Because getting info doesn't involve any operating on 
> EC device, it's feasible. A problem is if a system has more 
> than 1 EC, how do we?
> > > 
> > 
> > Yes, exactly.  Anyway, io ports 0x62, 0x66 are the legacy access
> > for the "main" EC.  Perhaps checking those ports and initilializing
> > that one only may be OK?
> > 
> > -- 
> > 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

^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-01-30 17:13 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-04  2:01 ACPI/ECDT on gateway 200x notebook Rich Ibbotson
     [not found] ` <3FF773E5.5070102-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org>
2004-01-04  2:07   ` Casey Harkins
     [not found]     ` <Pine.LNX.4.44.0401032005180.7785-100000-j0XSImJ06nG869pVMd/zofZ8FUJU4vz8@public.gmane.org>
2004-01-06 18:34       ` Ducrot Bruno
     [not found]         ` <20040106183426.GJ14031-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2004-01-07  0:39           ` Rich Ibbotson
     [not found]             ` <3FFB552F.8030508-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org>
2004-01-07 10:49               ` Ducrot Bruno
     [not found]                 ` <20040107104941.GL14031-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2004-01-07 16:47                   ` Greg Sarjeant
     [not found]                     ` <20040107114742.1f2de5b1.greg-QNIYhHqVzB9kr2E5YSwMOQ@public.gmane.org>
2004-01-07 17:17                       ` Ducrot Bruno
     [not found]                         ` <20040107171708.GQ14031-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2004-01-07 17:21                           ` Greg Sarjeant
2004-01-07 17:12                   ` Greg Sarjeant
  -- strict thread matches above, loose matches on Subject: below --
2004-01-07  1:04 Li, Shaohua
     [not found] ` <571ACEFD467F7749BC50E0A98C17CDD8E84E7B-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-01-07 10:54   ` Ducrot Bruno
     [not found]     ` <20040107105424.GM14031-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2004-01-13 15:26       ` Greg Sarjeant
2004-01-07 11:57 Yu, Luming
     [not found] ` <3ACA40606221794F80A5670F0AF15F8401720C89-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-01-07 12:40   ` Ducrot Bruno
2004-01-12  5:39 Yu, Luming
2004-01-14  2:23 Yu, Luming
     [not found] ` <3ACA40606221794F80A5670F0AF15F8401720CCA-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-01-30 17:13   ` William Morgan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox