EC._INI will fail, if there is no ec address space handler. To resolve this problem ECDT has been introduced. But there are many laptop lack ECDT. How about deferring the execution of EC._INI to later when the real EC address space handler has been installed.
Created attachment 1690 [details] a proposal patch for fixing this issue. This patch guarantee that EC._INI will not failed due to lack correct EC space handler. The only shortcoming is that it will not help other method which could illegally access EC address space.
Thanks for the patch. Next time I compile my kernel, I will give it a try. I'm amazed at the speed with which this issue was addressed, especially when it was originally reported in the wrong bug.
This isn't a bug. BIOSes typically use a variable, that gets set when _REG gets run for the EC opregion. What system is this on, anyways?
Andy, The user problem is at http://bugme.osdl.org/show_bug.cgi?id=1444#c40.
I applied the patch to Gentoo's kernel and those messages went away which I assume means this indeed fixed the problem. I am left with messages of: ACPI: System [ACPI] (supports S0 S3 S4 S5) ACPI-1120: *** Error: Method execution failed [\_SB_.C047.C053] (Node c1c102 c0), AE_AML_BUFFER_LIMIT ACPI-1120: *** Error: Method execution failed [\_SB_.C047.C057] (Node c1c103 00), AE_AML_BUFFER_LIMIT ACPI-1120: *** Error: Method execution failed [\_SB_.C047._CRS] (Node c1c103 40), AE_AML_BUFFER_LIMIT ACPI-0098: *** Error: Method execution failed [\_SB_.C047._CRS] (Node c1c103 40), AE_AML_BUFFER_LIMIT Those errors, I believe, were covered by the bug I originally reported this issue to though.
FYI - this patch also resolves the battery and ac adapter problems that I mentioned in bug 1744 (AE_BAD_PARAMETER) on the 2.6.x kernels. http://bugzilla.kernel.org/show_bug.cgi?id=1744#c14 I'll update that bug as well.
I can verify Greg. The battery/AC monitor in KDE works when the patch is applied.
This patch does not apply cleanly to the latest kernel sources.
I'm not familiar with the kernel patch workings, but how long does it take for a patch such as this to end up in the official kernel and/or ACPI4Linux patchset, assuming no regressions for other systems.
I am investigating this for inclusion in the ACPI CA core. Bob
*** Bug 2310 has been marked as a duplicate of this bug. ***
Bob, could you please provide a solution for all ECDT lack problem? we have other issues which failed when executing battery's _INI method istead of EC._INI. the issue is bug 2093
Created attachment 2553 [details] fix one annoying reject when applied to 2.4.26-rc2
I have a problem with this patch, and it concerns the sharing of a global variable between the EC driver and the ACPI CA core (acpi_ec_need_reinit). I would prefer a different solution that does not share a global. Bob
Bob, How about export a new function from ACPI CA , that can tell EC driver that EC._INI should be re-executed. Thanks, Luming
So you didn't take care about other ECDT lack problems? I don't think reinit EC._INI is a good solution. If you want to provide a workaround, why doesn't provide a workarond for all such kind of problem. Please note ec address space handler only need to know the ioport. So if ECDT is lack, ACPICA can pre-scan DSDT, find the EC's ioport (just parse _CRS) and provide a temporary EC address hander untill EC is initialized. this can resolve all similar problems istead of EC._INI problem. Bob, please evaluate this method.
The ACPI CA core does not scan around for particular devices, this is the responsibility of upper OSPM software. Nor does it parse resource packages. I don't want to add this kind of code just for the EC. Bob
It would be helpful if someone could post a DSDT that exhibits the EC._INI issue. Bob
> It would be helpful if someone could post a DSDT that exhibits the EC._INI issue. Sure, I'm ready to do this (I guess I can do it since I have a machine that seems to have an issue related to this DSDT stuff), point is I do not know exactly what to do. I already posted a bunch of log outputs on the bug 2310 page, could please tell me what command line I'd need to type to get this "DSDT" (or simply point me to some instructive URL so that I can RTFM). Thanks in advance, Christian.
*** Bug 2667 has been marked as a duplicate of this bug. ***
Christian, your acpidmp output in the other bug report is sufficient for Bob to extract the DSDT. thanks. -Len
I have serious problems with this change although I don't know how to solve it. --- ACPI 2.0 spec section 6.5.1: The _INI method must only access Operation Regions that have been indicated to available as defined by the _REG method. The _REG method is described in section 6.5.4, "_REG (Region)." This control method is run before _ADR, _CID, _HID, _SUN, and _UID are run. --- If we are probing without an ECDT, we have to run _HID and/or _CID to find the EC device. But this spec explicitly says you have to run _INI first. If the EC._INI method accesses the EC space, what can it expect to accomplish? The patch from Luming appears to create a no-op EC space handler. I can't see how this is any different from having no handler installed, which is ACPI-CA's current behavior I believe. Also, I can't seem to find a DSDT for the Toshiba Tecra S1 that Christian seems to indicate has this problem. The Gateway 200x listed by Greg in another bug does not have an EC._INI method.
I attached a disassembled version of the DSDT for my Toshiba Tecra S1 here: http://bugme.osdl.org/show_bug.cgi?id=2667#c3
*** Bug 2541 has been marked as a duplicate of this bug. ***
FYI I installed a kernel 2.6.8 on my laptop, and battery is now correctly detected and its charge correctly displayed, without applying any patch. I installed a locally compiled kernel, using a Debian source package (sarge). I also updated the BIOS (after I first saw it worked) and it kept working. So from my point of view the problem is solved (previous Bug 2310).
Sorry to correct Christian: a vanilla (kernel.org) 2.6.8 kernel does NOT fix the problem. The Debian 2.6.8 kernel package that he used is heavily patched. However, I can confirm that this Debian kernel works on my Toshiba Tecra S1, too. It has other issues, though (e.g. resume from S3 doesn't work). Note that the patch attached to this bug page is NOT among those applied to the Debian kernel, rather a patch called acpi-early-init seems to do the trick.
Created attachment 4031 [details] fake ECDT patch Please try this patch. The idea of the patch is if system hasn't an ECDT, try to make a fake ECDT by pre-scanning EC device.
*** Bug 1515 has been marked as a duplicate of this bug. ***
Created attachment 4035 [details] fake ECDT patch using boot option Using boot option possibly is better (still using above idea in the patch). Please apply the patch and add boot option 'acpi_fake_ecdt'
Created attachment 4073 [details] updated patch Per Len's request, add comments in the patch. The patch passed test in a Toshiba laptop and T40 (I force them using fake ECDT instead of physical ECDT).
applied patch in comment #30 to acpi-test tree
shipped in linux-2.6.11-rc1 -- closing.
I think this bug needs to be reopened. I have a Sony Vaio PCG-K195HP and have made the following observations. Note that I am using a corrected DSDT, which I created using Intel's compiler. Sorry about the different kernels but the ACPI stuff should be the same anyway. gentoo-2.6.9-r9 - /proc/acpi/battery works fine but ACPI battery errors appear in dmesg. Haven't got these to hand but apparently they are typical of a missing ECDT. suspend2-2.6.13-r4 (based on gentoo) - /proc/acpi/battery doesn't work at all normally. I discovered the original patch submitted here by Luming Yu before seeing the entire bug report so I updated the patch and applied it to this kernel. It worked. I only then discovered the acpi_fake_ecdt option so I removed the patch and tried the option but it had no effect. linux-2.6.14-rc2 - Basically the same result as suspend2-2.6.13-r4 but the patch only seems to work when not using a custom DSDT? Evidently there is some key element missing from the acpi_fake_ecdt option that is present in the orignal patch. It's unlikely but if anyone watching this is going to be at LinuxWorld in London next week, they can take a look at this machine.
Created attachment 6201 [details] Original patch updated for 2.6.14-rc2 I'm not saying this patch should be used instead but I thought I'd include it here to make solving the problem easier.
Please post dmesg and acpidump output.
Created attachment 6505 [details] Chewi's dmesg Sorry for the delay. I'm now running 2.6.14-suspend2 and basically, it works sometimes but not others, regardless of whether I'm using acpi_fake_ecdt or not. Here is my dmesg. My DSDT (I don't have acpidump but that's what it dumps right?) will follow.
Created attachment 6506 [details] Sony-PCG-K195HP-radeon64-custom.asl
Please try boot option ec_burst=1, and disable preempt.
I upgraded to 2.6.14-r2 and tried ec_burst=1 with and without preempt. I said the battery was absent every time, I'm afraid. )-: