Just one more information i got from my 2.6.12-10 kernel's source. I'm
not a kernel hacker but I could find some points that it may be
calling that error messages.
What I got is that both errors on parser/psparse.c and
utilities/uteval.c call the acpi_ns_report_error with the message
"Method execution failed" that's why we see that particular order on
/var/log/messages.
As far as I can tell, it can only be one of those two errors:
acpi_ps_parse_loop or acpi_ns_evaluate_relative. Couldn't be
acpi_ns_evaluate_relative because it have a special treatment for
AE_NOT_FOUND and the error message is different, thus it must be on
acpi_ps_parse_loop.
Also, I noted that acpi_ps_parse_loop has no special treatment for
AE_NOT_FOUND and also does not return it by it's own, so it's probably
returned by some methods it calls.
Now, for the code snippets:
- drivers/acpi/parser/psparse.c:1112 - 1138
while (walk_state) {
if (ACPI_SUCCESS (status)) {
/*
* The parse_loop executes AML until the method terminates
* or calls another method.
*/
status = acpi_ps_parse_loop (walk_state);
}
(...)
if (status == AE_CTRL_TRANSFER) {
(...)
else if ((status != AE_OK) && (walk_state->method_desc)) {
ACPI_REPORT_METHOD_ERROR ("Method execution failed",
walk_state->method_node, NULL, status);
- drivers/acpi/utilities/uteval.c:150 - 162
status = acpi_ns_evaluate_relative (path, &info);
if (ACPI_FAILURE (status)) {
if (status == AE_NOT_FOUND) {
ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "[%4.4s.%s] was not found\n",
acpi_ut_get_node_name (prefix_node), path));
}
else {
ACPI_REPORT_METHOD_ERROR ("Method execution failed",
prefix_node, path, status);
}
return_ACPI_STATUS (status);
}
- drivers/acpi/namespace/nsutils.c:70
void
acpi_ns_report_error (...)
(...)
acpi_os_printf ("%8s-%04d: *** Error: Looking up ",
module_name, line_number);
cheers,
--rengolin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
