Skip to contentSkip to conversation

4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

DISCUSSION Imre Deak 3 participants 12 messages Oct 19, 2016 – Oct 27, 2016 1 message not in the archive

Subsystems (2)
ACPI ACPI component architecture (acpica)
lore
Share & tools
lore

Imre Deak

author
#0 lore raw

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-330)
[   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227)
[   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8), AE_ALREADY_EXISTS (20160831/psparse-543) [   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node ffff8802770b7dc0), AE_ALREADY_EXISTS (20160831/psparse-543) [   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa
Author: Lv Zheng <[email protected]>
Date:   Wed Sep 7 14:07:10 2016 +0800

    ACPICA: Namespace: Fix dynamic table loading issues

Reverting this on top of 4.9-rc1 gets rid of the error messages.

--Imre

#1 lore raw

Hi, Imre

Quoted 8 lines

From: Deak, Imre
Subject: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

Quoted 7 lines

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-330) [   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227) [   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node ffff8802770b7dc0), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Could you send me acpidump output?

Quoted 10 lines

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa
Author: Lv Zheng <lv.zheng(a)intel.com>
Date:   Wed Sep 7 14:07:10 2016 +0800

    ACPICA: Namespace: Fix dynamic table loading issues

Reverting this on top of 4.9-rc1 gets rid of the error messages.

This fix is essential.
Without this, all of other ACPICA fixes can easily fall into dead locks. So we won't simply revert it just because of non-functional-failure error messages. Instead, we will improve it.

Thanks and best regards
Lv

#2 lore raw
In reply to Imre Deak

Hi,

Quoted 22 lines

From: Deak, Imre
Subject: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-330) [   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227) [   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node ffff8802770b7dc0), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa
Author: Lv Zheng <lv.zheng(a)intel.com>
Date:   Wed Sep 7 14:07:10 2016 +0800

Quoted 3 lines

    ACPICA: Namespace: Fix dynamic table loading issues

Reverting this on top of 4.9-rc1 gets rid of the error messages.

The commit in question only modified code to make locks unlocked/locked. Which should be transparent to the functional stuffs.
I'm not sure how it can lead to such error in the single-threading boot environment. Please provide the acpidump output for further investigation.

Thanks and best regards
Lv

maintainer
#3 lore raw
Quoted 24 lines · Lv

Hi,

Quoted 22 lines

From: Deak, Imre
Subject: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-330)
[   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227)
[   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8),
AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node ffff8802770b7dc0),
AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa

Author: Lv Zheng <[email protected]>
Date:   Wed Sep 7 14:07:10 2016 +0800
Quoted 6 lines
Quoted 3 lines

ACPICA: Namespace: Fix dynamic table loading issues

Reverting this on top of 4.9-rc1 gets rid of the error messages.

The commit in question only modified code to make locks unlocked/locked. Which should be transparent to the functional stuffs.

It might change the relative timing of thigs (which might result in ordering changes).

Quoted 1 line

I'm not sure how it can lead to such error in the single-threading boot environment.

Why do you think it's single-threaded? At least suspend/resume isn't in general.

Thanks,
Rafael

#4 lore raw

Hi, Rafael

Quoted 32 lines

From: rjwysocki(a)gmail.com [mailto:rjwysocki(a)gmail.com] On Behalf Of Rafael J. Wysocki
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 11 lines · Lv

Hi,

Quoted 9 lines

From: Deak, Imre
Subject: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-

330)

Quoted 4 lines
Quoted 4 lines
[   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227)
[   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8),
AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node

ffff8802770b7dc0),

Quoted 11 lines
Quoted 11 lines

AE_ALREADY_EXISTS (20160831/psparse-543)

[   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa

Author: Lv Zheng <lv.zheng(a)intel.com>
Date:   Wed Sep 7 14:07:10 2016 +0800

ACPICA: Namespace: Fix dynamic table loading issues

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Reverting this on top of 4.9-rc1 gets rid of the error messages.

The commit in question only modified code to make locks unlocked/locked. Which should be transparent to the functional stuffs.

It might change the relative timing of thigs (which might result in ordering changes).

Yes, I'll check that with the acpidump.
To see if this is caused by wrong reduced lock affection scope.

Quoted 5 lines
Quoted 2 lines

I'm not sure how it can lead to such error in the single-threading boot environment.

Why do you think it's single-threaded? At least suspend/resume isn't in general.

I just say that because it is also reported as "occasionally during boot".

Thanks and best regards
Lv

#5 lore raw
In reply to Imre Deak

Hi, Imre

Quoted 22 lines

From: Deak, Imre
Subject: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi,

after upgrading to 4.9-rc1 I get the following errors occasionally during boot and suspend-to-ram on an APL system:

[   59.513434] ACPI Error: [TMP_] Namespace lookup failure, AE_ALREADY_EXISTS (20160831/dswload2-330) [   59.513446] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160831/psobject-227) [   59.513469] ACPI Error: Method parse/execution failed [\_SB.PCI0.SCPG] (Node ffff8802770b7bb8), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.515415] ACPI Error: Method parse/execution failed [\_SB.PCI0.SDHA._PS3] (Node ffff8802770b7dc0), AE_ALREADY_EXISTS (20160831/psparse-543)
[   59.517118] ACPI: Marking method _PS3 as Serialized because of AE_ALREADY_EXISTS error

Other than these error messages, booting and suspend/resume seems to work ok. Bisecting points to
commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa
Author: Lv Zheng <lv.zheng(a)intel.com>
Date:   Wed Sep 7 14:07:10 2016 +0800

Quoted 3 lines

    ACPICA: Namespace: Fix dynamic table loading issues

Reverting this on top of 4.9-rc1 gets rid of the error messages.

I checked the code, only found one issue.
And I'm not sure if it is related.
Please send me the full dmesg containing the errors and the acpidump output.

Please give the fix a try (see attachment).
I'm sorry for sending fix patch using attachment.
It's not convenient for me due to my current working environment.

Thanks and best regards
Lv

From 5f919f66c147c9fd4ce0a3c814480ad58479d252 Mon Sep 17 00:00:00 2001
From: Lv Zheng <[email protected]>
Date: Sat, 22 Oct 2016 01:41:03 +0800
From: Lv Zheng <[email protected]>
Subject: [PATCH 0] ACPICA: Dispatcher: Tune interpreter lock around acpi_ev_initialize_region()

In code path of acpi_ev_initialize_region(), there are namespace modification code unlocked. This patch tunes the code to make sure such modification are locked. Lv Zheng.

Signed-off-by Lv Zheng <[email protected]>
---
 dsinit.c   |   13 +++++--------
 dswload2.c |    2 --
 evrgnini.c |    3 +++
 nsload.c   |    2 ++
 4 files changed, 10 insertions(+), 10 deletions(-)
drivers/acpi/acpica/dsinit.c +5 -8
diff -Nurp linux.before/drivers/acpi/acpica/dsinit.c linux.after/drivers/acpi/acpica/dsinit.c
@@ -46,6 +46,7 @@
 #include "acdispat.h"
 #include "acnamesp.h"
 #include "actables.h"
+#include "acinterp.h"
 
 #define _COMPONENT          ACPI_DISPATCHER
 ACPI_MODULE_NAME("dsinit")

@@ -140,7 +141,9 @@ acpi_ds_init_one_object(acpi_handle obj_
 
 			/* Parse/scan method and serialize it if necessary */
 
+			acpi_ex_exit_interpreter();
 			acpi_ds_auto_serialize_method(node, obj_desc);
+			acpi_ex_enter_interpreter();
 			if (obj_desc->method.
 			    info_flags & ACPI_METHOD_SERIALIZED) {
 

@@ -214,23 +217,17 @@ acpi_ds_initialize_objects(u32 table_ind
 
 	/* Walk entire namespace from the supplied root */
 
-	status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
-	if (ACPI_FAILURE(status)) {
-		return_ACPI_STATUS(status);
-	}
-
 	/*
 	 * We don't use acpi_walk_namespace since we do not want to acquire
 	 * the namespace reader lock.
 	 */
 	status =
 	    acpi_ns_walk_namespace(ACPI_TYPE_ANY, start_node, ACPI_UINT32_MAX,
-				   ACPI_NS_WALK_UNLOCK, acpi_ds_init_one_object,
-				   NULL, &info, NULL);
+				   0, acpi_ds_init_one_object, NULL, &info,
+				   NULL);
 	if (ACPI_FAILURE(status)) {
 		ACPI_EXCEPTION((AE_INFO, status, "During WalkNamespace"));
 	}
-	(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
 
 	status = acpi_get_table_by_index(table_index, &table);
 	if (ACPI_FAILURE(status)) {
drivers/acpi/acpica/dswload2.c +0 -2
diff -Nurp linux.before/drivers/acpi/acpica/dswload2.c linux.after/drivers/acpi/acpica/dswload2.c
@@ -607,11 +607,9 @@ acpi_status acpi_ds_load2_end_op(struct
 				}
 			}
 
-			acpi_ex_exit_interpreter();
 			status =
 			    acpi_ev_initialize_region
 			    (acpi_ns_get_attached_object(node));
-			acpi_ex_enter_interpreter();
 			break;
 
 		case AML_NAME_OP:
drivers/acpi/acpica/evrgnini.c +3 -0
diff -Nurp linux.before/drivers/acpi/acpica/evrgnini.c linux.after/drivers/acpi/acpica/evrgnini.c
@@ -45,6 +45,7 @@
 #include "accommon.h"
 #include "acevents.h"
 #include "acnamesp.h"
+#include "acinterp.h"
 
 #define _COMPONENT          ACPI_EVENTS
 ACPI_MODULE_NAME("evrgnini")

@@ -594,8 +595,10 @@ acpi_status acpi_ev_initialize_region(un
 				 * Tell all users that this region is usable by
 				 * running the _REG method
 				 */
+				acpi_ex_exit_interpreter();
 				(void)acpi_ev_execute_reg_method(region_obj,
 								 ACPI_REG_CONNECT);
+				acpi_ex_enter_interpreter();
 				return_ACPI_STATUS(AE_OK);
 			}
 		}
drivers/acpi/acpica/nsload.c +2 -0
diff -Nurp linux.before/drivers/acpi/acpica/nsload.c linux.after/drivers/acpi/acpica/nsload.c
@@ -137,7 +137,9 @@ unlock:
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			  "**** Begin Table Object Initialization\n"));
 
+	acpi_ex_enter_interpreter();
 	status = acpi_ds_initialize_objects(table_index, node);
+	acpi_ex_exit_interpreter();
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			  "**** Completed Table Object Initialization\n"));

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw

Hi, Imre

Quoted 10 lines

From: Deak, Imre
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 5 lines · Lv

 [...]
I checked the code, only found one issue.
And I'm not sure if it is related.
Please send me the full dmesg containing the errors and the acpidump output.

Quoted 5 lines

I attached the dmesg containing the error during boot (happened 1 out of 200 boots), during reboot (20 out of 200 reboots), during suspend (happened all the time).

I attached the acpidump output.

Thanks for the information.

Quoted 6 lines
Quoted 2 lines

Please give the fix a try (see attachment).

The patch didn't apply on 4.9-rc1 or Linus' master, please see the attached patch for my attempt to resolve the conflicts. With the patch applied I could still trigger the same problem during suspend.

Could you pull this branch directly and try again:
https://github.com/zetalog/linux
Branch: acpica-lock

I've pushed the fix commit there.

Thanks in advance.

Best regards
Lv

Quoted 8 lines

--Imre

Quoted 5 lines

I'm sorry for sending fix patch using attachment.
It's not convenient for me due to my current working environment.

Thanks and best regards
Lv

#8 lore raw
In reply to a message not in the archive

Hi, Imre

Quoted 10 lines

From: Deak, Imre
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 5 lines · Lv

 [...]
I checked the code, only found one issue.
And I'm not sure if it is related.
Please send me the full dmesg containing the errors and the acpidump output.

Quoted 3 lines

I attached the dmesg containing the error during boot (happened 1 out of 200 boots), during reboot (20 out of 200 reboots), during suspend (happened all the time).

I just checked the error and the related code.

1. What the error is
The error message is generated by an old method auto-serial mechanism. However this mechanism should have been disabled by new auto-serial approach.

See: the error is generated by the code in drivers/acpi/acpica/psparse.c:

			if ((status == AE_ALREADY_EXISTS) &&
			    (!(walk_state->method_desc->method.
			       info_flags & ACPI_METHOD_SERIALIZED))) {
				/*
				 * Method is not serialized and tried to create an object
				 * twice. The probable cause is that the method cannot
				 * handle reentrancy. Mark as "pending serialized" now, and
				 * then mark "serialized" when the last thread exits.
				 */
				walk_state->method_desc->method.info_flags |=
				    ACPI_METHOD_SERIALIZED_PENDING;
			}
It can only happen when ACPI_METHOD_SERIALIZED flag is not set.
However, in the upstream kernel, this flag is set by the code in drivers/acpi/acpica/dsinit.c:
		if (obj_desc->method.info_flags & ACPI_METHOD_SERIALIZED) {
			info->serial_method_count++;
			break;
		}

		if (acpi_gbl_auto_serialize_methods) {

			/* Parse/scan method and serialize it if necessary */

			acpi_ds_auto_serialize_method(node, obj_desc);
			if (obj_desc->method.
			    info_flags & ACPI_METHOD_SERIALIZED) {

				/* Method was just converted to Serialized */

				info->serial_method_count++;
				info->serialized_method_count++;
				break;
			}
		}

Which is invoked by acpi_ds_initialize_objects(), always invoked in acpi_ns_load_table(). Unless acpi_gbl_auto_serialize_methods = false or acpi_ns_parse_table() failed, the flag won't be remained unset.

The error message is generated by old auto-serialize implementation. And acpi_gbl_auto_serialize_methods is meant to mute the warnings.

Both mechanism should work, thus this error message is not fatal. It just makes ACPICA to fall back to use old auto-serial method. So the issue is not urgent.

2. Why the error message is caused
I couldn't see whether the bisected commit can be related to this feature. It seems we need your help to debug what the problem is.

First, please try the mentioned branch here:
https://github.com/zetalog/linux
acpica-lock branch.

As I may need to ask for several debugging steps, let me file a kernel Bugzilla bug for this. So that we can communicate there in order not to bother others:

https://bugzilla.kernel.org/show_bug.cgi?id=180111

Thanks and best regards
Lv

Quoted 16 lines

I attached the acpidump output.

Quoted 1 line

Please give the fix a try (see attachment).

The patch didn't apply on 4.9-rc1 or Linus' master, please see the attached patch for my attempt to resolve the conflicts. With the patch applied I could still trigger the same problem during suspend.

--Imre

Quoted 5 lines

I'm sorry for sending fix patch using attachment.
It's not convenient for me due to my current working environment.

Thanks and best regards
Lv

#9 lore raw
Quoted 29 lines

-----Original Message-----
From: Zheng, Lv
Sent: Monday, October 24, 2016 12:36 AM
To: Deak, Imre <imre.deak(a)intel.com>; Moore, Robert <robert.moore(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; linux-acpi(a)vger.kernel.org; devel(a)acpica.org
Subject: RE: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi, Imre

Quoted 11 lines

From: Deak, Imre
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 5 lines · Lv

 [...]
I checked the code, only found one issue.
And I'm not sure if it is related.
Please send me the full dmesg containing the errors and the acpidump output.

Quoted 3 lines

I attached the dmesg containing the error during boot (happened 1 out of 200 boots), during reboot (20 out of 200 reboots), during suspend (happened all the time).

Quoted 6 lines

I just checked the error and the related code.

1. What the error is
The error message is generated by an old method auto-serial mechanism. However this mechanism should have been disabled by new auto-serial approach.

[Moore, Robert]

We kept the original auto-serialize mechanism because the new one is not 100% deterministic. Thus, the original mechanism is a fallback case, that is why it is still there. It should not be removed.

Quoted 89 lines

See: the error is generated by the code in
drivers/acpi/acpica/psparse.c:

			if ((status == AE_ALREADY_EXISTS) &&
			    (!(walk_state->method_desc->method.
			       info_flags & ACPI_METHOD_SERIALIZED))) {
				/*
				 * Method is not serialized and tried to create an

object
* twice. The probable cause is that the method
cannot
* handle reentrancy. Mark as "pending serialized"
now, and
* then mark "serialized" when the last thread
exits.

				 */
				walk_state->method_desc->method.info_flags |=
				    ACPI_METHOD_SERIALIZED_PENDING;
			}
It can only happen when ACPI_METHOD_SERIALIZED flag is not set.
However, in the upstream kernel, this flag is set by the code in
drivers/acpi/acpica/dsinit.c:
		if (obj_desc->method.info_flags & ACPI_METHOD_SERIALIZED) {
			info->serial_method_count++;
			break;
		}

		if (acpi_gbl_auto_serialize_methods) {

			/* Parse/scan method and serialize it if necessary */

			acpi_ds_auto_serialize_method(node, obj_desc);
			if (obj_desc->method.
			    info_flags & ACPI_METHOD_SERIALIZED) {

				/* Method was just converted to Serialized */

				info->serial_method_count++;
				info->serialized_method_count++;
				break;
			}
		}

Which is invoked by acpi_ds_initialize_objects(), always invoked in acpi_ns_load_table().
Unless acpi_gbl_auto_serialize_methods = false or acpi_ns_parse_table() failed, the flag won't be remained unset.

The error message is generated by old auto-serialize implementation. And acpi_gbl_auto_serialize_methods is meant to mute the warnings.

Both mechanism should work, thus this error message is not fatal. It just makes ACPICA to fall back to use old auto-serial method. So the issue is not urgent.

2. Why the error message is caused
I couldn't see whether the bisected commit can be related to this feature.
It seems we need your help to debug what the problem is.

First, please try the mentioned branch here:
https://github.com/zetalog/linux
acpica-lock branch.

As I may need to ask for several debugging steps, let me file a kernel Bugzilla bug for this.
So that we can communicate there in order not to bother others:

https://bugzilla.kernel.org/show_bug.cgi?id=180111

Thanks and best regards
Lv

Quoted 16 lines

I attached the acpidump output.

Quoted 1 line

Please give the fix a try (see attachment).

The patch didn't apply on 4.9-rc1 or Linus' master, please see the attached patch for my attempt to resolve the conflicts. With the patch applied I could still trigger the same problem during suspend.

--Imre

Quoted 5 lines

I'm sorry for sending fix patch using attachment.
It's not convenient for me due to my current working environment.

Thanks and best regards
Lv

#10 lore raw
In reply to a message not in the archive

Hi, Imre

I think this is the root cause fix:
https://github.com/zetalog/linux/commit/108009d0
Which seems to be an old trap triggered by the good fix.

Could you give the fix commit a try?
It’s better to use this branch, where more improvements are included:
git clone linux-acpica https://github.com/zetalog/linux
git branch acpica-lock linux-acpica/acpica-lock
git checkout acpica-lock

Thanks in advance.

Best regards
Lv

Quoted 104 lines

From: Zheng, Lv
Subject: RE: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Hi, Imre

Quoted 10 lines

From: Deak, Imre
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 5 lines · Lv

 [...]
I checked the code, only found one issue.
And I'm not sure if it is related.
Please send me the full dmesg containing the errors and the acpidump output.

Quoted 3 lines

I attached the dmesg containing the error during boot (happened 1 out of 200 boots), during reboot (20 out of 200 reboots), during suspend (happened all the time).

I just checked the error and the related code.

1. What the error is
The error message is generated by an old method auto-serial mechanism. However this mechanism should have been disabled by new auto-serial approach.

See: the error is generated by the code in drivers/acpi/acpica/psparse.c:

			if ((status == AE_ALREADY_EXISTS) &&
			    (!(walk_state->method_desc->method.
			       info_flags & ACPI_METHOD_SERIALIZED))) {
				/*
				 * Method is not serialized and tried to create an object
				 * twice. The probable cause is that the method cannot
				 * handle reentrancy. Mark as "pending serialized" now, and
				 * then mark "serialized" when the last thread exits.
				 */
				walk_state->method_desc->method.info_flags |=
				    ACPI_METHOD_SERIALIZED_PENDING;
			}
It can only happen when ACPI_METHOD_SERIALIZED flag is not set.
However, in the upstream kernel, this flag is set by the code in drivers/acpi/acpica/dsinit.c:
		if (obj_desc->method.info_flags & ACPI_METHOD_SERIALIZED) {
			info->serial_method_count++;
			break;
		}

		if (acpi_gbl_auto_serialize_methods) {

			/* Parse/scan method and serialize it if necessary */

			acpi_ds_auto_serialize_method(node, obj_desc);
			if (obj_desc->method.
			    info_flags & ACPI_METHOD_SERIALIZED) {

				/* Method was just converted to Serialized */

				info->serial_method_count++;
				info->serialized_method_count++;
				break;
			}
		}

Which is invoked by acpi_ds_initialize_objects(), always invoked in acpi_ns_load_table(). Unless acpi_gbl_auto_serialize_methods = false or acpi_ns_parse_table() failed, the flag won't be remained unset.

The error message is generated by old auto-serialize implementation. And acpi_gbl_auto_serialize_methods is meant to mute the warnings.

Both mechanism should work, thus this error message is not fatal. It just makes ACPICA to fall back to use old auto-serial method. So the issue is not urgent.

2. Why the error message is caused
I couldn't see whether the bisected commit can be related to this feature. It seems we need your help to debug what the problem is.

First, please try the mentioned branch here:
https://github.com/zetalog/linux
acpica-lock branch.

As I may need to ask for several debugging steps, let me file a kernel Bugzilla bug for this. So that we can communicate there in order not to bother others:

https://bugzilla.kernel.org/show_bug.cgi?id=180111

Thanks and best regards
Lv

Quoted 16 lines

I attached the acpidump output.

Quoted 1 line

Please give the fix a try (see attachment).

The patch didn't apply on 4.9-rc1 or Linus' master, please see the attached patch for my attempt to resolve the conflicts. With the patch applied I could still trigger the same problem during suspend.

--Imre

Quoted 5 lines

I'm sorry for sending fix patch using attachment.
It's not convenient for me due to my current working environment.

Thanks and best regards
Lv

author
#11 lore raw
Quoted 11 lines · Lv

Hi, Imre

I think this is the root cause fix:
https://github.com/zetalog/linux/commit/108009d0
Which seems to be an old trap triggered by the good fix.

Could you give the fix commit a try?
It’s better to use this branch, where more improvements are included:
git clone linux-acpica https://github.com/zetalog/linux
git branch acpica-lock linux-acpica/acpica-lock
git checkout acpica-lock

Yes, with the above branch I couldn't reproduce the problem during suspend/resume while reverting 108009d0 made the problem reappear.

--Imre

#12 lore raw

Hi, Imre

Quoted 10 lines

From: Deak, Imre
Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS

Quoted 6 lines · Lv

Hi, Imre

I think this is the root cause fix:
https://github.com/zetalog/linux/commit/108009d0
Which seems to be an old trap triggered by the good fix.

Quoted 8 lines
Quoted 5 lines

Could you give the fix commit a try?
It’s better to use this branch, where more improvements are included:
git clone linux-acpica https://github.com/zetalog/linux
git branch acpica-lock linux-acpica/acpica-lock
git checkout acpica-lock

Yes, with the above branch I couldn't reproduce the problem during suspend/resume while reverting 108009d0 made the problem reappear.

Thanks for the bug report.
I've sent the patches to the ACPI mailinglist.

Best regards
Lv