ACPICA version 20180810 released
by Moore, Robert
10 August 2018. Summary of changes for version 20180810:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Initial ACPI table loading: Attempt to continue loading ACPI tables regardless of malformed AML. Since migrating table initialization to the new module-level code support, the AML interpreter rejected tables upon any ACPI error encountered during table load. This is a problem because non-serious ACPI errors during table load do not necessarily mean that the entire definition block (DSDT or SSDT) is invalid. This change improves the table loading by ignoring some types of errors that can be generated by incorrect AML. This can range from object type errors, scope errors, and index errors.
Suspend/Resume support: Update to stop unconditionally clearing ACPI IRQs during suspend/resume. The status of ACPI events is no longer cleared when entering the ACPI S5 system state (power off) which caused some systems to power up immediately after turning off power in certain situations. This was a functional regression. It was fixed by clearing the status of all ACPI events again when entering S5 (for system-wide suspend or hibernation the clearing of the status of all events is not desirable, as it might cause the kernel to miss wakeup events sometimes). Rafael Wysocki.
2) iASL Compiler/Disassembler and Tools:
AcpiExec: Enhanced the -fi option (Namespace initialization file). Field elements listed in the initialization file were previously initialized after the table load and before executing module-level code blocks. Recent changes in the module-level code support means that the table load becomes a large control method execution. If fields are used within module-level code and we are executing with the -fi option, the initialization values were used to initialize the namespace object(s) only after the table was finished loading. This change Provides an early initialization of objects specified in the initialization file so that field unit values are populated during the table load (not after the load).
AcpiExec: Fixed a small memory leak regression that could result in warnings during exit of the utility. These warnings were similar to these:
0002D690 Length 0x0006 nsnames-0502 [Not a Descriptor - too small]
0002CD70 Length 0x002C utcache-0453 [Operand] Integer RefCount 0x0001
4 years, 1 month
[PATCH RESEND v2] arm64: clean the additional checks before calling ghes_notify_sea()
by Dongjiu Geng
In order to remove the additional check before calling the
ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
After this cleanup, we can simply call the ghes_notify_sea() to let
APEI driver handle the SEA notification.
CC: Tyler Baicar <tbaicar(a)codeaurora.org>
CC: James Morse <james.morse(a)arm.com>
Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com>
Acked-by: Will Deacon <will.deacon(a)arm.com>
---
This cleanup is ever mentioned by Mark Rutland in [1]
[1]:
https://lkml.org/lkml/2018/5/31/289
Change since v1:
1. Update the commit messages
2. CC Tyler and James
3. Add Acked-by of Will
---
arch/arm64/mm/fault.c | 7 +------
include/acpi/ghes.h | 4 ++++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index b8eecc7..9ffe01d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -727,12 +727,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
int handle_guest_sea(phys_addr_t addr, unsigned int esr)
{
- int ret = -ENOENT;
-
- if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
- ret = ghes_notify_sea();
-
- return ret;
+ return ghes_notify_sea();
}
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 1624e2b..82cb4eb 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -118,6 +118,10 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
(void *)section - (void *)(estatus + 1) < estatus->data_length; \
section = acpi_hest_get_next(section))
+#ifdef CONFIG_ACPI_APEI_SEA
int ghes_notify_sea(void);
+#else
+static inline int ghes_notify_sea(void) { return -ENOENT; }
+#endif
#endif /* GHES_H */
--
1.9.1
4 years, 1 month
Re: [Devel] [PATCH] arm64: clean the additional checks before calling ghes_notify_sea()
by Will Deacon
On Sun, Aug 05, 2018 at 10:35:03AM +0800, gengdongjiu wrote:
> 2018-07-27 18:06 GMT+08:00 Will Deacon <will.deacon(a)arm.com>:
> > On Thu, Jul 26, 2018 at 05:01:47PM -0400, Dongjiu Geng wrote:
> >> In order to remove the additional check before calling the
> >> ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
> >>
> >> Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com>
> >> ---
> >
> > Acked-by: Will Deacon <will.deacon(a)arm.com>
>
> Will,
> This patch will be applied, right? thanks
I haven't queued it in the arm64 tree, since it touches include/acpi/ghes.h
and you don't have an ack from the acpi folks. I acked it so that you could
route it via the acpi tree without me holding you up.
Will
> >> This cleanup is ever mentioned by Mark Rutland in [1]
> >>
> >> [1]:
> >> https://lkml.org/lkml/2018/5/31/289
> >> ---
> >> arch/arm64/mm/fault.c | 7 +------
> >> include/acpi/ghes.h | 4 ++++
> >> 2 files changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> >> index b8eecc7..9ffe01d 100644
> >> --- a/arch/arm64/mm/fault.c
> >> +++ b/arch/arm64/mm/fault.c
> >> @@ -727,12 +727,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> >>
> >> int handle_guest_sea(phys_addr_t addr, unsigned int esr)
> >> {
> >> - int ret = -ENOENT;
> >> -
> >> - if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
> >> - ret = ghes_notify_sea();
> >> -
> >> - return ret;
> >> + return ghes_notify_sea();
> >> }
> >>
> >> asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
> >> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
> >> index 1624e2b..82cb4eb 100644
> >> --- a/include/acpi/ghes.h
> >> +++ b/include/acpi/ghes.h
> >> @@ -118,6 +118,10 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
> >> (void *)section - (void *)(estatus + 1) < estatus->data_length; \
> >> section = acpi_hest_get_next(section))
> >>
> >> +#ifdef CONFIG_ACPI_APEI_SEA
> >> int ghes_notify_sea(void);
> >> +#else
> >> +static inline int ghes_notify_sea(void) { return -ENOENT; }
> >> +#endif
> >>
> >> #endif /* GHES_H */
> >> --
> >> 1.9.1
> >>
4 years, 1 month
Re: [Devel] [PATCH 1/1] x86, pmem, acpi: Remove excessive ACPI Large Reference Count warnings
by Moore, Robert
> -----Original Message-----
> From: Russ Anderson [mailto:rja@hpe.com]
> Sent: Wednesday, August 1, 2018 1:38 PM
> To: Moore, Robert <robert.moore(a)intel.com>
> Cc: Mike Travis <mike.travis(a)hpe.com>; Schmauss, Erik
> <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>; Len Brown <lenb(a)kernel.org>; Russ Anderson
> <russ.anderson(a)hpe.com>; Dimitri Sivanich <dimitri.sivanich(a)hpe.com>;
> Ross Zwisler <ross.zwisler(a)linux.intel.com>; Williams, Dan J
> <dan.j.williams(a)intel.com>; Verma, Vishal L <vishal.l.verma(a)intel.com>;
> Jiang, Dave <dave.jiang(a)intel.com>; linux-acpi(a)vger.kernel.org;
> devel(a)acpica.org; linux-nvdimm(a)lists.01.org; linux-
> kernel(a)vger.kernel.org
> Subject: Re: [PATCH 1/1] x86, pmem, acpi: Remove excessive ACPI Large
> Reference Count warnings
>
> On Wed, Aug 01, 2018 at 07:49:14PM +0000, Moore, Robert wrote:
> > Are there any actual memory leaks, or this a consequence of the number
> of sockets?
>
> It is a consequence of the number of sockets.
> It is not an actual memory leak.
>
> Thanks.
>
[Moore, Robert]
It does bother me a bit that there are over 4096 references to a single object, however. Could you send us the ACPI dump for the machine?
This issue sounds vaguely familiar though. Perhaps Dan remembers, it was something about large reference counts and the NFIT/NVDIMM stuff. If so, this has been fixed for some time now.
Bob
> > > -----Original Message-----
> > > From: Mike Travis [mailto:mike.travis@hpe.com]
> > > Sent: Monday, July 30, 2018 12:56 PM
> > > To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik
> > > <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> > > <rafael.j.wysocki(a)intel.com>; Len Brown <lenb(a)kernel.org>
> > > Cc: Russ Anderson <russ.anderson(a)hpe.com>; Dimitri Sivanich
> > > <dimitri.sivanich(a)hpe.com>; Ross Zwisler
> > > <ross.zwisler(a)linux.intel.com>; Williams, Dan J
> > > <dan.j.williams(a)intel.com>; Verma, Vishal L
> > > <vishal.l.verma(a)intel.com>; Jiang, Dave <dave.jiang(a)intel.com>;
> > > linux- acpi(a)vger.kernel.org; devel(a)acpica.org;
> > > linux-nvdimm(a)lists.01.org; linux-kernel(a)vger.kernel.org
> > > Subject: [PATCH 1/1] x86, pmem, acpi: Remove excessive ACPI Large
> > > Reference Count warnings
> > >
> > > With the Intel BIOS support for 8 processor sockets with a full
> > > complement of NVDIMMS potentially installable, and there are empty
> > > sockets without NVDIMMS, there is an extremely large amount of the
> > > following warnings:
> > >
> > > ACPI Warning: Large Reference Count (0x1001) in object
> ffff99453fc71750,
> > > Type=0x0A
> > >
> > > On a 4 socket system with 4 NVDIMMs there were over 6000 of these
> > > warning messages and it has been seem on systems from 4 to 32
> sockets.
> > >
> > > Through some guidance from the BIOS developers and testing, it
> > > appears that simply bumping up the threshold for warnings from
> > > 0x1000 to 0x2000 eliminates these messages. Changing them to be
> > > ACPI DEBUG messages, or even removing them are other options, but it
> > > would then defeat the purpose of the warnings as the problem would
> effectively be hidden.
> > >
> > > Reviewed-by: Dimitri Sivanich <dimitri.sivanich(a)hpe.com>
> > > Tested-by: Russ Anderson <russ.anderson(a)hpe.com>
> > > Signed-off-by: Mike Travis <mike.travis(a)hpe.com>
> > > ---
> > > include/acpi/acconfig.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > --- linux-4.12.orig/include/acpi/acconfig.h
> > > +++ linux-4.12/include/acpi/acconfig.h
> > > @@ -123,7 +123,7 @@
> > >
> > > /* Maximum object reference count (detects object deletion issues)
> > > */
> > >
> > > -#define ACPI_MAX_REFERENCE_COUNT 0x1000
> > > +#define ACPI_MAX_REFERENCE_COUNT 0x2000
> > >
> > > /* Default page size for use in mapping memory for operation
> > > regions */
> > >
> > >
> > > --
> >
>
> --
> Russ Anderson, SuperDome Flex Linux Kernel Group Manager HPE - Hewlett
> Packard Enterprise (formerly SGI) rja(a)hpe.com
4 years, 2 months
Re: [Devel] [PATCH 1/1] x86, pmem, acpi: Remove excessive ACPI Large Reference Count warnings
by Moore, Robert
Are there any actual memory leaks, or this a consequence of the number of sockets?
> -----Original Message-----
> From: Mike Travis [mailto:mike.travis@hpe.com]
> Sent: Monday, July 30, 2018 12:56 PM
> To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik
> <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>; Len Brown <lenb(a)kernel.org>
> Cc: Russ Anderson <russ.anderson(a)hpe.com>; Dimitri Sivanich
> <dimitri.sivanich(a)hpe.com>; Ross Zwisler <ross.zwisler(a)linux.intel.com>;
> Williams, Dan J <dan.j.williams(a)intel.com>; Verma, Vishal L
> <vishal.l.verma(a)intel.com>; Jiang, Dave <dave.jiang(a)intel.com>; linux-
> acpi(a)vger.kernel.org; devel(a)acpica.org; linux-nvdimm(a)lists.01.org;
> linux-kernel(a)vger.kernel.org
> Subject: [PATCH 1/1] x86, pmem, acpi: Remove excessive ACPI Large
> Reference Count warnings
>
> With the Intel BIOS support for 8 processor sockets with a full
> complement of NVDIMMS potentially installable, and there are empty
> sockets without NVDIMMS, there is an extremely large amount of the
> following warnings:
>
> ACPI Warning: Large Reference Count (0x1001) in object ffff99453fc71750,
> Type=0x0A
>
> On a 4 socket system with 4 NVDIMMs there were over 6000 of these
> warning messages and it has been seem on systems from 4 to 32 sockets.
>
> Through some guidance from the BIOS developers and testing, it appears
> that simply bumping up the threshold for warnings from 0x1000 to 0x2000
> eliminates these messages. Changing them to be ACPI DEBUG messages, or
> even removing them are other options, but it would then defeat the
> purpose of the warnings as the problem would effectively be hidden.
>
> Reviewed-by: Dimitri Sivanich <dimitri.sivanich(a)hpe.com>
> Tested-by: Russ Anderson <russ.anderson(a)hpe.com>
> Signed-off-by: Mike Travis <mike.travis(a)hpe.com>
> ---
> include/acpi/acconfig.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-4.12.orig/include/acpi/acconfig.h
> +++ linux-4.12/include/acpi/acconfig.h
> @@ -123,7 +123,7 @@
>
> /* Maximum object reference count (detects object deletion issues) */
>
> -#define ACPI_MAX_REFERENCE_COUNT 0x1000
> +#define ACPI_MAX_REFERENCE_COUNT 0x2000
>
> /* Default page size for use in mapping memory for operation regions */
>
>
> --
4 years, 2 months
