Bug 1690

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