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

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

[Imre Deak]

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@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.

--Imre

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

[Zheng, Lv]

Hi, Imre

> 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

Could you send me acpidump output?

> 
> Other than these error messages, booting and suspend/resume seems to work ok.
> Bisecting points to
> commit 74f51b80a0c4ff84fbeb7f12ea43ce66934d29aa
> Author: Lv Zheng <lv.zheng@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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

Hi, Imre

> 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

Could you send me acpidump output?

> 
> 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

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

[Zheng, Lv]

Hi,

> 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@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.

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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

Hi,

> 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
> 
>     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

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

[Rafael J. Wysocki]

On Thu, Oct 20, 2016 at 8:44 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi,
>
>> 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@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.
>
> 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).

> 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

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

[Zheng, Lv]

Hi, Rafael

> From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of Rafael J. Wysocki
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On Thu, Oct 20, 2016 at 8:44 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > Hi,
> >
> >> 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@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.
> >
> > 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.

> 
> > 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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Hi, Rafael

> 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
> 
> On Thu, Oct 20, 2016 at 8:44 PM, Zheng, Lv <lv.zheng(a)intel.com> wrote:
> > Hi,
> >
> >> 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
> >>
> >>     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).

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

> 
> > 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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Hi, Imre

> 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@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.

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

[-- Attachment #2: lv-lockx.patch --]
[-- Type: application/octet-stream, Size: 4138 bytes --]

From 5f919f66c147c9fd4ce0a3c814480ad58479d252 Mon Sep 17 00:00:00 2001
From: Lv Zheng <lv.zheng@intel.com>
Date: Sat, 22 Oct 2016 01:41:03 +0800
From: Lv Zheng <lv.zheng@intel.com>
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 <lv.zheng@intel.com>
---
 dsinit.c   |   13 +++++--------
 dswload2.c |    2 --
 evrgnini.c |    3 +++
 nsload.c   |    2 ++
 4 files changed, 10 insertions(+), 10 deletions(-)

diff -Nurp linux.before/drivers/acpi/acpica/dsinit.c linux.after/drivers/acpi/acpica/dsinit.c
--- linux.before/drivers/acpi/acpica/dsinit.c	2016-10-22 01:50:09.496430502 +0800
+++ linux.after/drivers/acpi/acpica/dsinit.c	2016-10-22 01:50:05.976430479 +0800
@@ -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)) {
diff -Nurp linux.before/drivers/acpi/acpica/dswload2.c linux.after/drivers/acpi/acpica/dswload2.c
--- linux.before/drivers/acpi/acpica/dswload2.c	2016-10-22 01:50:09.480430502 +0800
+++ linux.after/drivers/acpi/acpica/dswload2.c	2016-10-22 01:50:05.960430479 +0800
@@ -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:
diff -Nurp linux.before/drivers/acpi/acpica/evrgnini.c linux.after/drivers/acpi/acpica/evrgnini.c
--- linux.before/drivers/acpi/acpica/evrgnini.c	2016-10-22 01:50:09.484430502 +0800
+++ linux.after/drivers/acpi/acpica/evrgnini.c	2016-10-22 01:50:05.964430479 +0800
@@ -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);
 			}
 		}
diff -Nurp linux.before/drivers/acpi/acpica/nsload.c linux.after/drivers/acpi/acpica/nsload.c
--- linux.before/drivers/acpi/acpica/nsload.c	2016-10-22 01:50:09.496430502 +0800
+++ linux.after/drivers/acpi/acpica/nsload.c	2016-10-22 01:50:05.976430479 +0800
@@ -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"));

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

Hi, Imre

> 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
> 
>     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

[-- Attachment #2: lv-lockx.patch --]
[-- Type: application/octet-stream, Size: 4138 bytes --]

From 5f919f66c147c9fd4ce0a3c814480ad58479d252 Mon Sep 17 00:00:00 2001
From: Lv Zheng <lv.zheng@intel.com>
Date: Sat, 22 Oct 2016 01:41:03 +0800
From: Lv Zheng <lv.zheng@intel.com>
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 <lv.zheng@intel.com>
---
 dsinit.c   |   13 +++++--------
 dswload2.c |    2 --
 evrgnini.c |    3 +++
 nsload.c   |    2 ++
 4 files changed, 10 insertions(+), 10 deletions(-)

diff -Nurp linux.before/drivers/acpi/acpica/dsinit.c linux.after/drivers/acpi/acpica/dsinit.c
--- linux.before/drivers/acpi/acpica/dsinit.c	2016-10-22 01:50:09.496430502 +0800
+++ linux.after/drivers/acpi/acpica/dsinit.c	2016-10-22 01:50:05.976430479 +0800
@@ -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)) {
diff -Nurp linux.before/drivers/acpi/acpica/dswload2.c linux.after/drivers/acpi/acpica/dswload2.c
--- linux.before/drivers/acpi/acpica/dswload2.c	2016-10-22 01:50:09.480430502 +0800
+++ linux.after/drivers/acpi/acpica/dswload2.c	2016-10-22 01:50:05.960430479 +0800
@@ -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:
diff -Nurp linux.before/drivers/acpi/acpica/evrgnini.c linux.after/drivers/acpi/acpica/evrgnini.c
--- linux.before/drivers/acpi/acpica/evrgnini.c	2016-10-22 01:50:09.484430502 +0800
+++ linux.after/drivers/acpi/acpica/evrgnini.c	2016-10-22 01:50:05.964430479 +0800
@@ -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);
 			}
 		}
diff -Nurp linux.before/drivers/acpi/acpica/nsload.c linux.after/drivers/acpi/acpica/nsload.c
--- linux.before/drivers/acpi/acpica/nsload.c	2016-10-22 01:50:09.496430502 +0800
+++ linux.after/drivers/acpi/acpica/nsload.c	2016-10-22 01:50:05.976430479 +0800
@@ -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"));

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

[Zheng, Lv]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > [...]
> > 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.
> 
> 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.

> 
> > 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

> 
> --Imre
> 
> > 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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > [...]
> > 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.
> 
> 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.

> 
> > 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

> 
> --Imre
> 
> > 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

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

[Zheng, Lv]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > [...]
> > 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.
> 
> 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


> 
> I attached the acpidump output.
> 
> > 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
> 
> > 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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > [...]
> > 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.
> 
> 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


> 
> I attached the acpidump output.
> 
> > 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
> 
> > 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

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

[Zheng, 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

Thanks in advance.

Best regards
Lv

> From: Zheng, Lv
> Subject: RE: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> Hi, Imre
> 
> > From: Deak, Imre
> > Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> >
> > On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > > [...]
> > > 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.
> >
> > 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
> 
> 
> >
> > I attached the acpidump output.
> >
> > > 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
> >
> > > 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

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 4263 bytes --]

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

> From: Zheng, Lv
> Subject: RE: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> Hi, Imre
> 
> > From: Deak, Imre
> > Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> >
> > On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > > [...]
> > > 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.
> >
> > 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
> 
> 
> >
> > I attached the acpidump output.
> >
> > > 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
> >
> > > 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

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

[Imre Deak]

On ti, 2016-10-25 at 04:14 +0300, Zheng, Lv wrote:
> 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

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

[Zheng, Lv]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On ti, 2016-10-25 at 04:14 +0300, Zheng, Lv wrote:
> > 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.

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

Best regards
Lv

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

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Hi, Imre

> From: Deak, Imre
> Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure, AE_ALREADY_EXISTS
> 
> On ti, 2016-10-25 at 04:14 +0300, Zheng, Lv wrote:
> > 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.

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

Best regards
Lv

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

[Moore, Robert]

> -----Original Message-----
> From: Zheng, Lv
> Sent: Monday, October 24, 2016 12:36 AM
> To: Deak, Imre <imre.deak@intel.com>; Moore, Robert
> <robert.moore@intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>; linux-acpi@vger.kernel.org;
> devel@acpica.org
> Subject: RE: 4.9-rc1: [TMP_] ACPI namespace lookup failure,
> AE_ALREADY_EXISTS
> 
> Hi, Imre
> 
> > From: Deak, Imre
> > Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure,
> > AE_ALREADY_EXISTS
> >
> > On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > > [...]
> > > 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.
> >
> > 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.
[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.





> 
> 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
> 
> 
> >
> > I attached the acpidump output.
> >
> > > 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
> >
> > > 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

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

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 4356 bytes --]



> -----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
> 
> > From: Deak, Imre
> > Subject: Re: 4.9-rc1: [TMP_] ACPI namespace lookup failure,
> > AE_ALREADY_EXISTS
> >
> > On Fri, 2016-10-21 at 22:46 +0300, Zheng, Lv wrote:
> > > [...]
> > > 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.
> >
> > 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.
[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.





> 
> 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
> 
> 
> >
> > I attached the acpidump output.
> >
> > > 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
> >
> > > 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