|Product:||ACPI||Reporter:||Thomas Meyer (thomas.mey)|
|Component:||ACPICA-Core||Assignee:||Robert Moore (Robert.Moore)|
|Kernel Version:||2.6.21-rc1 (git head 9654640d0af8f2de40ff3807d3695109d3463f54)||Tree:||Mainline|
Belonging kernel log buffer
My acpi tables
dmesg from 2.6.20
Dont use GL if not asked to
Fix GL re-entrancy
Dont allow query until address space init is complete
Description Thomas Meyer 2007-02-22 23:33:04 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
Comment 1 Thomas Meyer 2007-02-22 23:35:20 UTC
Created attachment 10502 [details] Belonging kernel log buffer
Comment 3 Robert Moore 2007-02-28 13:44:49 UTC
Looks like the exception is returned by the EC driver: ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for [EmbeddedControl] 
Comment 5 Alexey Starikovskiy 2007-02-28 16:43:19 UTC
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.
Comment 6 Alexey Starikovskiy 2007-03-01 08:23:39 UTC
Created attachment 10577 [details] Dont use GL if not asked to Please try the patch with recent rc.
Comment 7 Robert Moore 2007-03-01 09:58:04 UTC
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
Comment 8 Thomas Meyer 2007-03-01 10:55:56 UTC
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]  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
Comment 9 Alexey Starikovskiy 2007-03-02 10:36:43 UTC
Created attachment 10582 [details] Fix GL re-entrancy Digging deeper it appears that "GL enchancements" simply broke re-entrancy.
Comment 10 Alexey Starikovskiy 2007-03-02 10:46:12 UTC
Created attachment 10583 [details] Dont allow query until address space init is complete Please check if this patch helps with "Q10" error
Comment 11 Thomas Meyer 2007-03-02 14:16:13 UTC
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.
Comment 13 Len Brown 2007-03-07 15:42:01 UTC
patches from comment #6 and comment #10 applied to acpi-test -- target 2.6.22
Comment 14 Len Brown 2007-03-08 15:37:23 UTC
*** Bug 8080 has been marked as a duplicate of this bug. ***
Comment 16 Robert Moore 2007-03-14 13:48:14 UTC
Should this really be closed before the final "GL reentrancy" fix makes it into the ACPI CA core and is validated?
Comment 17 Len Brown 2007-03-14 15:03:58 UTC
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.
Comment 18 Robert Moore 2007-03-14 15:13:14 UTC
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: email@example.com [mailto:bugme- > firstname.lastname@example.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 email@example.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.
Comment 19 Len Brown 2007-03-14 21:13:18 UTC
> 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.