On Fri, Apr 13, 2018 at 12:42 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > On Friday, April 13, 2018 6:54:04 AM CEST Schmauss, Erik wrote: >> >> > -----Original Message----- >> > From: Dan Williams [mailto:dan.j.williams@xxxxxxxxx] >> > Sent: Thursday, April 12, 2018 5:57 PM >> > To: Schmauss, Erik <erik.schmauss@xxxxxxxxx> >> > Cc: Linux ACPI <linux-acpi@xxxxxxxxxxxxxxx>; Rafael J. Wysocki >> > <rjw@xxxxxxxxxxxxx>; Moore, Robert <robert.moore@xxxxxxxxx>; linux-nvdimm >> > <linux-nvdimm@xxxxxxxxxxxx> >> > Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- >> > level code >> > >> > On Thu, Apr 12, 2018 at 3:50 PM, Dan Williams <dan.j.williams@xxxxxxxxx> >> > wrote: >> > > [ adding linux-nvdimm ] >> > > >> > > On Fri, Feb 16, 2018 at 7:20 AM Erik Schmauss >> > > <erik.schmauss@xxxxxxxxx> >> > > wrote: >> > > >> > >> 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 <kai.heng.feng@xxxxxxxxxxxxx> >> > >> Signed-off-by: Bob Moore <robert.moore@xxxxxxxxx> >> > >> Signed-off-by: Erik Schmauss <erik.schmauss@xxxxxxxxx> >> > > >> > > 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? >> >> > 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
