Created attachment 10502 [details]
Belonging kernel log buffer

Created attachment 10503 [details]
My acpi tables

Looks like the exception is returned by the EC driver:

ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for 
[EmbeddedControl] [20070126]

Created attachment 10561 [details]
dmesg from 2.6.20

Bob,
Could it be that install_gpe_handler is not right place to  run _REG method 
for _EC? It's address space handler is not installed at the moment. 

Created attachment 10577 [details]
Dont use GL if not asked to

Please try the patch with recent rc.

It looks like there is at least some handler present, "Returned by handler" 
means that the handler was invoked ("No handler for Region" is a separate 
message)

Please explain the GL change

Yes. This patch fixed the problem. Now my battery icon is back.
These messages remain:

ACPI Error (evregion-0316): No handler for Region [ECOR] (c190b434) 
[EmbeddedControl] [20070126]
ACPI Error (exfldio-0289): Region EmbeddedControl(3) has no handler [20070126]
ACPI Exception (dswexec-0462): AE_NOT_EXIST, While resolving operands for 
[OpcodeName unavailable] [20070126]
ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0.LPCB.EC__._Q10] (Node c190db94), AE_NOT_EXIST

Created attachment 10582 [details]
Fix GL re-entrancy

Digging deeper it appears that "GL enchancements" simply broke re-entrancy.

Created attachment 10583 [details]
Dont allow query until address space init is complete

Please check if this patch helps with "Q10" error

Applying the "Fix GL re-entrancy" patch the current (clean) git head, fixes the 
battery problem and removes all AE_xxx messages (also the Q10 messages), so i 
didn't apply the "Dont allow query until address space init is complete" at 
all. Thanks for the excellent work.

patch in comment #9 applied to acpi-test

patches from comment #6 and comment #10 applied to acpi-test -- target 2.6.22

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

patch in comment #9 shipped in 2.6.21-rc3-git6
closed

Should this really be closed before the final "GL reentrancy" fix makes it 
into the ACPI CA core and is validated?

Yes.
The protocols is this:

OPEN a bug when a failure in Linux is sighted.
ASSIGN a bug report when it is acknowledged and somebody is
at least trying to look into it.
RESOLVE a bug report when there is a patch in the report available to test.
CLOSE a bug report when the symptom in upstream Linux is gone.

So this bugzilla reflects the state of Linux --
not necessarily the state of ACPICA.

Of course, if the fix was somehow incomplete and
there are additional Linux sightings
that may be related to the same cause, then we'll
see additional Linux bug reports opened.

This is also why issues that are fixed first in ACPICA
may hang around in the RESOLVED state for some time --
as they are waiting for the ACPICA fix to make it into
Linux before they are CLOSED.

I have some concern that something might be lost if closed before the
fix is implemented in ACPICA and migrated into linux.


> -----Original Message-----
> From: bugme-daemon@bugzilla.kernel.org [mailto:bugme-
> daemon@bugzilla.kernel.org]
> Sent: Wednesday, March 14, 2007 3:04 PM
> To: Moore, Robert
> Subject: [Bug 8066] AE_NOT_FOUND messages
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=8066
> 
> 
> 
> 
> 
> ------- Additional Comments From len.brown@intel.com  2007-03-14 15:03
---
> ----
> Yes.
> The protocols is this:
> 
> OPEN a bug when a failure in Linux is sighted.
> ASSIGN a bug report when it is acknowledged and somebody is
> at least trying to look into it.
> RESOLVE a bug report when there is a patch in the report available to
> test.
> CLOSE a bug report when the symptom in upstream Linux is gone.
> 
> So this bugzilla reflects the state of Linux --
> not necessarily the state of ACPICA.
> 
> Of course, if the fix was somehow incomplete and
> there are additional Linux sightings
> that may be related to the same cause, then we'll
> see additional Linux bug reports opened.
> 
> This is also why issues that are fixed first in ACPICA
> may hang around in the RESOLVED state for some time --
> as they are waiting for the ACPICA fix to make it into
> Linux before they are CLOSED.
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.

> I have some concern that something might be lost if closed before the
> fix is implemented in ACPICA and migrated into linux.

Then file it in an ACPICA database, this database is for the Linux kernel only.