ACPICA release 20180208v2

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

---
  drivers/acpi/acpica/dspkginit.c | 128

drivers/acpi/acpica/dspkginit.c +3 -2

+
         arg = op->common.value.arg;
         arg = arg->common.next;
 
-       if (arg) {
-               obj_desc->package.flags |= AOPOBJ_DATA_VALID;
+       /*
+        * If we are executing module-level code, we will defer the

drivers/acpi/acpica/dspkginit.c +0 -1

         if (ACPI_FAILURE(status)) {
                 return_VOID;
         }
-#if 0

include/acpi/acpixf.h +6 -3

  /*
   * Optionally support group module level code.
+ * NOTE, this is essentially obsolete and will be removed soon
+ * (01/2018).
   */
-ACPI_INIT_GLOBAL(u8, acpi_gbl_group_module_level_code, TRUE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_group_module_level_code, FALSE);
 
  /*
   * Optionally support module level code by parsing the entire table as
   * a term_list. Default is FALSE, do not execute entire table until some
   * lock order issues are fixed.
+ * NOTE, this is essentially obsolete and will be removed soon
+ * (01/2018).
   */
-ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, TRUE);
 
  /*
   * Optionally use 32-bit FADT addresses if and when there is a conflict
--

2.14.3

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

[ adding linux-nvdimm ]

Quoted 50 lines · Erik Schmauss

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

Quoted 6 lines

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

Hi,

This commit 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") regresses the detection of persistent memory in my qemu-kvm setup.

-----Original Message-----
From: Dan Williams [mailto:[email protected]]
Sent: Thursday, April 12, 2018 5:57 PM
To: Schmauss, Erik <[email protected]>
Cc: Linux ACPI <[email protected]>; Rafael J. Wysocki <[email protected]>; Moore, Robert <[email protected]>; linux-nvdimm <[email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module-
level code

Quoted 69 lines · Dan Williams

[ adding linux-nvdimm ]

Quoted 50 lines · Erik Schmauss

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

Quoted 6 lines

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

Hi,

This commit 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") regresses the detection of persistent memory in my qemu-kvm setup.

With the following set of clean reverts on top of latest-Linus I'm back to a working configuration:

Revert "ACPICA: Change a compile-time option to a runtime option" Revert "ACPICA: Cleanup/simplify module-level code support" Revert "ACPICA: Rename a global for clarity, no functional change" Revert "ACPICA: Add option to disable Package object name resolution errors" Revert "ACPICA: Integrate package handling with module-level code"

...i.e.

git revert 34f206fd757c
git revert a406dea82af8
git revert e7d970f6fca8
git revert 959c38a7e128
git revert 5a8361f7ecce

Quoted 11 lines

-----Original Message-----
From: Dan Williams [mailto:[email protected]]
Sent: Thursday, April 12, 2018 5:57 PM
To: Schmauss, Erik <[email protected]>
Cc: Linux ACPI <[email protected]>; Rafael J. Wysocki <[email protected]>; Moore, Robert <[email protected]>; linux-nvdimm <[email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- level code

Quoted 72 lines

Quoted 69 lines · Dan Williams

[ adding linux-nvdimm ]

Quoted 50 lines · Erik Schmauss

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

Quoted 6 lines

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

Hi,

This commit 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") regresses the detection of persistent memory in my qemu-kvm setup.

Hi Dan,

Thanks for figuring this out. Do you think it's possible for you to send me a full acpidump or some sort hexdump of the QEMU environment?

Quoted 9 lines

With the following set of clean reverts on top of latest-Linus I'm back to a working configuration:

Revert "ACPICA: Change a compile-time option to a runtime option" Revert "ACPICA: Cleanup/simplify module-level code support" Revert "ACPICA: Rename a global for clarity, no functional change" Revert "ACPICA: Add option to disable Package object name resolution errors" Revert "ACPICA: Integrate package handling with module-level code"

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

If this is the case, I wonder if we could change the
ACPICA version number so that it is one digit lower or append something to the end of the version number. This would be helpful in reminding us that it's not the full release in ACPICA upstream. Either that or remove the ACPICA release all together for this rc..

Quoted 7 lines

...i.e.

git revert 34f206fd757c
git revert a406dea82af8
git revert e7d970f6fca8
git revert 959c38a7e128
git revert 5a8361f7ecce

Quoted 97 lines · Erik

Quoted 11 lines

-----Original Message-----
From: Dan Williams [mailto:[email protected]]
Sent: Thursday, April 12, 2018 5:57 PM
To: Schmauss, Erik <[email protected]>
Cc: Linux ACPI <[email protected]>; Rafael J. Wysocki <[email protected]>; Moore, Robert <[email protected]>; linux-nvdimm <[email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module-
level code

Quoted 72 lines

Quoted 69 lines · Dan Williams

[ adding linux-nvdimm ]

Quoted 50 lines · Erik Schmauss

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

Quoted 6 lines

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

Hi,

This commit 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") regresses the detection of persistent memory in my qemu-kvm setup.

Hi Dan,

Thanks for figuring this out. Do you think it's possible for you to send me a full acpidump or some sort hexdump of the QEMU environment?

Quoted 9 lines

With the following set of clean reverts on top of latest-Linus I'm back to a working configuration:

Revert "ACPICA: Change a compile-time option to a runtime option" Revert "ACPICA: Cleanup/simplify module-level code support" Revert "ACPICA: Rename a global for clarity, no functional change" Revert "ACPICA: Add option to disable Package object name resolution errors" Revert "ACPICA: Integrate package handling with module-level code"

Quoted 4 lines

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

Quoted 5 lines

Quoted 4 lines

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

Quoted 2 lines

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

Note, that I'm willing to try any proposed fix patches on top. I just wanted to clarify that we have a simple fallback position if the debug starts dragging out.

[ trimming ]

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

Hi Rafael,

Quoted 2 lines

Quoted 2 lines

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

This is indeed what I meant last week. However, I've looked into the issue and Dan's qemu
instance had AML that we no longer support. This is because the ACPICA commit makes changes to the execution of AML during table load to match windows AML interpreter behavior so this commit also got rid of support for executing code containing forward references (except for package elements).

I've suggested a fix for the firmware in a separate email. So I would say that this issue is resolved after if Dan can run his test successfully with the adjusted firmware.

If Dan's test is successful, we don’t need to revert these changes

-----Original Message-----
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Dan Williams
Sent: Monday, April 16, 2018 4:22 PM
To: Schmauss, Erik <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; Linux ACPI <linux- [email protected]>; Moore, Robert <[email protected]>; linux- nvdimm <[email protected]>; Qemu Developers <qemu- [email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- level code

Quoted 8 lines · Erik

[ trimming ]

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

Hi Rafael,

Quoted 7 lines

Quoted 2 lines

Quoted 2 lines

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

This is indeed what I meant last week. However, I've looked into the issue and Dan's qemu instance had AML that we no longer support. This is because the ACPICA commit makes changes to the execution of AML during table load to match windows AML interpreter behavior so this commit

also got rid of support for executing code containing forward references (except for package elements).

Quoted 3 lines

I've suggested a fix for the firmware in a separate email. So I would say that this issue is resolved after if Dan can run his test successfully with the

adjusted firmware.

Quoted 2 lines

If Dan's test is successful, we don’t need to revert these changes

I'm concerned about other qemu-kvm users that do not upgrade their hypervisor at the same pace as their guest kernel. Especially for cloud providers that may be running latest mainline kernel on older qemu-kvm this will look like a pure kernel regression. Is there a quick fix we can carry in the kernel to support these forward references, at least until we know that qemu-kvm is no longer shipping the broken AML?

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

Quoted 30 lines

-----Original Message-----
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Dan Williams
Sent: Monday, April 16, 2018 4:22 PM
To: Schmauss, Erik <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; Linux ACPI <linux- [email protected]>; Moore, Robert <[email protected]>; linux- nvdimm <[email protected]>; Qemu Developers <qemu- [email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- level code

Quoted 8 lines · Erik

[ trimming ]

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

Hi Rafael,

Quoted 7 lines

Quoted 2 lines

Quoted 2 lines

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

This is indeed what I meant last week. However, I've looked into the issue and Dan's qemu instance had AML that we no longer support. This is because the ACPICA commit makes changes to the execution of AML during table load to match windows AML interpreter behavior so this commit

Quoted 9 lines

also got rid of support for executing code containing forward references (except for package elements).

Quoted 3 lines

I've suggested a fix for the firmware in a separate email. So I would say that this issue is resolved after if Dan can run his test successfully with the

adjusted firmware.

Quoted 2 lines

If Dan's test is successful, we don’t need to revert these changes

Hi Dan,

Quoted 6 lines

I'm concerned about other qemu-kvm users that do not upgrade their hypervisor at the same pace as their guest kernel. Especially for cloud providers that may be running latest mainline kernel on older qemu-kvm this will look like a pure kernel regression. Is there a quick fix we can carry in the kernel to support these forward references, at least until we know that qemu-kvm is no longer shipping the broken AML?

This is a very good point. Thanks for bringing this up! One option is for them to set the global variable acpi_gbl_execute_tables_as_methods in include/acpi/acpixf.h to false. This will effectively revert the new behavior in the AML interpreter and go back to the old way. Since this is a global flag, we could have a command line option for Linux kernel to turn this feature on.

Out of curiosity, is this ACPI table somehow customized for your work? I have a collection of acpi tables and your ACPI tables are the only ones that have an OperationRegion called NRAM. What is the chance that others will be running Linux on the same tables as the one you sent me?

-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Friday, April 13, 2018 12:43 AM
To: Schmauss, Erik <[email protected]>
Cc: Williams, Dan J <[email protected]>; Linux ACPI <linux- [email protected]>; Moore, Robert <[email protected]>; linux- nvdimm <[email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with
module-level code

Quoted 49 lines · Erik

Quoted 49 lines

-----Original Message-----
From: Dan Williams [mailto:[email protected]]
Sent: Thursday, April 12, 2018 5:57 PM
To: Schmauss, Erik <[email protected]>
Cc: Linux ACPI <[email protected]>; Rafael J. Wysocki <[email protected]>; Moore, Robert <[email protected]>; linux-nvdimm <[email protected]>
Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with
module- level code

Quoted 35 lines · Dan Williams

[ adding linux-nvdimm ]

Quoted 28 lines · Erik Schmauss

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope.

DefinitionBlock (...)

{
   Name(OBJ1, 0)

   if (1)
   {
     Device (DEV1)
     {
       Name (_HID,0x0)
     }
   }
   Scope (DEV1)
   {
     Name (OBJ2)
   }
}

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the

scope of DEV1.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Since DEV1 is not in scope, this would incur an AE_NOT_FOUND

error.

Quoted 27 lines

Quoted 27 lines

Quoted 27 lines

Quoted 18 lines

After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace.

This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1.

Bug report links:

Link https://bugs.acpica.org/show_bug.cgi?id=963

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

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

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

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

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

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

Quoted 6 lines

ACPICA repo:

Link https://github.com/acpica/acpica/commit/8faf6fca

Tested-by Kai-Heng Feng <[email protected]>

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Erik Schmauss <[email protected]>

Hi,

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

This commit 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") regresses the detection of persistent memory in my qemu-kvm setup.

Hi Dan,

Thanks for figuring this out. Do you think it's possible for you to

send me a full acpidump or some sort hexdump of the QEMU environment?

Quoted 8 lines

Quoted 8 lines

With the following set of clean reverts on top of latest-Linus I'm back to a working configuration:

Revert "ACPICA: Change a compile-time option to a runtime option" Revert "ACPICA: Cleanup/simplify module-level code support" Revert "ACPICA: Rename a global for clarity, no functional change" Revert "ACPICA: Add option to disable Package object name

resolution errors"

Quoted 7 lines

Quoted 2 lines

Revert "ACPICA: Integrate package handling with module-level code"

Rafael, we may want to hold back on the module-level code changes (the patches below) for rc1. Between this and the strange _TSS issue, it seems like there are a few more things to resolve before this is ready for kernel upstream.

It looks like you are asking me to queue up reverts as per the Dan's report, is that correct?

Quoted 5 lines

If this is the case, I wonder if we could change the ACPICA version number so that it is one digit lower or append something to the end of the version number. This would be helpful in reminding us that it's not the full release in ACPICA upstream. Either that or remove the ACPICA release all together for this rc..

I can revert the commit updating the ACPICA version number easily enough. :-)

Quoted 9 lines

Quoted 8 lines

...i.e.

git revert 34f206fd757c
git revert a406dea82af8
git revert e7d970f6fca8
git revert 959c38a7e128
git revert 5a8361f7ecce

-----Original Message-----
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Erik Schmauss
Sent: Thursday, February 15, 2018 1:09 PM
To: [email protected]
Cc: [email protected]; Schmauss, Erik <[email protected]>
Subject: [PATCH v2 0/7] ACPICA release 20180208v2

v2 of the patch set. Apparently, a patch was left off due to issues with my mail client...

This is the ACPICA20180212 release.

Notable commits are changes made to integrate package handling with MLC and setting the TermList parsing as a default. A small commit was made to disable package resolution errors. This reverts the error reporting behavior to match the previous behavior (in 4.13)

Bob Moore (5):
ACPICA: Update error message, no functional change
ACPICA: Update for some debug output. No functional change
ACPICA: Revert "Fix for implicit result conversion for the ToXXXX
functions"
ACPICA: Add option to disable Package object name resolution errors
ACPICA: Update version to 20180209

Erik Schmauss (2):
ACPICA: Restructure ACPI table files

ACPICA: Integrate package handling with module-level code

 drivers/acpi/acpica/acopcode.h  |   14 +-
 drivers/acpi/acpica/amlcode.h   |   20 +-
 drivers/acpi/acpica/dsargs.c    |    1 +
 drivers/acpi/acpica/dsopcode.c  |    4 +-
 drivers/acpi/acpica/dspkginit.c |  164 ++--
 drivers/acpi/acpica/dswexec.c   |    6 +-
 drivers/acpi/acpica/dswload.c   |    2 +-
 drivers/acpi/acpica/exconvrt.c  |    1 +
 drivers/acpi/acpica/exnames.c   |    7 +-
 drivers/acpi/acpica/exresop.c   |    1 +
 drivers/acpi/acpica/nseval.c    |    8 +-
 drivers/acpi/acpica/nsinit.c    |    7 +-
 drivers/acpi/acpica/nsnames.c   |    3 +
 drivers/acpi/acpica/nsparse.c   |   10 +-
 drivers/acpi/acpica/psloop.c    |    4 +-
 drivers/acpi/acpica/psparse.c   |    2 +-
 drivers/acpi/acpica/pstree.c    |    1 +
 drivers/acpi/acpica/utcache.c   |    7 +-
 drivers/acpi/acpica/utdelete.c  |   20 +-
 include/acpi/acpixf.h           |   10 +-
 include/acpi/actbl1.h           | 1638 ++++++++++++++++----------------
 include/acpi/actbl2.h           | 1964 +++++++++++++++++++++------------------
 include/acpi/actbl3.h           | 1016 +++++++++-----------
 include/acpi/platform/aclinux.h |    1 +
 24 files changed, 2477 insertions(+), 2434 deletions(-)

--
2.14.3

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