Greg Sarjeant [greg@morningdave.org] said: Hello, 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. Thanks, Greg ~
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.