Bug 1744 - AE_BAD_PARAMETER returned from ec address space handler.
AE_BAD_PARAMETER returned from ec address space handler.
Product: ACPI
Classification: Unclassified
Component: Power-Battery
i386 Linux
: P2 high
Assigned To: Luming Yu
: 2857 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2003-12-24 19:55 UTC by Luming Yu
Modified: 2005-01-26 21:53 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.4 , 2.6
Tree: Mainline
Regression: ---

a proposal patch (570 bytes, patch)
2003-12-24 20:03 UTC, Luming Yu
Details | Diff
dmesg after applying bit width patch (182 bytes, text/html)
2003-12-25 08:27 UTC, Greg Sarjeant
a proposal patch (10.64 KB, patch)
2003-12-29 04:28 UTC, Luming Yu
Details | Diff
Relevant files after applying 12/29/2003 proposal patch (158 bytes, text/html)
2003-12-29 16:29 UTC, Greg Sarjeant
Modified DSDT override patch (495 bytes, text/plain)
2004-01-07 09:23 UTC, Greg Sarjeant
Fixed DSDT for Gateway 200x (130.44 KB, text/plain)
2004-01-07 09:25 UTC, Greg Sarjeant
luming's patch updated for 2.6.9 (1.31 KB, patch)
2004-11-10 21:34 UTC, Len Brown
Details | Diff
enable up-to 32-bit ec bit width. (2.19 KB, patch)
2004-11-23 04:12 UTC, Luming Yu
Details | Diff
an update version against latest acpi tree (1.00 KB, patch)
2004-12-01 05:57 UTC, Luming Yu
Details | Diff

Description Luming Yu 2003-12-24 19:55:14 UTC
Greg Sarjeant [greg@morningdave.org] said:

   I know that this has been covered here before, but I have gotten stuck, so I
was wondering if someone could give me a nudge in the right direction.

   I have a Gateway 200x. Apparently, as discussed here previously
(http://sourceforge.net/mailarchive/message.php?msg_id=6514510), these machines
do not provide an ECDT. I am getting some EmbeddedController errors in dmesg,
and do not have battery, button, thermal or ac adapter support. Obviously, it
would be nice to resolve this :)

   I followed the thread above, and noticed that there is a patch for the 2.4.23
kernel that allows you to supply an ECDT as a boot parameter. Sounds like just
the thing. I have applied the patch and am sending what I believe to be the
correct parameters to the kernel in my grub.conf, but it will not use the faked
ECDT. I imagine that I am just doing something stupid, but I can't figure out
what it is right now. I have tried a number of different ways of specifying
these parameters, but none has worked so far. I've posted some files (DSDT,
dmesg, grub.conf and the version of the patch that I applied) at
http://www.morningdave.org/acpi/. If someone could look them over and let me
know if anything jumps out as obviously wrong, I would really appreciate it.
Right now, I'm hopeful that it is just a subtle difference in the syntax for
lilo.conf and grub.conf that I am not catching. If you need any other
information, please let me know.

   Also, if it wouldn't be too much trouble, could someone let me know how one
determines the command and data ports that are used by the EmbeddedController? I
am using the values that folks seemed to agree on in the previous thread for
this machine (0x66 and 0x62, respectively). But my only real justification is
that they were mentioned in that thread, and I see those values in the DSDT. I
don't really understand how I could have identified them without someone who
knows what he is doing providing them first.


Comment 1 Luming Yu 2003-12-24 20:03:42 UTC
Created attachment 1741 [details]
a proposal patch

Just try it.
Comment 2 Greg Sarjeant 2003-12-25 08:27:37 UTC
Created attachment 1748 [details]
dmesg after applying bit width patch


   Thanks for the rapid reply. It looks like you have identified the problem
correctly. After applying your patch, I am getting the "bit_width must be 8"
warning in dmesg instead of AE_BAD_PARAMETER. Here is the dmesg output:

ACPI: Embedded Controller [H_EC] (gpe 28)
Warning: bit_width must be 8 
schedule_task(): keventd has not started

 - and -

ACPI: Processor [CPU0] (supports C1 C2 C3, 5 performance states, 8 throttling
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Sleep Button (CM) [SLPB]
Warning: bit_width must be 8 
[ACPI Debug] String: Not Support
Warning: bit_width must be 8 
ACPI: Thermal Zone [THRM] (46 C)
ACPI: Fan [FAN0] (on)

Changing from the error to the warning seems to have given me button and
thermal zone support. I haven't played with them yet, but I at least have
entries under /proc/acpi/thermal_zone, where it was empty before. Also, the
entries under /proc/acpi/button/*/state now have meaningful information, where
before they just said "state:unsupported". So, it looks like that has helped.

I still do not have battery or ac adapter support. It looks like I still get
some messages from the EC that may be related. Here is the relevant dmesg
output for those devices:

ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 S4 S5)
evregion-0251 [22] ev_address_space_dispa: No handler for Region [ECR_]
(df5ec688) [EmbeddedControl]
 exfldio-0284 [21] ex_access_region	 : Region EmbeddedControl(3) has no
 dswexec-0435 [14] ds_exec_end_op	 : [LEqual]: Could not resolve
operands, AE_NOT_EXIST
dswstate-0273 [16] ds_result_pop_from_bot: No result objects! State=df5fb428
 dsutils-0525 [16] ds_create_operand	 : Missing or null operand,
 psparse-1120: *** Error: Method execution failed [\_SB_.ADP1._STA] (Node
evregion-0251 [22] ev_address_space_dispa: No handler for Region [ECR_]
(df5ec688) [EmbeddedControl]
 exfldio-0284 [21] ex_access_region	 : Region EmbeddedControl(3) has no
 dswexec-0435 [14] ds_exec_end_op	 : [LEqual]: Could not resolve
operands, AE_NOT_EXACPI: Processor [CPU0] (supports C1 C2 C3, 5 performance
states, 8 throttling states)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Sleep Button (CM) [SLPB]
Warning: bit_width must be 8 
[ACPI Debug] String: Not Support
Warning: bit_width must be 8 
ACPI: Thermal Zone [THRM] (46 C)
ACPI: Fan [FAN0] (on)IST
dswstate-0273 [16] ds_result_pop_from_bot: No result objects! State=df5fb428
 dsutils-0525 [16] ds_create_operand	 : Missing or null operand,
 psparse-1120: *** Error: Method execution failed [\_SB_.BAT1._STA] (Node
ACPI: PCI Root Bridge [PCI0] (00:00)

  I have attached the entire contents of dmesg after applying your patch
(again, to fresh 2.4.23 sources with the latest acpi patch applied) in the url,
in case I have left anything out of the comments that would be of use.

  Thanks again for all your help. This is a great Christmas gift :)

Comment 3 Luming Yu 2003-12-29 04:28:37 UTC
Created attachment 1757 [details]
a proposal patch 

Please try this prototype patch to init EC driver wherever EC device located in
namespace , that could lead to uninstalled ec address space handler.
Comment 4 Greg Sarjeant 2003-12-29 16:29:51 UTC
Created attachment 1767 [details]
Relevant files after applying 12/29/2003 proposal patch


   Thanks again for the quick reply.

   This patch got us closer. I applied it and your previous bit width patch to
the vanilla 2.4.23 kernel sources. Now, I have entries in /proc/acpi for the ac
adapter and the battery. Here is what I have noticed:

1. The AC Adapter responds to being unplugged and plugged in.
2. The battery responds to the AC Adapter being unplugged and plugged in.
3. The battery is aware of when it is charging and discharging, and reports the
rate at which it is discharging.
4. The battery is *not* aware of its current capacity, or its fully charged

    I also noticed the following changes (not related to battery and ac
adapter) from just having the bit width patch applied:

1. The processor now reports performance states. It said that performance
states were unsupported when only the bit width patch was applied. It did
report performance states with the unpatched 2.4.23 sources.
2. I see 2 H_EC directories under /proc/acpi/embedded_controller, which seems
3. /proc/acpi/embedded_controller/H_EC/info seems to be reporting incorrect
ports. They were reported correctly when I only had the bit_width patch

   Finally, I did not mention before that the bit width patch gave me access to
the function keys on the laptop. I could not use them with the vanilla sources.
I still have function key access with this latest patch.

   Thanks again for your help. It looks like the only thing that I am still
missing is the battery capacity information. I have posted my dmesg, embedded
controller info and battery info at the attached url. Please let me know if you
would like any additional information.

Comment 5 Greg Sarjeant 2003-12-31 08:28:10 UTC
A couple more things that I have noticed with this latest patch:

1. The system responds to the battery being removed and inserted
2. The lid status is always reported as "closed" (this was also the case with
the bit width patch). However, the lid button does generate events on open and
3. I can put the system into sleep states 3 and 4 using the sleep button (or
just writing to /proc/acpi/sleep), but I can not wake it up from either.
However, this may just be because I don't really know what I'm doing with sleep
states. I'll keep playing with them to see what I can find out. What's the worst
that could happen? ;)

Also, I tried to apply this patch to the 2.6.0 kernel, but it failed. I imagine
that the bus code is a bit different between the two branches, but haven't
really looked it over yet. The bit width patch worked just fine with 2.4.23 and

Comment 6 Greg Sarjeant 2004-01-03 15:16:34 UTC

   I forgot to include the output of cat /proc/acpi/battery/BAT1/state. I have
added those files to the url in my last attachment (1 each for charging and
discharging). The battery properly reports its state, but is unaware of its
capacity. I have noticed that each time I cat /proc/acpi/battery/BAT1/state and
/proc/acpi/battery/BAT1/info, I get two "warning: bit_width must be 8" messages
in dmesg. Could that be related to my 0 capacity problem? I've been looking
through the _BIF and _BST control methods in the DSDT to see if I can work out
what is going on, but I haven't made much progress there.

Comment 7 Greg Sarjeant 2004-01-06 05:52:08 UTC
Another update:

These patches have now also been successfully applied to a Dell Latitude that
had the same problem. They fixed the problem, and the owner is reporting values
for battery capacity where I have zeroes. So, perhaps my battery capacity issue
is unrelated?
Comment 8 Rich Ibbotson 2004-01-06 19:41:32 UTC
I've applied the same patches to a Gateway 200X with the same results.  Battery
and ac_adapter information becomes available, but battery capacity shows as 0. 
It looks like the bit_width warnings come when a bit_width of 32 is passed to
acpi_ec_space_handler() rather the expected 8.  Should this routine handle a
bit_width of 32 or is that an illegal value?

I'm not sure if this is related or not, but iasl shows errors in the dsdt.  Running 
cat /proc/acpi/dsdt >dsdt.dat; iasl -dc dsdt.dat


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)
Comment 9 Greg Sarjeant 2004-01-06 19:57:57 UTC
Ah, great! I was just starting to play around with iasl after seeing the
acpi-devel thread.

I can't say for sure, but I wouldn't be surprised if that error is the cause of
the trouble. I tried just changing that line to the following:

  Field (ECR, ByteAcc, Lock, Preserve)

iasl then compiled the dsdt with no errors and no warnings. I have no idea
whether or not this would actually work, though. I seem to remember a "how to
override your DSDT" topic over at acpi.sourceforge.net. I'll try to find it in
the morning, and see if I can get it to load the new dsdt.
Comment 10 Greg Sarjeant 2004-01-07 09:17:59 UTC
Using the proposal patch from 12/29/2003 in conjunction with the DSDT override
patch (modified) and a fixed DSDT for this machine restores all of the missing
functionality. That includes:

Buttons (including lid properly reporting its state)
Thermal Zones
AC Adapter
Battery (including capacity, charging/discharging rate)

Thanks to all, especially Luming and Ducrot, for your help. It sounds like you
may be looking to clean up the 12/29 proposal patch. I'll be happy to test any
changes. I'll attach the fixed DSDT and the modified DSDT patch.
Comment 11 Greg Sarjeant 2004-01-07 09:23:47 UTC
Created attachment 1810 [details]
Modified DSDT override patch

This is a minor modification to the DSDT override patch located here:

so that it will compile with kernel 2.4.23
Comment 12 Greg Sarjeant 2004-01-07 09:25:40 UTC
Created attachment 1811 [details]
Fixed DSDT for Gateway 200x

This fixes the DWordAcc error in the EmbeddedControl region of the DSDT for the
Gateway 200x. It does not resolve either of the warnings generated on compile,
but it does seem to fix the problems I was having.
Comment 13 Greg Sarjeant 2004-01-09 19:45:40 UTC
I have fixed the warnings in the Gateway 200X DSDT now. It now compiles with no
errors and no warnings. I have posted the asl to acpi.sourceforge.net. It is
available here:

Is there any possibility of a corollary to the Embedded Control initialization
patch for the 2.6.x kernels, or are you looking into a different solution for
that? Should I be trying something else?
Comment 14 Greg Sarjeant 2004-01-13 18:50:18 UTC
Hi,   I just wanted to send along an update on this.

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:  

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 ECDTschedule_task(): keventd has not startedevregion-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_EXISTACPI: 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?

I think it's safe to close this one, since the AE_BAD_PARAMETER issue is caused
by the buggy DSDT, and can be fixed by either replacing the DSDT or by applying
the bit_width patch. I'll submit a new bug for providing an ECDT in the 2.6.x

Thanks again for all of the help.

Comment 15 Greg Sarjeant 2004-01-16 08:32:19 UTC
The EC._INI patch at bug 1690 restores the battery and ac adapter on the 200X 
after applying the fixed DSDT. It works on both the 2.4.2x and 2.6.x kernels. 
It doesn't cause any of the odd behavior seen with the other two patches. There 
is a single H_EC subdirectory in /proc/acpi/embedded_controller with the 
correct ports in info. There are no errors in dmesg.

I had thought at first that the system fan wasn't coming on after applying this 
patch, but it is - it just isn't as frequent or as loud as before. The system 
is set to go to active cooling at 65 degrees. An mplayer compile topped out at 
about 68 for me, and there was a low humming from the fan if I put my ear right 
next to it. It had previously been a higher-pitched whirr, and audible from 
farther away. Also, now it is difficult to detect the exhaust, even with my 
hand right up against the fan grill. Previously I could definitely feel the fan 
blowing on my hand from an inch or so away. I guess now it just runs more 
slowly. Interestingly, in either case the fan does go on before the system hits 
65 (looks like it's somewhere in the 50s). Perhaps the fan was being 
hyperactive before? That would be nice, since I would expect slightly better 
battery life if the fan is better behaved. (The default battery on this laptop 
is practically worthless. I don't get 2 hours out of it under Linux or Windows.)

Anyhow, it looks now like the fixed DSDT and the patch at bug 1690 may be the 
best combination for this laptop. The patch is available here:

Comment 16 Nate Lawson 2004-02-03 11:27:40 UTC
In FreeBSD, we actually handle up to 32 bit accesses to EC space.  See

Comment 17 Luming Yu 2004-04-01 01:52:47 UTC
  The patch at http://bugzilla.kernel.org/show_bug.cgi?id=1744#c1 is necessary   
for informing user that only 8-bit width get supported, and we can treat it as  
warning ,rather than fatal error. 
 On the other hand, maybe we need to learn something from Free BSD at this 
Comment 18 Luming Yu 2004-04-15 18:25:05 UTC
  This issue happened on Gateway 200x, and any EC related device such as 
battery, fan, ... will not work well, just because EC address space fail to 
get fully initialized. If i didn't miss something, the following two patches 
aim at the issue.


Comment 19 Len Brown 2004-11-10 21:34:38 UTC
Created attachment 4007 [details]
luming's patch updated for 2.6.9

applied an updated version of the "ignore bit_width patch".
With Nate's comments about 32-bit support though, I'm wondering
if we'll be re-visiting this in the future to remove the warning.
Perhaps we should file an "ACPI Spec. clarification"...
Comment 20 lkbugs 2004-11-19 03:09:19 UTC

Patch 1741 fixed my issues with battery and ac status not showing up. Every time
a status change happens wrt those two issues I get the width-8 warning, as well
as on bootup and when viewing the info.

This was with kernel 2.6.10-rc2 with the bug 1515 patch also included.

Will something like this patch make it into the kernel? I'd hate to have to
forever patch the beast. :/
Comment 21 Luming Yu 2004-11-23 03:55:20 UTC
*** Bug 2857 has been marked as a duplicate of this bug. ***
Comment 22 Luming Yu 2004-11-23 04:12:03 UTC
Created attachment 4124 [details]
enable up-to 32-bit ec bit width.

Copy code of ec address space handler from FreeBSD.
 * Copyright (c) 2003 Nate Lawson
 * Copyright (c) 2000 Michael Smith
 * Copyright (c) 2000 BSDi
Comment 23 Oleksij Rempel (fishor) 2004-11-23 09:52:36 UTC
Hi Have samasung nv5000 
with it is same story 
i tryd  Luming's patc with kernel 2.6.10-rc2-mm3 
it still have : 
ACPI: acpi_ec_space_handler: bit_width should be 8 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
cat /proc/acpi/battery/BAT0/state -> present:                 no 
bat it's wrong 
Please let me know if you 
would like any additional information. 
Comment 24 Luming Yu 2004-11-23 18:06:04 UTC
Hi Alex,

Your problem seems Not related to the problem described here.
Please open a new bug for your specific issue.
The full boot log, and /proc/acpi/dsdt will help
me understand the problem better.

Comment 25 Luming Yu 2004-12-01 05:57:56 UTC
Created attachment 4185 [details]
an update version against latest acpi tree
Comment 26 Len Brown 2004-12-05 22:41:58 UTC
patch in comment #25 applied to acpi-test tree 
Comment 27 Len Brown 2005-01-03 17:42:37 UTC
shipped in 2.6.10 
Comment 28 Len Brown 2005-01-03 17:46:04 UTC
oops, didn't ship in 2.6.10, 
but is in early 2.6.11 
Comment 29 Len Brown 2005-01-26 21:53:10 UTC
shipped in linux-2.6.11-rc1 -- closing. 

Note You need to log in before you can comment on or make changes to this bug.