Bug 1744

Created attachment 1741 [details]
a proposal patch

Just try it.

Created attachment 1748 [details]
dmesg after applying bit width patch

Luming,

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

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
handler
 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,
AE_AML_NO_RETURN_VALUE
 psparse-1120: *** Error: Method execution failed [\_SB_.ADP1._STA] (Node
df5f42c8), AE_AML_NO_RETURN_VALUE
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
handler
 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,
AE_AML_NO_RETURN_VALUE
 psparse-1120: *** Error: Method execution failed [\_SB_.BAT1._STA] (Node
df5f4848), AE_AML_NO_RETURN_VALUE
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 :)

  Thanks,
   Greg

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.

Created attachment 1767 [details]
Relevant files after applying 12/29/2003 proposal patch

Luming,

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

    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
odd.
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
applied.

   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.

   Thanks,
    Greg

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
close.
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
2.6.0.

Thanks,
Greg

Luming,

   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.

   Thanks,
    Greg

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?

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

yields:

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)

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.

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

Created attachment 1810 [details]
Modified DSDT override patch

This is a minor modification to the DSDT override patch located here:
http://www.poupinou.org/acpi/over.html

so that it will compile with kernel 2.4.23

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.

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:
http://acpi.sourceforge.net/dsdt/view.php?id=140

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?

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:  
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 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
kernels.

Thanks again for all of the help.

Greg

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:

http://bugzilla.kernel.org/attachment.cgi?id=1690&action=view

In FreeBSD, we actually handle up to 32 bit accesses to EC space.  See
sys/dev/acpica/acpi_ec.c:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_ec.c?rev=1.42&content-type=text/x-cvsweb-markup

Len,   
  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 
point. 
 
Thanks, 
Luming 
   

Len,
  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.

1.http://bugzilla.kernel.org/attachment.cgi?id=1741&action=view
2.http://bugzilla.kernel.org/show_bug.cgi?id=1690

Thanks,
Luming

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

Hi,

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. :/

*** Bug 2857 has been marked as a duplicate of this bug. ***

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
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_ec.c?rev=1.42&content-type=text/x-cvsweb-markup

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 
 
and 
 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c11 
38508] 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c11 
38288] 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c11 
37f48] 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c1137cc8] 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c1137a48] 
acpi_bus-0073 [10] acpi_bus_get_device   : Error getting context for object 
[c7fc42c8] 
 
cat /proc/acpi/battery/BAT0/state -> present:                 no 
bat it's wrong 
Please let me know if you 
would like any additional information. 
 
Thanks, 
Alex 

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.

Thanks,
Luming

Created attachment 4185 [details]
an update version against latest acpi tree

patch in comment #25 applied to acpi-test tree 

shipped in 2.6.10 
closing 

oops, didn't ship in 2.6.10, 
but is in early 2.6.11 

shipped in linux-2.6.11-rc1 -- closing.