Kernel Bug Tracker – Bug 8066
Last modified: 2007-03-14 21:13:18 UTC
Several acpi (error/warning) messages appears in 2.6.21-rc1, that didn't appear
in 2.6.20 (before acpi update).
(i guess as a result of this messages my kde klaptopdaemon battery icon is gone,
but that is maybe an kde problem? I'm not sure about this.)
See attachted dmesg and acpidump
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
Created attachment 10561 [details]
dmesg from 2.6.20
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
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)
ACPI Error (exfldio-0289): Region EmbeddedControl(3) has no handler 
ACPI Exception (dswexec-0462): AE_NOT_EXIST, While resolving operands for
[OpcodeName unavailable] 
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
Should this really be closed before the final "GL reentrancy" fix makes it
into the ACPI CA core and is validated?
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: firstname.lastname@example.org [mailto:bugme-
> Sent: Wednesday, March 14, 2007 3:04 PM
> To: Moore, Robert
> Subject: [Bug 8066] AE_NOT_FOUND messages
> ------- Additional Comments From email@example.com 2007-03-14 15:03
> 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
> 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.