RE: [PATCH] ACPICA: Clear status of all events when entering sleep states
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Sunday, August 12, 2018 3:50 AM
> To: Linux ACPI
> Cc: Paul Menzel ; Linux PM p...@vger.kernel.org>; LKML ; Schmauss, Erik
>
> Subject: [PATCH] ACPICA: Clear status of all events when entering sleep states
>
> From: Rafael J. Wysocki
>
> Commit fa85015c0d95 (ACPICA: Clear status of all events when entering
> S5) made the sleep state entry code in ACPICA clear the status of all ACPI
> events
> when entering S5 to fix a functional regression reported against commit
> 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during
> suspend/resume). However, it is reported now that the regression also affects
> system states other than S5 on some systems and causes them to wake up from
> sleep prematurely.
>
> For this reason, make the code in question clear the status of all ACPI events
> when entering all sleep states (in addition to S5) to avoid the premature
> wakeups (this may cause some wakeup events to be missed in theory, but the
> likelihood of that is small and the change here simply restores the previous
> behavior of the code).
>
> Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs
> during suspend/resume)
> Reported-by: Paul Menzel
> Tested-by: Paul Menzel
> Cc: 4.17+ # 4.17+: fa85015c0d95 ACPICA: Clear
> status ...
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/acpica/hwsleep.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpica/hwsleep.c
> =
> ==
> --- linux-pm.orig/drivers/acpi/acpica/hwsleep.c
> +++ linux-pm/drivers/acpi/acpica/hwsleep.c
> @@ -56,14 +56,9 @@ acpi_status acpi_hw_legacy_sleep(u8 slee
> if (ACPI_FAILURE(status)) {
> return_ACPI_STATUS(status);
> }
> - /*
> - * If the target sleep state is S5, clear all GPEs and fixed events too
> - */
> - if (sleep_state == ACPI_STATE_S5) {
> - status = acpi_hw_clear_acpi_status();
> - if (ACPI_FAILURE(status)) {
> - return_ACPI_STATUS(status);
> - }
> + status = acpi_hw_clear_acpi_status();
> + if (ACPI_FAILURE(status)) {
> + return_ACPI_STATUS(status);
> }
> acpi_gbl_system_awake_and_running = FALSE;
>
I'll backport this for the next ACPICA release
Thanks,
Erik
RE: [GIT PULL] ACPI fix for v4.18-rc7
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Linus Torvalds
> Sent: Friday, July 27, 2018 11:38 AM
> To: Rafael J. Wysocki
> Cc: Linux ACPI ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [GIT PULL] ACPI fix for v4.18-rc7
>
> My XPS13 laptop is unhappy with something recent.
>
> As of yesterday, I get this at bootup:
>
> ACPI: Added _OSI(Module Device)
> ACPI: Added _OSI(Processor Device)
> ACPI: Added _OSI(3.0 _SCP Extensions)
> ACPI: Added _OSI(Processor Aggregator Device)
> ACPI: Added _OSI(Linux-Dell-Video)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI Error: Result stack is empty! State=(ptrval)
> (20180531/dswstate-65)
> ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> (20180531/dsutils-612)
> ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> (20180531/dsutils-727)
> ACPI: 9 ACPI AML tables successfully acquired and loaded
>
> It does *not* happen in
>
> Linux version 4.18.0-rc6-00110-g6e77b267723c
>
> but it *does* happen in
>
> Linux version 4.18.0-rc6-00152-gcd3f77d74ac3
>
> and while I didn't bisect it, I'm assuming it's due to 73c2a01c52b6
> ("ACPICA: AML Parser: ignore dispatcher error status during table
> load")
>
> Ideas?
Sorry about the breakage. I found the cause this failure and I'm working on a
fix right now.
Erik
>
> Note only the errors are new. On older kernels, I just get:
>
> ACPI: Added _OSI(Module Device)
> ACPI: Added _OSI(Processor Device)
> ACPI: Added _OSI(3.0 _SCP Extensions)
> ACPI: Added _OSI(Processor Aggregator Device)
> ACPI: Added _OSI(Linux-Dell-Video)
> ACPI: 9 ACPI AML tables successfully acquired and loaded
>
> without the big slew of errors.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the
> body of
> a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ACPI fix for v4.18-rc7
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Schmauss, Erik
> Sent: Friday, July 27, 2018 2:51 PM
> To: Linus Torvalds ; Rafael J. Wysocki
>
> Cc: Linux ACPI ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: RE: [GIT PULL] ACPI fix for v4.18-rc7
>
>
>
> > -Original Message-
> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > ow...@vger.kernel.org] On Behalf Of Linus Torvalds
> > Sent: Friday, July 27, 2018 11:38 AM
> > To: Rafael J. Wysocki
> > Cc: Linux ACPI ; Linux Kernel Mailing List
> >
> > Subject: Re: [GIT PULL] ACPI fix for v4.18-rc7
> >
> > My XPS13 laptop is unhappy with something recent.
> >
> > As of yesterday, I get this at bootup:
> >
> > ACPI: Added _OSI(Module Device)
> > ACPI: Added _OSI(Processor Device)
> > ACPI: Added _OSI(3.0 _SCP Extensions)
> > ACPI: Added _OSI(Processor Aggregator Device)
> > ACPI: Added _OSI(Linux-Dell-Video)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI Error: Result stack is empty! State=(ptrval)
> > (20180531/dswstate-65)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand
> > (20180531/dsutils-612)
> > ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0
> > (20180531/dsutils-727)
> > ACPI: 9 ACPI AML tables successfully acquired and loaded
> >
> > It does *not* happen in
> >
> > Linux version 4.18.0-rc6-00110-g6e77b267723c
> >
> > but it *does* happen in
> >
> > Linux version 4.18.0-rc6-00152-gcd3f77d74ac3
> >
> > and while I didn't bisect it, I'm assuming it's due to 73c2a01c52b6
> > ("ACPICA: AML Parser: ignor
RE: [PATCH] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530
Hi,
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
> Sent: Tuesday, January 30, 2018 10:18 AM
> To: Kai-Heng Feng
> Cc: Rafael J. Wysocki ; Len Brown ; ACPI
> Devel Maling List ; Linux Kernel Mailing List
> ker...@vger.kernel.org>; Mario Limonciello
> Subject: Re: [PATCH] ACPI: Parse entire table as a term_list for Dell XPS
> 9570 and
> Precision M5530
>
> On Tue, Jan 30, 2018 at 8:07 AM, Kai-Heng Feng
> wrote:
> > The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
> > of box.
> >
> > The touchpad relies on its _INI method to update its _HID value from
> > to SYNA2393.
> > Also, the _STA relies on value of I2CN to report correct status.
> >
> > Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
> > correctly set up, and _INI can get run. The ACPI table in this machine
> > is designed to get parsed this way.
I thought I would give everyone an update: we are getting close to finishing
patches to enable this term list parsing by default as well as a few other
fixes with forward referencing of package elements. Once we have established
that these patches are stable, we will get rid of
acpi_gbl_parse_table_as_term_list. So this quirk may not be needed in the near
future...
Erik
> >
> > Also, change the quirk table to a more generic name.
>
> > +static int set_gbl_term_list(const struct dmi_system_id *id) {
> > + pr_notice("%s detected - parse the entire table as a term_list\n",
> > + id->ident);
> > + acpi_gbl_parse_table_as_term_list = 1;
> > + return 0;
> > +}
> > #endif
>
> The above should be outside of another #ifdef. Basically after the above
> #endif.
>
> > #else
>
> > #endif
>
> > @@ -1005,7 +1034,7 @@ void __init acpi_early_init(void)
>
> > * If the machine falls into the DMI check table,
> > * DSDT will be copied to memory
> > */
>
> It might make sense to adjust comment above that it's about quirks in general.
> And, if needed, move current content to actual DMI group of records.
>
> > - dmi_check_system(dsdt_dmi_table);
> > + dmi_check_system(acpi_quirks_dmi_table);
>
> --
> With Best Regards,
> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the
> body of
> a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4.14 044/100] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 29, 2018 7:01 AM > To: Jean Delvare > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir > ; Schmauss, Erik ; > Wysocki, Rafael J > Subject: Re: [PATCH 4.14 044/100] ACPICA: AML interpreter: add region > addresses in global list during initialization > > On Thu, Nov 29, 2018 at 03:45:26PM +0100, Jean Delvare wrote: > > Hi Greg, > > > > On Thu, 2018-11-29 at 15:12 +0100, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > know. > > > > > > -- > > > > > > From: Erik Schmauss > > > > > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. > > > > > > The table load process omitted adding the operation region address > > > range to the global list. This omission is problematic because the > > > OS queries the global list to check for address range conflicts > > > before deciding which drivers to load. This commit may result in > > > warning messages that look like the following: > > > > > > [7.871761] ACPI Warning: system_IO range 0x0428-0x042F > conflicts with op_region 0x0400-0x047F (\PMIO) > (20180531/utaddress-213) > > > [7.871769] ACPI: If an ACPI driver is available for this device, you > > > should > use it instead of the native driver > > > > > > However, these messages do not signify regressions. It is a result > > > of properly adding address ranges within the global address list. > > > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 > > > Tested-by: Jean-Marc Lenoir > > > Signed-off-by: Erik Schmauss > > > Cc: All applicable > > > Signed-off-by: Rafael J. Wysocki > > > Cc: Jean Delvare > > > Signed-off-by: Greg Kroah-Hartman > > > > I'm confused. While we were discussing the regression, Erik said that > > this is fixing commit 5a8361f7ecceaed64b4064000d16cb703462be49, which > > went upstream in v4.17. So how can the fix be needed in any kernel > > older than v4.17? Erik, did I understand you incorrectly? > Hi Greg, > The patch says "All applicable", and I assumed that meant, "as long as it > applies." > > Erik, should I drop this from 4.14.y? This should only apply to 4.17 or later. I unintentionally put all applicable so please drop this for all 4.16 or earlier. I've learned my lesson and I'll put the correct tags from now on :-) Erik > > thanks, > > greg k-h
RE: [PATCH 4.14 044/100] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Jean Delvare [mailto:jdelv...@suse.de] > Sent: Thursday, November 29, 2018 11:34 AM > To: Greg Kroah-Hartman > Cc: Schmauss, Erik ; linux- > ker...@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir > ; Wysocki, Rafael J > Subject: Re: [PATCH 4.14 044/100] ACPICA: AML interpreter: add region > addresses in global list during initialization > > On Thu, 29 Nov 2018 20:21:37 +0100, Greg Kroah-Hartman wrote: > > On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote: > > > This should only apply to 4.17 or later. I unintentionally put all > > > applicable so please drop this for all 4.16 or earlier. I've learned > > > my lesson and I'll put the correct tags from now on :-) > > > > Ok, now dropped from 4.14, thanks. > > Should be dropped from 4.9 and 4.4 too... if it was not clear. Yes, it should, Thanks, Erik > > Thanks, > -- > Jean Delvare > SUSE L3 Support
RE: [PATCH 4.14 009/222] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Sunday, November 11, 2018 2:22 PM > To: linux-kernel@vger.kernel.org > Cc: Greg Kroah-Hartman ; > sta...@vger.kernel.org; Jean-Marc Lenoir ; > Schmauss, Erik ; Wysocki, Rafael J > > Subject: [PATCH 4.14 009/222] ACPICA: AML interpreter: add region > addresses in global list during initialization > Hi Greg, > 4.14-stable review patch. If anyone has any objections, please let me know. This patch is only meant to be added for kernels that are 4.17 or later. Please drop this from kernel 4.16 or older. Thanks, Erik > > -- > > From: Erik Schmauss > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. > > The table load process omitted adding the operation region address range to > the global list. This omission is problematic because the OS queries the > global > list to check for address range conflicts before deciding which drivers to > load. > This commit may result in warning messages that look like the following: > > [7.871761] ACPI Warning: system_IO range 0x0428-0x042F > conflicts with op_region 0x0400-0x047F (\PMIO) > (20180531/utaddress-213) > [7.871769] ACPI: If an ACPI driver is available for this device, you > should use > it instead of the native driver > > However, these messages do not signify regressions. It is a result of properly > adding address ranges within the global address list. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 > Tested-by: Jean-Marc Lenoir > Signed-off-by: Erik Schmauss > Cc: All applicable > Signed-off-by: Rafael J. Wysocki > Signed-off-by: Greg Kroah-Hartman > > --- > drivers/acpi/acpica/dsopcode.c |4 > 1 file changed, 4 insertions(+) > > --- a/drivers/acpi/acpica/dsopcode.c > +++ b/drivers/acpi/acpica/dsopcode.c > @@ -451,6 +451,10 @@ acpi_ds_eval_region_operands(struct acpi > ACPI_FORMAT_UINT64(obj_desc->region.address), > obj_desc->region.length)); > > + status = acpi_ut_add_address_range(obj_desc->region.space_id, > +obj_desc->region.address, > +obj_desc->region.length, node); > + > /* Now the address and length are valid for this opregion */ > > obj_desc->region.flags |= AOPOBJ_DATA_VALID; >
RE: [PATCH 4.14 009/222] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Monday, November 12, 2018 9:47 AM > To: Schmauss, Erik > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir > ; Wysocki, Rafael J > Subject: Re: [PATCH 4.14 009/222] ACPICA: AML interpreter: add region > addresses in global list during initialization > > On Mon, Nov 12, 2018 at 05:16:19PM +, Schmauss, Erik wrote: > > > > > -Original Message- > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > > > Sent: Sunday, November 11, 2018 2:22 PM > > > To: linux-kernel@vger.kernel.org > > > Cc: Greg Kroah-Hartman ; > > > sta...@vger.kernel.org; Jean-Marc Lenoir ; > > > Schmauss, Erik ; Wysocki, Rafael J > > > > > > Subject: [PATCH 4.14 009/222] ACPICA: AML interpreter: add region > > > addresses in global list during initialization > > > > > Hi Greg, > > > > > 4.14-stable review patch. If anyone has any objections, please let me > know. > > > > This patch is only meant to be added for kernels that are 4.17 or later. > > > > Please drop this from kernel 4.16 or older. > Hi Greg, > Ok, but next time be a bit more careful when you add a line like this to the > patch: > > > > Cc: All applicable > > I take this to mean "everything it can apply cleanly to". Thanks for the information! I will be more careful in the future Erik > > I'll go drop it from the 3.18.y, 4.4.y, and 4.9.y stable queues as well. > > thanks, > > greg k-h
RE: [PATCH 4.19 025/361] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Holger Hoffstätte [mailto:hol...@applied-asynchrony.com] > Sent: Monday, November 12, 2018 10:31 AM > To: Greg Kroah-Hartman ; linux- > ker...@vger.kernel.org > Cc: sta...@vger.kernel.org; Jean-Marc Lenoir ; > Schmauss, Erik ; Wysocki, Rafael J > > Subject: Re: [PATCH 4.19 025/361] ACPICA: AML interpreter: add region > addresses in global list during initialization > > On 11/11/18 11:16 PM, Greg Kroah-Hartman wrote: > > 4.19-stable review patch. If anyone has any objections, please let me > know. > Hi, > As probably expected this patch causes problems. In my case one server can > no longer load the nct6775 hwmon module, which means the fan cannot be > monitored, and therefore my monitoring system promptly starts spamming > me with alerts that my fan has failed - which is of course not true. > > --snip-- > Nov 12 18:08:56 tux kernel: nct6775: Found NCT6776D/F or compatible chip at > 0x2e:0x290 Nov 12 18:08:56 tux kernel: ACPI Warning: SystemIO range > 0x0295-0x0296 conflicts with OpRegion > 0x0290-0x Nov 12 18:08:56 tux kernel: ACPI: If an ACPI driver is > available for this device, you should use it instead of the native driver > --snip-- > > This is certainly caused by my old BIOS and its broken ACPI implementation, > however since it's working perfectly fine otherwise I see no reason to > replace it. That being said, I must be able to monitor my fan, so for now > reverting the patch immediately "fixed" the problem for me - the fan entries > appeared in sysfs again after successfully loading the module. > > Idea, workarounds or patches welcome. Is there a firmware update available for this machine? If so, you may want to do a firmware update. Also, what is the behavior in kernels 4.16 or older? Erik > > > -- > > > > From: Erik Schmauss > > > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. > > > > The table load process omitted adding the operation region address > > range to the global list. This omission is problematic because the OS > > queries the global list to check for address range conflicts before > > deciding which drivers to load. This commit may result in warning > > messages that look like the following: > > > > [7.871761] ACPI Warning: system_IO range 0x0428-0x042F > conflicts with op_region 0x0400-0x047F (\PMIO) > (20180531/utaddress-213) > > [7.871769] ACPI: If an ACPI driver is available for this device, you > > should > use it instead of the native driver > > > > However, these messages do not signify regressions. It is a result of > > properly adding address ranges within the global address list. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 > > Tested-by: Jean-Marc Lenoir > > Signed-off-by: Erik Schmauss > > Cc: All applicable > > Signed-off-by: Rafael J. Wysocki > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > drivers/acpi/acpica/dsopcode.c |4 > > 1 file changed, 4 insertions(+) > > > > --- a/drivers/acpi/acpica/dsopcode.c > > +++ b/drivers/acpi/acpica/dsopcode.c > > @@ -417,6 +417,10 @@ acpi_ds_eval_region_operands(struct acpi > > ACPI_FORMAT_UINT64(obj_desc->region.address), > > obj_desc->region.length)); > > > > + status = acpi_ut_add_address_range(obj_desc->region.space_id, > > + obj_desc->region.address, > > + obj_desc->region.length, node); > > + > > /* Now the address and length are valid for this opregion */ > > > > obj_desc->region.flags |= AOPOBJ_DATA_VALID; > > > > > >
RE: [PATCH 4.19 025/361] ACPICA: AML interpreter: add region addresses in global list during initialization
> -Original Message- > From: Holger Hoffstätte [mailto:hol...@applied-asynchrony.com] > Sent: Monday, November 12, 2018 11:42 AM > To: Schmauss, Erik ; Greg Kroah-Hartman > ; linux-kernel@vger.kernel.org > Cc: sta...@vger.kernel.org; Jean-Marc Lenoir ; > Wysocki, Rafael J > Subject: Re: [PATCH 4.19 025/361] ACPICA: AML interpreter: add region > addresses in global list during initialization > > Hello Erik, > > thanks for responding. > > On 11/12/18 8:01 PM, Schmauss, Erik wrote: > >> As probably expected this patch causes problems. In my case one > >> server can no longer load the nct6775 hwmon module, which means the > >> fan cannot be monitored, and therefore my monitoring system promptly > >> starts spamming me with alerts that my fan has failed - which is of course > not true. > >> > >> --snip-- > >> Nov 12 18:08:56 tux kernel: nct6775: Found NCT6776D/F or compatible > >> chip at > >> 0x2e:0x290 Nov 12 18:08:56 tux kernel: ACPI Warning: SystemIO range > >> 0x0295-0x0296 conflicts with OpRegion > >> 0x0290-0x Nov 12 18:08:56 tux kernel: ACPI: If an ACPI > >> driver is available for this device, you should use it instead of the > >> native driver > >> --snip-- > >> > >> This is certainly caused by my old BIOS and its broken ACPI > >> implementation, however since it's working perfectly fine otherwise I > >> see no reason to replace it. That being said, I must be able to > >> monitor my fan, so for now reverting the patch immediately "fixed" > >> the problem for me - the fan entries appeared in sysfs again after > successfully loading the module. > >> > >> Idea, workarounds or patches welcome. > > > > Is there a firmware update available for this machine? If so, you may > > want to do a firmware update. > > The motherboard is from 2011 and I already installed the last available BIOS > from 2013 a few years ago. That fixed exactly nothing. :) This was my last > motherboard from Asus ever, but alas, it's still here and otherwise working, > so.. > > > Also, what is the behavior in kernels 4.16 or older? > Hi, > Everything just worked - yes, with ACPI spew, but.. ¯\(ツ)/¯ > I understand that the patch might well be "technically correct" and OK for > mainline/current hardware and will try playing with acpi=.. kernel flags. It's strange how the driver would load in 4.16 and fail to load with this patch. I would like to make sure that the driver load behavior is not being changed from 4.16 or earlier. Could you send a working dmesg from 4.16 (or earlier) and a failing dmesg with this stable branch using the same kernel command line parameters for both? I don't need too much of the spew if it looks the same. I'm more interested in the initializations and the warning message. Erik > > thanks, > Holger
RE: small dmesg regression in kernel 4.17.3
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Friday, June 29, 2018 2:32 AM
> To: Schmauss, Erik
> Cc: Andy Shevchenko ; Toralf Förster
> ; Moore, Robert ; ACPI
> Devel Maling List ; Linux Kernel ker...@vger.kernel.org>; Guenter Roeck
> Subject: Re: small dmesg regression in kernel 4.17.3
>
> On Friday, June 29, 2018 12:13:54 AM CEST Schmauss, Erik wrote:
> >
> > > -Original Message-
> > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > > Sent: Wednesday, June 27, 2018 10:29 AM
> > > To: Toralf Förster ; Schmauss, Erik
> > >
> > > Cc: ACPI Devel Maling List ; Linux
> > > Kernel
> > > Subject: Re: small dmesg regression in kernel 4.17.3
> > >
> > > +Cc: Erik
> > >
> > > On Tue, Jun 26, 2018 at 8:57 PM, Toralf Förster
> > >
> > > wrote:
> > > > The attached dmesg contains non printable chars 0x01 33 around
> > > > "ACPI BIOS Error (bug): Could not resolve" which is a new issue
> > > > compared to the dmesg of 4.17.2
> > > >
> > > > System is a stable hardened Gentoo Linux at a ThinkPad T440s.
> > >
> > > I bet the below commit makes this.
> > >
> > > commit 2e78935d1e27d31955ad2dad4abe6c453cf669fd
> > > Author: Erik Schmauss
> > > Date: Fri Jun 1 12:06:43 2018 -0700
> > >
> > >ACPICA: AML parser: attempt to continue loading table after error
> > >
> > >
> > Hi Andy,
> >
> > > So, it does add leading '\n' which flushes buffers followed by
> > > printing the message you see. But, I'm guessing now, kernel adds a
> > > default level since it's going to dmesg which you can see as unprintable
> symbols.
> >
> > What do you mean by a default level?
> >
> > > Personally I'm not a fan of leading '\n':s since it brings more pain
> > > than fixing something. It has special meaning (flushing buffers) and
> > > many developers forget this.
> >
> > This leading '\n' made it in Linux kernel unintentionally. It was originally
> intended as a change for acpiexec and it makes the dmesg look strange. I'll
> send
> out a fix.
>
> Which would be something like the patch below I suppose?
Yes, this is what I was thinking of
Thanks,
Erik
>
> ---
> From: Rafael J. Wysocki
> Subject: [PATCH] ACPICA: Drop leading newlines from error messages
>
> Commit 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table
> after error) unintentionally added leading newlines to error messages emitted
> by
> ACPICA which caused unexpected things to be printed to the kernel log. Drop
> these newlines (which effectively reverts the part of commit 5088814a6e93
> adding them).
>
> Fixes: 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table
> after error)
> Reported-by: Toralf Förster
> Reported-by: Guenter Roeck
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/acpica/uterror.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpica/uterror.c
> =
> ==
> --- linux-pm.orig/drivers/acpi/acpica/uterror.c
> +++ linux-pm/drivers/acpi/acpica/uterror.c
> @@ -182,19 +182,19 @@ acpi_ut_prefixed_namespace_error(const c
> switch (lookup_status) {
> case AE_ALREADY_EXISTS:
>
> - acpi_os_printf("\n" ACPI_MSG_BIOS_ERROR);
> + acpi_os_printf(ACPI_MSG_BIOS_ERROR);
> message = "Failure creating";
> break;
>
> case AE_NOT_FOUND:
>
> - acpi_os_printf("\n" ACPI_MSG_BIOS_ERROR);
> + acpi_os_printf(ACPI_MSG_BIOS_ERROR);
> message = "Could not resolve";
> break;
>
> default:
>
> - acpi_os_printf("\n" ACPI_MSG_ERROR);
> + acpi_os_printf(ACPI_MSG_ERROR);
> message = "Failure resolving";
> break;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the
> body of
> a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
RE: small dmesg regression in kernel 4.17.3
> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Wednesday, June 27, 2018 10:29 AM > To: Toralf Förster ; Schmauss, Erik > > Cc: ACPI Devel Maling List ; Linux Kernel ker...@vger.kernel.org> > Subject: Re: small dmesg regression in kernel 4.17.3 > > +Cc: Erik > > On Tue, Jun 26, 2018 at 8:57 PM, Toralf Förster > wrote: > > The attached dmesg contains non printable chars 0x01 33 around "ACPI > > BIOS Error (bug): Could not resolve" which is a new issue compared to > > the dmesg of 4.17.2 > > > > System is a stable hardened Gentoo Linux at a ThinkPad T440s. > > I bet the below commit makes this. > > commit 2e78935d1e27d31955ad2dad4abe6c453cf669fd > Author: Erik Schmauss > Date: Fri Jun 1 12:06:43 2018 -0700 > >ACPICA: AML parser: attempt to continue loading table after error > > Hi Andy, > So, it does add leading '\n' which flushes buffers followed by printing the > message you see. But, I'm guessing now, kernel adds a default level since it's > going to dmesg which you can see as unprintable symbols. What do you mean by a default level? > Personally I'm not a fan of leading '\n':s since it brings more pain than > fixing > something. It has special meaning (flushing buffers) and many developers > forget > this. This leading '\n' made it in Linux kernel unintentionally. It was originally intended as a change for acpiexec and it makes the dmesg look strange. I'll send out a fix. Thanks for reporting it, Erik > > -- > With Best Regards, > Andy Shevchenko
RE: 4.18rc3 TX2 boot failure with "ACPICA: AML parser: attempt to continue loading table after error"
> -Original Message- > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: Tuesday, July 3, 2018 12:52 AM > To: Jeremy Linton > Cc: Rafael J. Wysocki ; Schmauss, Erik > ; linux-a...@vger.kernel.org; linux- > ker...@vger.kernel.org; Rafael J . Wysocki ; linux-arm- > ker...@lists.infradead.org; Lorenzo Pieralisi > Subject: Re: 4.18rc3 TX2 boot failure with "ACPICA: AML parser: attempt to > continue loading table after error" > > On Tue, Jul 3, 2018 at 12:30 AM, Jeremy Linton > wrote: > > Hi, > > > > On 07/02/2018 04:52 PM, Rafael J. Wysocki wrote: > >> > >> On Mon, Jul 2, 2018 at 11:41 PM, Jeremy Linton > >> > >> wrote: > >>> > >>> Hi, > >>> > >>> I'm experiencing two problems with commit 5088814a6e931 which is > "ACPICA: > >>> AML parser: attempt to continue loading table after error" > >>> > >>> The first is this boot failure on a thunderX2: > >>> > >>> [ 10.770098] ACPI Error: Ignore error and continue table load > >>> (20180531/psobject-604) > >>> [ 10.777926] Unable to handle kernel NULL pointer dereference at > >>> [ 10.950199] Call trace: > >>> > >>> [ 10.952663] acpi_ps_peek_opcode+0x1c/0x40 > >>> [ 10.956797] acpi_ps_create_op+0x54/0x278 > >>> [ 10.960842] acpi_ps_parse_loop+0x1b4/0x6c8 > >>> [ 10.965063] acpi_ps_parse_aml+0xe0/0x2b4 > >>> [ 10.969108] acpi_ps_execute_table+0xa0/0x104 > >>> [ 10.973505] acpi_ns_execute_table+0x120/0x194 > >>> [ 10.977989] acpi_ns_parse_table+0x34/0x68 > >>> [ 10.982122] acpi_ns_load_table+0x4c/0xbc > >>> [ 10.986169] acpi_tb_load_namespace+0x1d4/0x240 > >>> [ 10.990744] acpi_load_tables+0x50/0xbc > >>> [ 10.994614] acpi_init+0xb8/0x374 > >>> [ 10.997959] do_one_initcall+0x54/0x208 > >>> [ 11.001829] kernel_init_freeable+0x224/0x300 > >>> [ 11.006229] kernel_init+0x18/0x118 > >>> [ 11.009747] ret_from_fork+0x10/0x18 > >>> [ 11.013354] Code: aa0003f3 aa1e03e0 d503201f f9400661 (39400020) > >>> [ 11.019535] ---[ end trace 2bd8068593cf8acc ]--- > >>> [ 11.024195] Kernel panic - not syncing: Fatal exception > >>> [ 11.029488] SMP: stopping secondary CPUs > >>> [ 11.033480] ---[ end Kernel panic - not syncing: Fatal exception > >>> ]--- > >>> > >>> Which does appear to be the result of some bad data in the table, > >>> but it was working with 4.17, and reverting this commit solves the > >>> problem. > >> > >> > >> But this commit fixes another regression which was more widespread. > >> > >> Apparently, we can't work around all of the errors in the tables out > >> there at the same time. :-/ > > > > > > NP, Let me see if I can come up with a way to harden the > > parse_loop/create_op code enough that it doesn't crash the machine. > > Sure. I'll look at it too. I it looks like there are error cases that have yet to be implemented... Jeremy, could send an ACPI dump of this thunderX2 machine? Thanks, Erik > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the > body of > a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 5/5] ACPICA: Remove PCI bits from ACPICA when CONFIG_PCI is unset
> -Original Message-
> From: Sinan Kaya [mailto:ok...@kernel.org]
> Sent: Wednesday, December 12, 2018 9:20 AM
> To: linux-a...@vger.kernel.org
> Cc: Sinan Kaya ; Moore, Robert
> ; Schmauss, Erik ;
> Wysocki, Rafael J ; Len Brown
> ; open list:ACPI COMPONENT ARCHITECTURE (ACPICA)
> ; open list
> Subject: [PATCH v6 5/5] ACPICA: Remove PCI bits from ACPICA when
> CONFIG_PCI is unset
>
> Now that we allow CONFIG_PCI to be unset, remove useless code from
> ACPICA too.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/acpi/acpica/Makefile | 2 +-
> drivers/acpi/acpica/achware.h | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile index
> b14621da5413..59700433a96e 100644
> --- a/drivers/acpi/acpica/Makefile
> +++ b/drivers/acpi/acpica/Makefile
> @@ -77,13 +77,13 @@ acpi-y += \
> hwacpi.o\
> hwesleep.o \
> hwgpe.o \
> - hwpci.o \
> hwregs.o\
> hwsleep.o \
> hwvalid.o \
> hwxface.o \
> hwxfsleep.o
>
> +acpi-$(CONFIG_PCI) += hwpci.o
> acpi-$(ACPI_FUTURE_USAGE) += hwtimer.o
>
> acpi-y +=\
> diff --git a/drivers/acpi/acpica/achware.h b/drivers/acpi/acpica/achware.h
> index 43ce67a9da1f..1c827184fe64 100644
> --- a/drivers/acpi/acpica/achware.h
> +++ b/drivers/acpi/acpica/achware.h
> @@ -109,8 +109,17 @@ acpi_hw_enable_runtime_gpe_block(struct
> acpi_gpe_xrupt_info *gpe_xrupt_info,
CONFIG_PCI is a Linux-ism. We should stay with the OS-independent nature of
ACPICA. Please use ACPI_PCI_CONFIGURED and put it above the comment like so:
#ifdef ACPI_PCI_CONFIGURED
> /*
> * hwpci - PCI configuration support
> */
> +#ifdef CONFIG_PCI
> acpi_status
> acpi_hw_derive_pci_id(struct acpi_pci_id *pci_id,
> acpi_handle root_pci_device, acpi_handle pci_region);
> +#else
> +static inline acpi_status
> +acpi_hw_derive_pci_id(struct acpi_pci_id *pci_id, acpi_handle
> root_pci_device,
> + acpi_handle pci_region)
> +{
> + return AE_SUPPORT;
> +}
> +#endif
>
> #endif /* __ACHWARE_H__ */
> --
> 2.19.0
RE: [PATCH v6 5/5] ACPICA: Remove PCI bits from ACPICA when CONFIG_PCI is unset
> -Original Message- > From: Rafael J. Wysocki [mailto:raf...@kernel.org] > Sent: Wednesday, December 12, 2018 1:07 PM > To: ok...@kernel.org; Schmauss, Erik > Cc: ACPI Devel Maling List ; Moore, Robert > ; Wysocki, Rafael J ; > Len Brown ; de...@acpica.org; Linux Kernel Mailing List > > Subject: Re: [PATCH v6 5/5] ACPICA: Remove PCI bits from ACPICA when > CONFIG_PCI is unset > > On Wed, Dec 12, 2018 at 8:34 PM Sinan Kaya wrote: > > > > On 12/12/2018 2:02 PM, Schmauss, Erik wrote: > > >> ++ b/drivers/acpi/acpica/achware.h > > >> @@ -109,8 +109,17 @@ acpi_hw_enable_runtime_gpe_block(struct > > >> acpi_gpe_xrupt_info *gpe_xrupt_info, > > > CONFIG_PCI is a Linux-ism. We should stay with the OS-independent > > > nature of ACPICA. Please use ACPI_PCI_CONFIGURED and put it above > the comment like so: > > > > > > #ifdef ACPI_PCI_CONFIGURED > > > > Thanks for the feedback. My search for ACPI_PCI_CONFIGURED returned > nothing. > > > > git grep ACPI_PCI_CONFIGURED > > > > @Rafael, > > > > How do you want to handle this? > > I think what Eric suggested is effectively to introduce a new ACPICA symbol. > Erik? Yes, that's correct and you can add something like #ifdef CONFIG_PCI #define ACPI_PCI_CONFIGURED #endif in include/linux/platform/aclinux.h to enable it.
RE: [PATCHv2 01/12] acpi: Create subtable parsing infrastructure
> -Original Message- > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: Tuesday, December 11, 2018 1:45 AM > To: Busch, Keith > Cc: Linux Kernel Mailing List ; ACPI Devel > Maling List ; Linux Memory Management List > ; Greg Kroah-Hartman > ; Rafael J. Wysocki ; > Hansen, Dave ; Williams, Dan J > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing infrastructure > > On Tue, Dec 11, 2018 at 2:05 AM Keith Busch > wrote: > > Hi Rafael and Bob, > > Parsing entries in an ACPI table had assumed a generic header > > structure that is most common. There is no standard ACPI header, > > though, so less common types would need custom parsers if they want go > > through their sub-table entry list. > > It looks like the problem at hand is that acpi_hmat_structure is incompatible > with acpi_subtable_header because of the different layout and field sizes. Just out of curiosity, why don't we use ACPICA code to parse static ACPI tables in Linux? We have a disassembler for static tables that parses all supported tables. This seems like a duplication of code/effort... Erik > > If so, please state that clearly here. > > With that, please feel free to add > > Reviewed-by: Rafael J. Wysocki > > to this patch.
RE: [PATCHv2 01/12] acpi: Create subtable parsing infrastructure
> -Original Message- > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Dan Williams > Sent: Wednesday, December 19, 2018 4:00 PM > To: Schmauss, Erik > Cc: Rafael J. Wysocki ; Busch, Keith > ; Moore, Robert ; > Linux Kernel Mailing List ; ACPI Devel > Maling List ; Linux Memory Management > List ; Greg Kroah-Hartman > ; Hansen, Dave > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing > infrastructure > > On Wed, Dec 19, 2018 at 3:19 PM Schmauss, Erik > wrote: > > > > > > > > > -Original Message- > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > > > Sent: Tuesday, December 11, 2018 1:45 AM > > > To: Busch, Keith > > > Cc: Linux Kernel Mailing List ; ACPI > > > Devel Maling List ; Linux Memory > > > Management List ; Greg Kroah-Hartman > > > ; Rafael J. Wysocki > ; > > > Hansen, Dave ; Williams, Dan J > > > > > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing > > > infrastructure > > > > > > On Tue, Dec 11, 2018 at 2:05 AM Keith Busch > > > > wrote: > > > > > > > > Hi Rafael and Bob, > > > > > > Parsing entries in an ACPI table had assumed a generic header > > > > structure that is most common. There is no standard ACPI > header, > > > > though, so less common types would need custom parsers if they > > > > want go through their sub-table entry list. > > > > > > It looks like the problem at hand is that acpi_hmat_structure is > > > incompatible with acpi_subtable_header because of the different > layout and field sizes. > > > > Just out of curiosity, why don't we use ACPICA code to parse static > > ACPI tables in Linux? > > > > We have a disassembler for static tables that parses all supported > > tables. This seems like a duplication of code/effort... > Hi Dan, > Oh, I thought acpi_table_parse_entries() was the common code. > What's the ACPICA duplicate? I was thinking AcpiDmDumpTable(). After looking at this ACPICA code, I realized that the this ACPICA doesn't actually build a parse tree or data structure. It loops over the data structure to format the input ACPI table to a file. To me, it seems like a good idea for Linux and ACPICA to share the same code when parsing and analyzing these structures. I know that Linux may emit warnings that are specific to Linux but there are structural analyses that should be the same (such as checking lengths of tables and subtables so that we don't have out of bounds access). Erik
RE: [PATCHv2 01/12] acpi: Create subtable parsing infrastructure
> -Original Message- > From: Rafael J. Wysocki [mailto:raf...@kernel.org] > Sent: Thursday, December 20, 2018 12:57 AM > To: Schmauss, Erik > Cc: Williams, Dan J ; Rafael J. Wysocki > ; Busch, Keith ; Moore, > Robert ; Linux Kernel Mailing List ker...@vger.kernel.org>; ACPI Devel Maling List a...@vger.kernel.org>; Linux Memory Management List m...@kvack.org>; Greg Kroah-Hartman > ; Hansen, Dave > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing > infrastructure > > On Thu, Dec 20, 2018 at 2:15 AM Schmauss, Erik > wrote: > > > > > > > > > -Original Message- > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > ow...@vger.kernel.org] On Behalf Of Dan Williams > > > Sent: Wednesday, December 19, 2018 4:00 PM > > > To: Schmauss, Erik > > > Cc: Rafael J. Wysocki ; Busch, Keith > > > ; Moore, Robert > ; > > > Linux Kernel Mailing List ; ACPI > Devel > > > Maling List ; Linux Memory > Management > > > List ; Greg Kroah-Hartman > > > ; Hansen, Dave > > > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing > > > infrastructure > > > > > > On Wed, Dec 19, 2018 at 3:19 PM Schmauss, Erik > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > > > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > > > > > Sent: Tuesday, December 11, 2018 1:45 AM > > > > > To: Busch, Keith > > > > > Cc: Linux Kernel Mailing List ; > > > > > ACPI Devel Maling List ; Linux > > > > > Memory Management List ; Greg > Kroah-Hartman > > > > > ; Rafael J. Wysocki > > > ; > > > > > Hansen, Dave ; Williams, Dan J > > > > > > > > > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing > > > > > infrastructure > > > > > > > > > > On Tue, Dec 11, 2018 at 2:05 AM Keith Busch > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Rafael and Bob, > > > > > > > > > > Parsing entries in an ACPI table had assumed a generic header > > > > > > structure that is most common. There is no standard ACPI > > > header, > > > > > > though, so less common types would need custom parsers if > they > > > > > > want go through their sub-table entry list. > > > > > > > > > > It looks like the problem at hand is that acpi_hmat_structure is > > > > > incompatible with acpi_subtable_header because of the > different > > > layout and field sizes. > > > > > > > > Just out of curiosity, why don't we use ACPICA code to parse > > > > static ACPI tables in Linux? > > > > > > > > We have a disassembler for static tables that parses all supported > > > > tables. This seems like a duplication of code/effort... > > > > > Hi Dan, > > > > > Oh, I thought acpi_table_parse_entries() was the common code. > > > What's the ACPICA duplicate? > > > > I was thinking AcpiDmDumpTable(). After looking at this ACPICA > code, I > > realized that the this ACPICA doesn't actually build a parse tree or > data structure. > > It loops over the data structure to format the input ACPI table to a > file. > > > > To me, it seems like a good idea for Linux and ACPICA to share the > > same code when parsing and analyzing these structures. I know that > > Linux may emit warnings that are specific to Linux but there are > > structural analyses that should be the same (such as checking lengths > of tables and subtables so that we don't have out of bounds access). > > I agree. > > I guess the reason why it has not been done this way was because > nobody thought about it. :-) > > So a project to consolidate these things might be a good one. Ok, I'll talk to Bob about it and see what we can do
RE: [PATCH] ACPICA: Clear status of all events when entering S5
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Sunday, July 8, 2018 2:10 AM
> To: Linux ACPI
> Cc: Thomas Hänig ; Takashi Iwai ;
> Schmauss, Erik ; Linux PM p...@vger.kernel.org>; Linux Kernel Mailing List
>
> Subject: [PATCH] ACPICA: Clear status of all events when entering S5
>
> From: Rafael J. Wysocki
>
> After commit 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI
> IRQs during suspend/resume) the status of ACPI events is not cleared any more
> when entering the ACPI S5 system state (power
> off) which causes some systems to power up immediately after turing off power
> in certain situations.
>
> That is a functional regression, so address it by making the code clear 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).
>
> Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs
> during suspend/resume)
> Reported-by: Takashi Iwai
> Tested-by: Thomas Hänig
> Signed-off-by: Rafael J. Wysocki
> ---
>
> Resend https://patchwork.kernel.org/patch/10511451/ with a changelig and
> tags.
>
> ---
> drivers/acpi/acpica/hwsleep.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpica/hwsleep.c
> =
> ==
> --- linux-pm.orig/drivers/acpi/acpica/hwsleep.c
> +++ linux-pm/drivers/acpi/acpica/hwsleep.c
> @@ -51,16 +51,23 @@ acpi_status acpi_hw_legacy_sleep(u8 slee
> return_ACPI_STATUS(status);
> }
>
> - /*
> - * 1) Disable all GPEs
> - * 2) Enable all wakeup GPEs
> - */
> + /* Disable all GPEs */
> status = acpi_hw_disable_all_gpes();
> if (ACPI_FAILURE(status)) {
> return_ACPI_STATUS(status);
> }
> + /*
> + * If the target sleep state is S5, clear all GPEs and fixed events too
> + */
> + if (sleep_state == ACPI_STATE_S5) {
> + status = acpi_hw_clear_acpi_status();
> + if (ACPI_FAILURE(status)) {
> + return_ACPI_STATUS(status);
> + }
> + }
> acpi_gbl_system_awake_and_running = FALSE;
>
> + /* Enable all wakeup GPEs */
> status = acpi_hw_enable_all_wakeup_gpes();
> if (ACPI_FAILURE(status)) {
> return_ACPI_STATUS(status);
Rafael, I've created an ACPICA pull request containing this patch.
Thanks,
Erik
RE: [RFC 1/3] ACPICA: ACPI 6.3: Add MADT/GICC/SPE extension.
> -Original Message-
> From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
> Sent: Friday, February 8, 2019 4:47 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> de...@acpica.org; catalin.mari...@arm.com; will.dea...@arm.com;
> mark.rutl...@arm.com; Moore, Robert ;
> Schmauss, Erik ; Wysocki, Rafael J
> ; l...@kernel.org; Jeremy Linton
>
> Subject: [RFC 1/3] ACPICA: ACPI 6.3: Add MADT/GICC/SPE extension.
>
Hi Jeremy,
> [Placeholder patch for upstream ACPICA commit]
FYI: we are planning on releasing ACPICA patches by the end of this week at the
latest.
Erik
>
> Add just ACPI 6.3 changes associated with the arm64 SPE.
>
> Signed-off-by: Jeremy Linton
> ---
> include/acpi/actbl2.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> c50ef7e6b942..4b58eb6cf64e 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -623,7 +623,7 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3]; /* reserved - must be zero */
> };
>
> -/* 11: Generic Interrupt (ACPI 5.0 + ACPI 6.0 changes) */
> +/* 11: Generic Interrupt (ACPI 5.0 + 6.0 + 6.3 changes) */
>
> struct acpi_madt_generic_interrupt {
> struct acpi_subtable_header header;
> @@ -641,7 +641,8 @@ struct acpi_madt_generic_interrupt {
> u64 gicr_base_address;
> u64 arm_mpidr;
> u8 efficiency_class;
> - u8 reserved2[3];
> + u8 reserved2;
> + u16 spe_overflow_interrupt;
> };
>
> /* Masks for Flags field above */
> --
> 2.17.2
RE: Parsing PXM from ACPI (DSDT)
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Duran, Leo
> Sent: Wednesday, August 14, 2019 2:30 PM
> To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Rafael J. Wysocki ; Len Brown
> Subject: Parsing PXM from ACPI (DSDT)
>
Hi Leo,
> Hello,
> Is not clear or evident to me if the kernel parses _PXM values below (or
> under)
> the root-complex.
Build with CONFIG_ACPI_DEBUG=y and boot with acpi.debug_layer=0x
acpi.debug_level=0x8
This will print all of the AcpiEvaluateObject queries to the dmesg.
>
> For example, in my experience:
> This ASL sample for PXM at the root-complex level produces the expected
> NUMA assignment from “lstopo”:
> Scope (\_SB) {
> // ...
> Device (PCI0) { // Root PCI Bus (Host-Bridge)
> Name (_HID, EISAID("PNP0A08"))
> Name (_CID, EISAID("PNP0A03"))
> Name (_BBN, 0)
> Method (_CRS,0) {
> // Return current resources for host bridge 0
> }
> Name (_PRT, Package() {
> // Package with PCI IRQ routing table information
> })
> Method (_PXM, 0, NotSerialized) {
> Return (0)
> }
> }
> // ...
> }
>
> However,
> This ASL sample for PXM at the P2P root-bridge level does not produce the
> expected NUMA assignment from “lstopo”:
> (Of course, the assumption is that multiple NUMA nodes actually exist on the
> system)
>
> Scope (\_SB) {
> // ...
> Device (PCI0) { // Root PCI Bus (Host-Bridge)
> Name (_HID, EISAID ("PNP0A08"))
> Name (_CID, EISAID ("PNP0A03"))
> Name (_BBN, 0)
> Method (_CRS,0) {
> // Return current resources for host bridge 0
> }
> Name (_PRT, Package() {
> // Package with PCI IRQ routing table information
> })
>
> Device (P2P0) { // First PCI-to-PCI bridge (Port0)
> Name (_ADR, 0x00070001) // Device#7h, Func#1 on bus PCI0
> Name (_PRT, Package() {
> // Package with PCI IRQ routing table information
> })
> Method (_PXM, 0, NotSerialized) {
> Return (0)
> }
> }
>
> Device (P2P1) { // Second PCI-to-PCI bridge (Port1)
> Name (_ADR ,0x00080001) // Device#8h, Func#1 on bus PCI0
> Name (_PRT, Package() {
> // Package with PCI IRQ routing table information
> })
> Method (_PXM, 0, NotSerialized) {
> Return (1)
> }
> }
> }
> // ...
> }
>
> Thanks,
> Leo.
RE: [PATCH] ACPICA: make acpi_load_table() return table index
> -Original Message-
> From: Ferry Toth
> Sent: Thursday, September 12, 2019 12:37 PM
> To: Moore, Robert ; Nikolaus Voss
> ; Shevchenko, Andriy
> ; Schmauss, Erik ;
> Rafael J. Wysocki
> Cc: Len Brown ; Jacek Anaszewski
> ; Pavel Machek ; Dan Murphy
> ; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org; n...@vosn.de
> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index
>
> Op 12-09-19 om 16:19 schreef Moore, Robert:
> > Nikolaus,
> > The ability to unload an ACPI table (especially AML tables such as SSDTs)
> > is in
> the process of being deprecated in ACPICA -- since it is also deprecated in
> the
> current ACPI specification. This is being done because of the difficulty of
> deleting the namespace entries for the table. FYI, Windows does not properly
> support this function either.
>
> I really hope this is not the case. On x86 loading/unloading SSDTs has proven
> to
> be a powerful way to handle reconfigurable hardware without rebooting and
> without requiring dedicated platform drivers. Same for user plugable hardware
> on i2c/spi busses.
>
> This has worked before and will violate the "don't break user space" rule.
If the table index wasn't being used, how did this work before?
Which commit broke this?
Bob and I are trying to understand if this is a regression or a new feature
request...
Thanks,
Erik
>
> I don't see why Windows is an example to follow. On Windows platform drivers
> don't get compiled into the kernel and don't need to be upstreamed.
>
> > Bob
> >
> >
> > -----Original Message-
> > From: Nikolaus Voss [mailto:nikolaus.v...@loewensteinmedical.de]
> > Sent: Thursday, September 12, 2019 1:08 AM
> > To: Shevchenko, Andriy ; Schmauss, Erik
> > ; Rafael J. Wysocki ;
> > Moore, Robert
> > Cc: Len Brown ; Jacek Anaszewski
> > ; Pavel Machek ; Dan Murphy
> > ; linux-a...@vger.kernel.org; de...@acpica.org;
> > linux-kernel@vger.kernel.org; n...@vosn.de; Nikolaus Voss
> >
> > Subject: [PATCH] ACPICA: make acpi_load_table() return table index
> >
> > For unloading an ACPI table, it is necessary to provide the index of the
> > table.
> The method intended for dynamically loading or hotplug addition of tables,
> acpi_load_table(), should provide this information via an optional pointer to
> the loaded table index.
> >
> > This patch fixes the table unload function of acpi_configfs.
> >
> > Reported-by: Andy Shevchenko
> > Fixes: d06c47e3dd07f ("ACPI: configfs: Resolve objects on
> > host-directed table loads")
> > Signed-off-by: Nikolaus Voss
> > ---
> > drivers/acpi/acpi_configfs.c | 2 +-
> > drivers/acpi/acpica/dbfileio.c | 2 +-
> > drivers/acpi/acpica/tbxfload.c | 8 ++--
> > drivers/firmware/efi/efi.c | 2 +-
> > include/acpi/acpixf.h | 3 ++-
> > 5 files changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_configfs.c
> > b/drivers/acpi/acpi_configfs.c index 57d9d574d4dde..77f81242a28e6
> > 100644
> > --- a/drivers/acpi/acpi_configfs.c
> > +++ b/drivers/acpi/acpi_configfs.c
> > @@ -53,7 +53,7 @@ static ssize_t acpi_table_aml_write(struct config_item
> *cfg,
> > if (!table->header)
> > return -ENOMEM;
> >
> > - ret = acpi_load_table(table->header);
> > + ret = acpi_load_table(table->header, &table->index);
> > if (ret) {
> > kfree(table->header);
> > table->header = NULL;
> > diff --git a/drivers/acpi/acpica/dbfileio.c
> > b/drivers/acpi/acpica/dbfileio.c index c6e25734dc5cd..e1b6e54a96ac1
> > 100644
> > --- a/drivers/acpi/acpica/dbfileio.c
> > +++ b/drivers/acpi/acpica/dbfileio.c
> > @@ -93,7 +93,7 @@ acpi_status acpi_db_load_tables(struct
> acpi_new_table_desc *list_head)
> > while (table_list_head) {
> > table = table_list_head->table;
> >
> > - status = acpi_load_table(table);
> > + status = acpi_load_table(table, NULL);
> > if (ACPI_FAILURE(status)) {
> > if (status == AE_ALREADY_EXISTS) {
> > acpi_os_printf
> > diff --git a/drivers/acpi/acpica/tbxfload.c
> > b/drivers/acpi/acpica/tbxfload.c index 86f1693f6d29a..d08cd8ffcbdb6
> > 100644
> > --- a/drivers/acpi/acpica/tbxfload.c
> > +++ b/drivers/acpi/acpica/tbxfload.c
> > @@ -268,7 +268,8 @@ ACPI_EXPORT_SYMBOL_INIT(acpi
RE: [PATCH] ACPICA: make acpi_load_table() return table index
> -Original Message-
> From: Nikolaus Voss
> Sent: Thursday, September 12, 2019 1:08 AM
> To: Shevchenko, Andriy ; Schmauss, Erik
> ; Rafael J. Wysocki ; Moore,
> Robert
> Cc: Len Brown ; Jacek Anaszewski
> ; Pavel Machek ; Dan Murphy
> ; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org; n...@vosn.de; Nikolaus Voss
>
> Subject: [PATCH] ACPICA: make acpi_load_table() return table index
>
Hi Nikolaus,
> For unloading an ACPI table, it is necessary to provide the index of the
> table.
> The method intended for dynamically loading or hotplug addition of tables,
> acpi_load_table(), should provide this information via an optional pointer to
> the loaded table index.
We'll take this patch for ACPICA upstream
Thanks,
Erik
>
> This patch fixes the table unload function of acpi_configfs.
>
> Reported-by: Andy Shevchenko
> Fixes: d06c47e3dd07f ("ACPI: configfs: Resolve objects on host-directed table
> loads")
> Signed-off-by: Nikolaus Voss
> ---
> drivers/acpi/acpi_configfs.c | 2 +-
> drivers/acpi/acpica/dbfileio.c | 2 +-
> drivers/acpi/acpica/tbxfload.c | 8 ++--
> drivers/firmware/efi/efi.c | 2 +-
> include/acpi/acpixf.h | 3 ++-
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c index
> 57d9d574d4dde..77f81242a28e6 100644
> --- a/drivers/acpi/acpi_configfs.c
> +++ b/drivers/acpi/acpi_configfs.c
> @@ -53,7 +53,7 @@ static ssize_t acpi_table_aml_write(struct config_item
> *cfg,
> if (!table->header)
> return -ENOMEM;
>
> - ret = acpi_load_table(table->header);
> + ret = acpi_load_table(table->header, &table->index);
> if (ret) {
> kfree(table->header);
> table->header = NULL;
> diff --git a/drivers/acpi/acpica/dbfileio.c b/drivers/acpi/acpica/dbfileio.c
> index
> c6e25734dc5cd..e1b6e54a96ac1 100644
> --- a/drivers/acpi/acpica/dbfileio.c
> +++ b/drivers/acpi/acpica/dbfileio.c
> @@ -93,7 +93,7 @@ acpi_status acpi_db_load_tables(struct
> acpi_new_table_desc *list_head)
> while (table_list_head) {
> table = table_list_head->table;
>
> - status = acpi_load_table(table);
> + status = acpi_load_table(table, NULL);
> if (ACPI_FAILURE(status)) {
> if (status == AE_ALREADY_EXISTS) {
> acpi_os_printf
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index
> 86f1693f6d29a..d08cd8ffcbdb6 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -268,7 +268,8 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
> *
> * PARAMETERS: table - Pointer to a buffer containing the ACPI
> *table to be loaded.
> - *
> + * table_idx - Pointer to a u32 for storing the table
> + *index, might be NULL
> * RETURN: Status
> *
> * DESCRIPTION: Dynamically load an ACPI table from the caller's buffer. Must
> @@ -278,7 +279,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
> * to ensure that the table is not deleted or unmapped.
> *
>
> ***
> ***/
> -acpi_status acpi_load_table(struct acpi_table_header *table)
> +acpi_status acpi_load_table(struct acpi_table_header *table, u32
> +*table_idx)
> {
> acpi_status status;
> u32 table_index;
> @@ -297,6 +298,9 @@ acpi_status acpi_load_table(struct acpi_table_header
> *table)
> status =
> acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
>
> ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
> FALSE, &table_index);
> + if (table_idx)
> + *table_idx = table_index;
> +
> if (ACPI_SUCCESS(status)) {
>
> /* Complete the initialization/resolution of new objects */ diff
> --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index
> ad3b1f4866b35..9773e4212baef 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -308,7 +308,7 @@ static __init int efivar_ssdt_load(void)
> goto free_data;
> }
>
> - ret = acpi_load_table(data);
> + ret = acpi_load_table(data, NULL);
> if (ret) {
> pr_err("failed to load table: %d\n", ret);
> goto free_data;
> diff --git a/include/
RE: [PATCH] ACPICA: make acpi_load_table() return table index
> -Original Message- > From: linux-acpi-ow...@vger.kernel.org > On Behalf Of Shevchenko, Andriy > Sent: Thursday, September 26, 2019 9:35 AM > To: Schmauss, Erik > Cc: Nikolaus Voss ; Rafael J. Wysocki > ; Moore, Robert ; Len Brown > ; Jacek Anaszewski ; Pavel > Machek ; Dan Murphy ; linux- > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; > n...@vosn.de > Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index > > On Thu, Sep 26, 2019 at 07:09:05PM +0300, Schmauss, Erik wrote: > > > -Original Message- > > > From: Nikolaus Voss > > > Sent: Thursday, September 12, 2019 1:08 AM > > > To: Shevchenko, Andriy ; Schmauss, Erik > > > ; Rafael J. Wysocki ; > > > Moore, Robert > > > Cc: Len Brown ; Jacek Anaszewski > > > ; Pavel Machek ; Dan > > > Murphy ; linux-a...@vger.kernel.org; > > > de...@acpica.org; linux- ker...@vger.kernel.org; n...@vosn.de; > > > Nikolaus Voss > > > Subject: [PATCH] ACPICA: make acpi_load_table() return table index > > > > > Hi Nikolaus, > > > > > For unloading an ACPI table, it is necessary to provide the index of the > > > table. > > > The method intended for dynamically loading or hotplug addition of > > > tables, acpi_load_table(), should provide this information via an > > > optional pointer to the loaded table index. > > > > We'll take this patch for ACPICA upstream > > Erik, > Hi Andy, > how about to have also counterpart to acpi_load_table() which will do what > it's > done now in acpi_configfs.c via acpi_tb_*() API? I should have given more details. We decided to add this extra parameter in AcpiLoadTable and we're going to create an AcpiUnloadTable function that will take table index to unload the table (basically the acpi_tb_unload..). Once we do this, you can use table indices with AcpiUnloadTable and AcpiLoadTable. Erik > > Because it's kinda strange to call acpi_load_table*() and acpi_tb_*() in the > same module. > > -- > With Best Regards, > Andy Shevchenko >
RE: [PATCH] ACPICA: make acpi_load_table() return table index
> -Original Message- > From: Rafael J. Wysocki > Sent: Thursday, September 26, 2019 12:26 PM > To: Nikolaus Voss > Cc: Schmauss, Erik ; Shevchenko, Andriy > ; Rafael J. Wysocki ; > Moore, Robert ; Len Brown ; > Jacek Anaszewski ; Pavel Machek > ; Dan Murphy ; linux-a...@vger.kernel.org; > de...@acpica.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index > > On Thu, Sep 26, 2019 at 8:44 PM Nikolaus Voss wrote: > > > > On Thu, 26 Sep 2019, Schmauss, Erik wrote: > > >> -Original Message- > > >> From: linux-acpi-ow...@vger.kernel.org > > >> > > >> On Behalf Of Shevchenko, Andriy > > >> Sent: Thursday, September 26, 2019 9:35 AM > > >> To: Schmauss, Erik > > >> Cc: Nikolaus Voss ; Rafael J. > > >> Wysocki ; Moore, Robert > > >> ; Len Brown ; Jacek > > >> Anaszewski ; Pavel Machek > > >> ; Dan Murphy ; linux- > > >> a...@vger.kernel.org; de...@acpica.org; > > >> linux-kernel@vger.kernel.org; n...@vosn.de > > >> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table > > >> index > > >> > > >> On Thu, Sep 26, 2019 at 07:09:05PM +0300, Schmauss, Erik wrote: > > >>>> -Original Message- > > >>>> From: Nikolaus Voss > > >>>> Sent: Thursday, September 12, 2019 1:08 AM > > >>>> To: Shevchenko, Andriy ; Schmauss, > > >>>> Erik ; Rafael J. Wysocki > > >>>> ; Moore, Robert > > >>>> Cc: Len Brown ; Jacek Anaszewski > > >>>> ; Pavel Machek ; Dan > > >>>> Murphy ; linux-a...@vger.kernel.org; > > >>>> de...@acpica.org; linux- ker...@vger.kernel.org; n...@vosn.de; > > >>>> Nikolaus Voss > > >>>> Subject: [PATCH] ACPICA: make acpi_load_table() return table > > >>>> index > > >>>> > > >>> Hi Nikolaus, > > >>> > > >>>> For unloading an ACPI table, it is necessary to provide the index of > > >>>> the > table. > > >>>> The method intended for dynamically loading or hotplug addition > > >>>> of tables, acpi_load_table(), should provide this information via > > >>>> an optional pointer to the loaded table index. > > >>> > > >>> We'll take this patch for ACPICA upstream > > >> > > >> Erik, > > >> > > > Hi Andy, > > > > > >> how about to have also counterpart to acpi_load_table() which will > > >> do what it's done now in acpi_configfs.c via acpi_tb_*() API? > > > > > > I should have given more details. We decided to add this extra > > > parameter in AcpiLoadTable and we're going to create an > > > AcpiUnloadTable function that will take table index to unload the > > > table (basically the acpi_tb_unload..). Once we do this, you can use > > > table indices with AcpiUnloadTable and AcpiLoadTable. > > > > that's even better news. > > > > Rafael, shall I prepare anything? Hi everyone, > I don't think so. I'm expecting to get a proper fix from the upstream through > the normal process. Just so that we are on the same page: I've backported Nikolaus's patch for upstream here https://github.com/acpica/acpica/pull/506 and Bob has implemented the new API here: https://github.com/acpica/acpica/commit/c69369cd9cf0134e1aac516e97d612947daa8dc2 Once we do a release, I will send Bob's change to the linux ACPI mailing list. Feel free to use this new API where you see fit. Thanks, Erik > > Thanks, > Rafael
RE: [LKP] [ACPICA] 4c1379d7bb: reaim.jobs_per_min -2.8% regression
> -Original Message-
> From: Chen, Rong A
> Sent: Sunday, February 17, 2019 5:36 PM
> To: Moore, Robert
> Cc: Wysocki, Rafael J ; Schmauss, Erik
> ; LKML ; Linus
> Torvalds ; l...@01.org
> Subject: [LKP] [ACPICA] 4c1379d7bb: reaim.jobs_per_min -2.8% regression
>
> Greeting,
>
> FYI, we noticed a -2.8% regression of reaim.jobs_per_min due to commit:
>
>
> commit: 4c1379d7bb42fa664e0784539208ed74108c53f1 ("ACPICA: Debug
> output: Add option to display method/object evaluation")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
Hi,
Does the performance get back to normal when you apply the following changes?
I've added this as an attachment as well...
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index f59b4d944f7f..b524b4273d9f 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -552,9 +552,11 @@ acpi_ds_call_control_method(struct acpi_thread_state
*thread,
" Begin nested execution of [%4.4s]
WalkState=%p\n",
method_node->name.ascii, next_walk_state));
+#if 0
this_walk_state->method_pathname =
acpi_ns_get_normalized_pathname(method_node, TRUE);
this_walk_state->method_is_nested = TRUE;
+#endif
/* Optional object evaluation log */
diff --git a/drivers/acpi/acpica/psparse.c b/drivers/acpi/acpica/psparse.c
index 9b386530ffbe..c39db1a83222 100644
--- a/drivers/acpi/acpica/psparse.c
+++ b/drivers/acpi/acpica/psparse.c
@@ -483,6 +483,7 @@ acpi_status acpi_ps_parse_aml(struct acpi_walk_state
*walk_state)
/* Optional object evaluation log */
+#if 0
ACPI_DEBUG_PRINT_RAW((ACPI_DB_EVALUATION,
"%-26s: %*s%s\n",
" Exit nested method",
@@ -492,6 +493,7 @@ acpi_status acpi_ps_parse_aml(struct acpi_walk_state
*walk_state)
&walk_state->method_pathname[1]));
ACPI_FREE(walk_state->method_pathname);
+#endif
walk_state->method_is_nested = FALSE;
}
if (status == AE_CTRL_TRANSFER) {
>
> in testcase: ftq
> on test machine: 256 threads Phi with 96G memory with following
> parameters:
>
> nr_task: 100%
> samples: 6000ss
> test: cache
> freq: 20
> cpufreq_governor: performance
>
> test-description: The FTQ benchmarks measure hardware and software
> interference or 'noise' on a node from the applications perspective.
> test-url: https://github.com/rminnich/ftq
>
> In addition to that, the commit also has significant impact on the following
> tests:
>
> +--+
> ---+
> | testcase: change | perf_test:
> perf_test.msr_test.round1.cpu_util_zero.pass -100.0% undefined |
> | test machine | 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
> with 128G memory |
> | test parameters | type=lkp
> |
> | | ucode=0x3d
> |
> +--+
> ---+
>
>
> Details are as below:
> --
> >
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> ==
> ===
> compiler/cpufreq_governor/kconfig/nr_job/nr_task/rootfs/runtime/tbox_g
> roup/test/testcase/ucode:
> gcc-7/performance/x86_64-rhel-7.2/1500/100%/debian-x86_64-2018-04-
> 03.cgz/300s/lkp-hsw-ep2/all_utime/reaim/0x3d
>
> commit:
> 73a049a90f ("ACPICA: disassembler: disassemble OEMx tables as AML")
> 4c1379d7bb ("ACPICA: Debug output: Add option to display method/object
> evaluation")
>
> 73a049a90fb241af 4c1379d7bb42fa664e07845392
> --
> %stddev %change %stddev
> \ |\
> 0.07 ± 3% +20.2% 0.09 ± 12% reaim.child_systime
> 308866-2.8% 300200reaim.jobs_per_min
> 4289-2.8% 4169reaim.jobs_per_min_child
> 314258
RE: [PATCH 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=oldmap
> -Original Message-
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Tuesday, January 15, 2019 12:42 AM
> To: Kairui Song
> Cc: linux-kernel@vger.kernel.org; t...@linutronix.de;
> mi...@redhat.com; b...@alien8.de; h...@zytor.com; x...@kernel.org;
> a...@linux-foundation.org; Moore, Robert
> ; Schmauss, Erik
> ; Wysocki, Rafael J
> ; l...@kernel.org
> Subject: Re: [PATCH 2/2] x86, kexec_file_load: make it work with
> efi=noruntime or efi=oldmap
>
> On 01/09/19 at 02:47pm, Kairui Song wrote:
> > When efi=noruntime or efi=oldmap is used, EFI services won't be
> > available in the second kernel, therefore the second kernel will not
> > be able to get the ACPI RSDP address from firmware by calling EFI
> > services and won't boot. Previously we are expecting the user to set
> > the acpi_rsdp= on kernel command line for second kernel as
> there
> > was no way to pass RSDP address to second kernel.
> >
> > After commit e6e094e053af ('x86/acpi, x86/boot: Take RSDP address
> from
> > boot params if available'), now it's possible to set a acpi_rsdp_addr
> > parameter in the boot_params passed to second kernel, this commit
> make
> > use of it, detect and set the RSDP address when it's required for
> > second kernel to boot.
> >
> > Tested with an EFI enabled KVM VM with efi=noruntime.
> >
> > Suggested-by: Dave Young
> > Signed-off-by: Kairui Song
> > ---
> > arch/x86/kernel/kexec-bzimage64.c | 21 +
> > drivers/acpi/acpica/tbxfroot.c| 3 +--
> > include/acpi/acpixf.h | 2 +-
> > 3 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c
> > index 53917a3ebf94..0a90dcbd041f 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -255,8 +256,28 @@ setup_boot_parameters(struct kimage
> *image, struct boot_params *params,
> > /* Setup EFI state */
> > setup_efi_state(params, params_load_addr, efi_map_offset,
> efi_map_sz,
> > efi_setup_data_offset);
> > +
> > +#ifdef CONFIG_ACPI
> > + /* Setup ACPI RSDP pointer in case EFI is not available in
> second kernel */
> > + if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES)
> || efi_enabled(EFI_OLD_MEMMAP))) {
> > + /* Copied from acpi_os_get_root_pointer accordingly
> */
> > + params->acpi_rsdp_addr =
> boot_params.acpi_rsdp_addr;
> > + if (!params->acpi_rsdp_addr) {
> > + if (efi_enabled(EFI_CONFIG_TABLES)) {
> > + if (efi.acpi20 !=
> EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr =
> efi.acpi20;
> > + else if (efi.acpi !=
> EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr =
> efi.acpi;
> > + } else if
> (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > + acpi_find_root_pointer(¶ms-
> >acpi_rsdp_addr);
> > + }
> > + }
> > + if (!params->acpi_rsdp_addr)
> > + pr_warn("RSDP is not available for second
> kernel\n");
> > + }
> > #endif
> >
> > +#endif
> > /* Setup EDD info */
> > memcpy(params->eddbuf, boot_params.eddbuf,
> > EDDMAXNR * sizeof(struct edd_info));
> diff --git
> > a/drivers/acpi/acpica/tbxfroot.c b/drivers/acpi/acpica/tbxfroot.c
> > index 483d0ce5180a..dac1e34a931c 100644
> > --- a/drivers/acpi/acpica/tbxfroot.c
> > +++ b/drivers/acpi/acpica/tbxfroot.c
> > @@ -108,8 +108,7 @@ acpi_status acpi_tb_validate_rsdp(struct
> acpi_table_rsdp *rsdp)
> > *
> >
> >
> **
>
> > /
> >
> > -acpi_status ACPI_INIT_FUNCTION
> > -acpi_find_root_pointer(acpi_physical_address *table_address)
> > +acpi_status acpi_find_root_pointer(acpi_physical_address
> > +*table_address)
> > {
> > u8 *table_ptr;
> > u8 *mem_rover;
> > diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index
> > 7aa38b648564..869d75ecaf7d 100644
> > --- a/include/acpi/acpixf.h
> > +++ b/inclu
RE: [PATCH] ACPICA: acpica: Fix possible NULL pointer dereference in acpi_ut_remove_reference
> -Original Message-
> From: YueHaibing [mailto:yuehaib...@huawei.com]
> Sent: Wednesday, May 8, 2019 8:07 AM
> To: Moore, Robert ; Schmauss, Erik
> ; Wysocki, Rafael J ;
> l...@kernel.org
> Cc: linux-kernel@vger.kernel.org; de...@acpica.org; linux-
> a...@vger.kernel.org; YueHaibing
> Subject: [PATCH] ACPICA: acpica: Fix possible NULL pointer dereference in
> acpi_ut_remove_reference
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page PGD 0 P4D 0
> Oops: [#1
> CPU: 0 PID: 7393 Comm: modprobe Not tainted 5.1.0+ #34 Hardware name:
> QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-
> prebuilt.qemu-project.org 04/01/2014
> RIP: 0010:acpi_ut_update_object_reference+0xda/0x1e8
> Code: 4c 89 e7 eb ea 48 8b 7b 18 48 85 ff 0f 84 95 00 00 00 4c 8b 67 38 44
> 89 ee
> e8 dd fb ff ff 4c 89 e7 eb e6 48 8b 43 18 44 89 e2 <48> 8b 3c d0 48 85 ff 75
> 0b 41
> ff c4 44 3b 63 2c 72 e7 eb 66 8a 47
> RSP: 0018:c90001c9f550 EFLAGS: 00010283
> RAX: RBX: 8882310d7288 RCX:
> RDX: RSI: 0001 RDI: 8882310d7288
> RBP: c90001c9f580 R08: R09:
> R10: 0001 R11: 3ef29b78 R12:
> R13: 0001 R14: 88823122e000 R15:
> FS: 7f4469ead540() GS:888237a0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 00022c2b5000 CR4: 06f0 Call
> Trace:
> acpi_ut_remove_reference+0x29/0x2c
> acpi_ut_copy_iobject_to_iobject+0xd7/0xee
> acpi_ds_store_object_to_local+0x9a/0x181
> acpi_ex_store+0x233/0x279
> ? acpi_ds_create_operands+0x74/0xdb
> acpi_ex_opcode_1A_1T_1R+0x3c3/0x4fc
> acpi_ds_exec_end_op+0xd1/0x419
> acpi_ps_parse_loop+0x532/0x5d0
> acpi_ps_parse_aml+0x93/0x2c8
> acpi_ps_execute_method+0x16d/0x1b2
> acpi_ns_evaluate+0x1c1/0x26c
> acpi_ut_evaluate_object+0x7d/0x1a4
> acpi_rs_get_prt_method_data+0x30/0x66
> acpi_get_irq_routing_table+0x3d/0x56
> acpi_pci_irq_find_prt_entry+0x8d/0x300
> ? trace_hardirqs_on+0x3f/0x110
> acpi_pci_irq_lookup+0x35/0x1f0
> acpi_pci_irq_enable+0x72/0x1e0
> ? pci_read_config_word+0x2e/0x30
> pcibios_enable_device+0x2e/0x40
> do_pci_enable_device+0x5c/0x100
> pci_enable_device_flags+0xe0/0x130
> pci_enable_device+0xe/0x10
> e1000_probe+0xd2/0xfc0 [e1000
> ? trace_hardirqs_on+0x3f/0x110
> local_pci_probe+0x41/0x90
> pci_device_probe+0x14c/0x1b0
> really_probe+0x1d4/0x2d0
> driver_probe_device+0x50/0xf0
> device_driver_attach+0x54/0x60
> __driver_attach+0x7e/0xd0
> ? device_driver_attach+0x60/0x60
> bus_for_each_dev+0x68/0xc0
> driver_attach+0x19/0x20
> bus_add_driver+0x15e/0x200
> driver_register+0x5b/0xf0
> __pci_register_driver+0x66/0x70
> ? 0xa0179000
> e1000_init_module+0x50/0x1000 [e1000
> ? 0xa0179000
> do_one_initcall+0x6c/0x3cc
> ? do_init_module+0x22/0x207
> ? rcu_read_lock_sched_held+0x97/0xb0
> ? kmem_cache_alloc_trace+0x325/0x3b0
> do_init_module+0x5b/0x207
> load_module+0x1e34/0x2560
> ? m_show+0x1d0/0x1d0
> __do_sys_finit_module+0xc5/0xd0
> __x64_sys_finit_module+0x15/0x20
> do_syscall_64+0x6b/0x1d0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> In acpi_ut_copy_iobject_to_iobject, if
> acpi_ut_copy_ipackage_to_ipackage failed with AE_NO_MEMORY,
> acpi_ut_remove_reference will be called and in which calls
> acpi_ut_update_object_reference, then it try to dereference 'object-
> >package.elements[i]'
> which trigger NULL pointer dereference.
>
> Reported-by: Hulk Robot
> Fixes: 8aa5e56eeb61 ("ACPICA: Utilities: Fix memory leak in
> acpi_ut_copy_iobject_to_iobject")
> Signed-off-by: YueHaibing
> ---
> drivers/acpi/acpica/utcopy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/utcopy.c b/drivers/acpi/acpica/utcopy.c index
> 1fb8327..038d518 100644
> --- a/drivers/acpi/acpica/utcopy.c
> +++ b/drivers/acpi/acpica/utcopy.c
> @@ -895,7 +895,6 @@
>
> dest_obj->common.type = source_obj->common.type;
> dest_obj->common.flags = source_obj->common.flags;
> - dest_obj->package.count = source_obj->package.count;
>
> /*
>* Create the object array and walk the source package tree @@ -
> 909,6 +908,8 @@
> return_ACPI_STATUS(AE_NO_MEMORY);
> }
>
> + dest_obj->package.count = source_obj->package.count;
> +
> /*
>* Copy the package element-by-element by walking the package
> "tree".
>* This handles nested packages of arbitrary depth.
> --
> 1.8.3.1
>
Please provide the acpidump as well as the dmesg
Thanks,
Erik
RE: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set
> -Original Message-
> From: Gabriel C [mailto:nix.or@gmail.com]
> Sent: Tuesday, May 7, 2019 2:33 AM
> To: Rafael J. Wysocki
> Cc: ACPI Devel Maling List ; LKML ker...@vger.kernel.org>; Schmauss, Erik
> Subject: Re: [Kernel 5.1] ACPI_DEBUG messages without
> CONFIG_ACPI_DEBUG being set
>
> Am Di., 7. Mai 2019 um 10:35 Uhr schrieb Rafael J. Wysocki
> :
> >
> > On Tue, May 7, 2019 at 9:31 AM Gabriel C wrote:
> > >
> > > Am Di., 7. Mai 2019 um 09:01 Uhr schrieb Rafael J. Wysocki
> :
> > > >
> > > Hello Rafael , Erik
> > >
> > > > +Erik
> > > >
> > > > On Tue, May 7, 2019 at 1:33 AM Gabriel C
> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > while testing kernel-5.1 I get on one of my Lenovo Laptops very
> > > > > strange 'ACPI Debug:' messages.
> > > > >
> > > > > After some grepping I realized these are Debug messages from
> > > > > DSDT , however my kernel does not have ACPI_DEBUG enabled.
> > > > >
> > > > > I found out the module triggering this, on this Laptop is
> > > > > ideapad_laptop , but looking at the code I cannot see what would
> > > > > causes that.
> > > > >
> > > > > Also on the same Laptop with any 5.0.X kernels I cannot see these.
> > > > >
> > > > >
> > > > > ~$ grep -i ACPI_DEBUG /boot/config-5.1-fw1 #
> > > > > CONFIG_ACPI_DEBUGGER is not set # CONFIG_ACPI_DEBUG is not
> set #
> > > > > CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set #
> > > > > CONFIG_THINKPAD_ACPI_DEBUG is not set
> > > > >
> > > > > .. dmesg ..
> > > > > ...
> > > > > [ 68.020812] calling ideapad_acpi_driver_init+0x0/0x1000
> > > > > [ideapad_laptop] @ 1322
> > > > > [ 68.026708] input: Ideapad extra buttons as
> > > > >
> /devices/pci:00/:00:1f.0/PNP0C09:00/VPC2004:00/input/input16
> > > > > [ 68.038236] ACPI Debug: "=QUERY_64="
> > > > > [ 68.050232] ACPI Debug: "=QUERY_65="
> > > > > [ 68.060218] ACPI Debug: "=QUERY_64="
> > > > > [ 68.092216] probe of VPC2004:00 returned 1 after 71386 usecs
> > > > > [ 68.092245] initcall ideapad_acpi_driver_init+0x0/0x1000
> > > > > [ideapad_laptop] returned 0 after 69751 usecssg
> > > > >
> > > > > ...
> > > > >
> > > > > These =QUERY_XX= messages are from DSDT:
> > > > >
> > > > > ~/acpi$ grep QUERY dsdt.dsl
> > > > >Debug = "=QUERY_11="
> > > > >Debug = "=QUERY_12="
> > > > >Debug = "=QUERY_24="
> > > > >Debug = "=QUERY_25="
> > > > >Debug = "=QUERY_37="
> > > > >Debug = "=QUERY_38="
> > > > >Debug = "=QUERY_64="
> > > > >Debug = "=QUERY_65="
> > > > >
> > > > > Also this is the code from DSDT for QUERY 64 and 65:
> > > > >
> > > > > ...
> > > > > Method (_Q64, 0, NotSerialized) // _Qxx: EC Query
> > > > >{
> > > > >Debug = "=QUERY_64="
> > > > >If ((OSYS == 0x07D9))
> > > > >{
> > > > >If (((WLEX == One) & (WLAT == One)))
> > > > >{
> > > > >SGOV (0x02040005, One)
> > > > >}
> > > > >Else
> > > > >{
> > > > >SGOV (0x02040005, Zero)
> > > > >}
> > > > >}
> > > > >}
> > > > >
> > > > >Method (_Q65, 0, NotSerialized) // _Qxx: EC Query
> > > > >{
> > > > >Debug = "=QUERY_65="
> > > > >If ((OSYS == 0x07D9))
> > > > >
RE: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set
> -Original Message- > From: Gabriel C [mailto:nix.or@gmail.com] > Sent: Tuesday, May 7, 2019 12:06 PM > To: Schmauss, Erik > Cc: Rafael J. Wysocki ; ACPI Devel Maling List a...@vger.kernel.org>; LKML ; Moore, > Robert > Subject: Re: [Kernel 5.1] ACPI_DEBUG messages without > CONFIG_ACPI_DEBUG being set > > Am Di., 7. Mai 2019 um 20:46 Uhr schrieb Schmauss, Erik > : > > > > > > > > > -Original Message- > > > From: Gabriel C [mailto:nix.or@gmail.com] > > > Sent: Tuesday, May 7, 2019 2:33 AM > > > To: Rafael J. Wysocki > > > Cc: ACPI Devel Maling List ; LKML > > > ; Schmauss, Erik > > > > > > Subject: Re: [Kernel 5.1] ACPI_DEBUG messages without > > > CONFIG_ACPI_DEBUG being set > > > > > > Am Di., 7. Mai 2019 um 10:35 Uhr schrieb Rafael J. Wysocki > > > : > > > > > > > > On Tue, May 7, 2019 at 9:31 AM Gabriel C > wrote: > > > > > > > > > > Am Di., 7. Mai 2019 um 09:01 Uhr schrieb Rafael J. Wysocki > > > : > > > > > > > > > > > Hello Rafael , Erik > > > > > > > > > > > +Erik > > > > > > > > > > > > On Tue, May 7, 2019 at 1:33 AM Gabriel C > > > > > > > > > wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > while testing kernel-5.1 I get on one of my Lenovo Laptops > > > > > > > very strange 'ACPI Debug:' messages. > > > > > > > > > > > > > > After some grepping I realized these are Debug messages from > > > > > > > DSDT , however my kernel does not have ACPI_DEBUG enabled. > > > > > > > > > > > > > > I found out the module triggering this, on this Laptop is > > > > > > > ideapad_laptop , but looking at the code I cannot see what > > > > > > > would causes that. > > > > > > > > > > > > > > Also on the same Laptop with any 5.0.X kernels I cannot see these. > > > > > > > > > > > > > > > > > > > > > ~$ grep -i ACPI_DEBUG /boot/config-5.1-fw1 # > > > > > > > CONFIG_ACPI_DEBUGGER is not set # CONFIG_ACPI_DEBUG is > not > > > set # > > > > > > > CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set # > > > > > > > CONFIG_THINKPAD_ACPI_DEBUG is not set > > > > > > > > > > > > > > .. dmesg .. > > > > > > > ... > > > > > > > [ 68.020812] calling ideapad_acpi_driver_init+0x0/0x1000 > > > > > > > [ideapad_laptop] @ 1322 > > > > > > > [ 68.026708] input: Ideapad extra buttons as > > > > > > > > > > /devices/pci:00/:00:1f.0/PNP0C09:00/VPC2004:00/input/input16 > > > > > > > [ 68.038236] ACPI Debug: "=QUERY_64=" > > > > > > > [ 68.050232] ACPI Debug: "=QUERY_65=" > > > > > > > [ 68.060218] ACPI Debug: "=QUERY_64=" > > > > > > > [ 68.092216] probe of VPC2004:00 returned 1 after 71386 usecs > > > > > > > [ 68.092245] initcall ideapad_acpi_driver_init+0x0/0x1000 > > > > > > > [ideapad_laptop] returned 0 after 69751 usecssg > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > These =QUERY_XX= messages are from DSDT: > > > > > > > > > > > > > > ~/acpi$ grep QUERY dsdt.dsl > > > > > > >Debug = "=QUERY_11=" > > > > > > >Debug = "=QUERY_12=" > > > > > > >Debug = "=QUERY_24=" > > > > > > >Debug = "=QUERY_25=" > > > > > > >Debug = "=QUERY_37=" > > > > > > >Debug = "=QUERY_38=" > > > > > > >Debug = "=QUERY_64=" > > > > > > >Debug = "=QUERY_65=" > > > > > > > > > > > > > > Also this is the code from DSDT for QUERY 64 and 65: > >
RE: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings
> -Original Message- > From: Qian Cai [mailto:c...@lca.pw] > Sent: Thursday, August 1, 2019 12:16 PM > To: Moore, Robert ; Wysocki, Rafael J > > Cc: Schmauss, Erik ; j...@freebsd.org; > l...@kernel.org; ndesaulni...@google.com; linux-a...@vger.kernel.org; > de...@acpica.org; clang-built-li...@googlegroups.com; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings > > On Fri, 2019-07-26 at 19:35 +, Moore, Robert wrote: > > We've taken the change to ACPI_TO_POINTER. > > I am a bit confused here. I saw the commit in the acpia repo. > > https://github.com/acpica/acpica/commit/02bbca5070e42d298c9b824300aa0 > eb8a082d797 > > but how does that change will go into the linux kernel? Suppose Rafael will > need to pick it up manually? I do that after every ACPICA release Erik > > > > > > > -Original Message- > > From: Qian Cai [mailto:c...@lca.pw] > > Sent: Thursday, July 18, 2019 12:49 PM > > To: Wysocki, Rafael J > > Cc: Moore, Robert ; Schmauss, Erik > > ; j...@freebsd.org; l...@kernel.org; > > ndesaulni...@google.com; linux-acpi @vger.kernel.org; > > de...@acpica.org; clang-built-li...@googlegroups.com; linux- > > ker...@vger.kernel.org; Qian Cai > > Subject: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings > > > > Clang generate quite a few of those warnings. > > > > drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer > > treated as a cast from integer to pointer is a GNU extension > > [-Wnull-pointer- > arithmetic] > > status = acpi_get_handle(ACPI_ROOT_OBJECT, > > obj->string.pointer, > > ^~~~ > > ./include/acpi/actypes.h:458:56: note: expanded from macro > 'ACPI_ROOT_OBJECT' > > #define ACPI_ROOT_OBJECT((acpi_handle) > > ACPI_TO_POINTER > > (ACPI_MAX_PTR)) > > ^~~ > > ./include/acpi/actypes.h:509:41: note: expanded from macro > 'ACPI_TO_POINTER' > > #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) > > 0, > > (acpi_size) (i)) > > > > ^~~ > > ./include/acpi/actypes.h:503:84: note: expanded from macro 'ACPI_ADD_PTR' > > #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, > > (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) > > ^ > > ./include/acpi/actypes.h:501:66: note: expanded from macro > 'ACPI_CAST_PTR' > > #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) > > ^ > > This is because pointer arithmetic on a pointer not pointing to an > > array is an undefined behavior (C11 6.5.6, constraint 8). Fix it by > > just casting the corresponding pointers using ACPI_CAST_PTR() and skip > > the arithmetic. Also, fix a checkpatch warning together. > > > > ERROR: Macros with complex values should be enclosed in parentheses > > #45: FILE: include/acpi/actypes.h:509: > > +#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i) > > > > Signed-off-by: Qian Cai > > --- > > > > v2: Use ACPI_CAST_PTR() in ACPI_TO_POINTER() directly without > > arithmetic. > > > > include/acpi/actypes.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index > > ad6892a24015..163181e2d884 100644 > > --- a/include/acpi/actypes.h > > +++ b/include/acpi/actypes.h > > @@ -506,7 +506,7 @@ typedef u64 acpi_integer; > > > > /* Pointer/Integer type conversions */ > > > > -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) > > 0, > > (acpi_size) (i)) > > +#define ACPI_TO_POINTER(i) (ACPI_CAST_PTR (void, i)) > > #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0) > > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) > > 0)->f), (void > > *) 0) > > #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i) > > -- > > 2.20.1 (Apple Git-117) > >
RE: [Patch] ACPICA: Increase AE_OWNER_ID_LIMIT to 2047
> -Original Message- > From: Hedi Berriche [mailto:hedi.berri...@hpe.com] > Sent: Thursday, May 30, 2019 10:45 AM > To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Hedi Berriche ; Russ Anderson > ; Mike Travis ; Frank Ramsay > ; Moore, Robert ; > Schmauss, Erik ; Wysocki, Rafael J > > Subject: [Patch] ACPICA: Increase AE_OWNER_ID_LIMIT to 2047 > > 32 sockets systems with 192 NVDIMMs run into the ACPI_OWNER_ID_MAX > limit which is currently set to 255, and nfit kernel module initialisation > fails > with the following representative error messages: > > ACPI Error: Could not allocate new OwnerId (255 max), AE_OWNER_ID_LIMIT > (20170303/utownerid-149 ACPI Error: Method parse/execution failed > [\_SB.NVDR.N031.PCDR] (Node 9e2fffd8e280), AE_OWNER_ID_LIMIT > (20170303/psparse-543) ACPI Error: Method parse/execution failed > [\_SB.NVDR.N031.CR05] (Node 9547ffd91bb8), AE_OWNER_ID_LIMIT > (20170303/psparse-543) ACPI Error: Method parse/execution failed > [\_SB.NVDR.N031.CRLD] (Node 8e99ffd92550), AE_OWNER_ID_LIMIT > (20170303/psparse-543) ACPI Error: Method parse/execution failed > [\_SB.NVDR.N031._DSM] (Node adc5ffd90e88), AE_OWNER_ID_LIMIT > (20170303/psparse-543) > ACPI: \_SB_.NVDR.N031: failed to evaluate _DSM (0x1b) > Hi, > Further debugging shows that, on such a system, we end up using 1020 > owner IDs, hence I'm suggesting that we bump ACPI_OWNER_ID_MAX up to > 2047. Owner ID's increment for each ACPI table and for each control method invocation (and decreases after the method exits). How are you using 1020 owner ID's? How many nested control methods does \_SB_.NVDR.N031._DSM invoke? How many SSDT's does this machine have? More comments below. > > Signed-off-by: Hedi Berriche > Cc: Russ Anderson > Cc: Mike Travis > Cc: Frank Ramsay > Cc: Robert Moore > Cc: Erik Schmauss > Cc: Rafael J. Wysocki > --- > drivers/acpi/acpica/utownerid.c | 6 +++--- > include/acpi/acconfig.h | 4 ++-- > include/acpi/actypes.h | 4 ++-- > 3 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/acpi/acpica/utownerid.c > b/drivers/acpi/acpica/utownerid.c index 5eb8b76ce9d8..c015a2c147d9 > 100644 > --- a/drivers/acpi/acpica/utownerid.c > +++ b/drivers/acpi/acpica/utownerid.c > @@ -88,7 +88,7 @@ acpi_status acpi_ut_allocate_owner_id(acpi_owner_id > *owner_id) > /* >* Construct encoded ID from the index and > bit position >* > - * Note: Last [j].k (bit 255) is never used and > is marked > + * Note: Last [j].k (bit 2047) is never used and > is marked >* permanently allocated (prevents +1 > overflow) >*/ > *owner_id = > @@ -116,7 +116,7 @@ acpi_status > acpi_ut_allocate_owner_id(acpi_owner_id *owner_id) >*/ > status = AE_OWNER_ID_LIMIT; > ACPI_ERROR((AE_INFO, > - "Could not allocate new OwnerId (255 max), > AE_OWNER_ID_LIMIT")); > + "Could not allocate new OwnerId (2047 max), > AE_OWNER_ID_LIMIT")); > > exit: > (void)acpi_ut_release_mutex(ACPI_MTX_CACHES); > @@ -133,7 +133,7 @@ acpi_status > acpi_ut_allocate_owner_id(acpi_owner_id *owner_id) > * control method or unloading a table. Either way, we would > * ignore any error anyway. > * > - * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 - 255 > + * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 - > + 2047 > * > > ** > / > > diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index > 16a83959e616..536fe9a81cb7 100644 > --- a/include/acpi/acconfig.h > +++ b/include/acpi/acconfig.h > @@ -95,9 +95,9 @@ > > #define ACPI_DEFAULT_PAGE_SIZE 4096 /* Must be power of 2 */ > > -/* owner_id tracking. 8 entries allows for 255 owner_ids */ > +/* owner_id tracking. 64 entries allow for 2047 owner_ids */ > > -#define ACPI_NUM_OWNERID_MASKS 8 > +#define ACPI_NUM_OWNERID_MASKS 64 > > /* Size of the root table array is increased by this increment */ > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index > ad6892a24015..f32a4d49ea13 100644 > --- a/include/acpi/actypes.h > +++ b/include/acpi/actypes.h > @@ -442,8 +442,8 @@ typedef void *acpi_handle;/* Actually a ptr to a > NS Node */ > > /* Owner I
RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long
> -Original Message- > From: alexander.le...@verizon.com [mailto:alexander.le...@verizon.com] > Sent: Wednesday, November 15, 2017 8:39 AM > To: Moore, Robert > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Wysocki, Rafael J > ; Schmauss, Erik > Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid > resource if buffer length too long > > On Wed, Nov 15, 2017 at 03:39:22PM +, Moore, Robert wrote: > >> -Original Message- > >> From: alexander.le...@verizon.com > >> [mailto:alexander.le...@verizon.com] > >> Sent: Tuesday, November 14, 2017 6:46 PM > >> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org > >> Cc: Moore, Robert ; Zheng, Lv > >> ; Wysocki, Rafael J ; > >> alexander.le...@verizon.com > >> Subject: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid > >> resource if buffer length too long > >> > >> From: Bob Moore > >> > >> [ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ] > >> > >> ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 > >> ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a > >> ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e > >> > >> The declared buffer length must be the same as the length of the byte > >> initializer list, otherwise not a valid resource descriptor. > [snip] > > >[Moore, Robert] > > > >Please explain what you are doing here. > > Proposing this commit for the 4.9 LTS tree. What problem are you trying to solve with this change? Are you seeing ACPI errors? If so what are they? > > -- > > Thanks, > Sasha
RE: [PATCH] ACPICA: Fix indentation
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael
> J. Wysocki
> Sent: Friday, December 8, 2017 9:06 AM
> To: Vasyl Gomonovych
> Cc: Moore, Robert ; Zheng, Lv
> ; Wysocki, Rafael J ; Len
> Brown ; ACPI Devel Maling List ;
> de...@acpica.org; Linux Kernel Mailing List ;
> Schmauss, Erik
> Subject: Re: [PATCH] ACPICA: Fix indentation
>
> On Fri, Dec 8, 2017 at 5:29 PM, Vasyl Gomonovych
> wrote:
> > This patch avoids that smatch reports the following:
> > drivers/acpi/acpica/exdump.c:623 acpi_ex_dump_operand() warn:
> > inconsistent indenting
> >
> > Signed-off-by: Vasyl Gomonovych
>
> This is ACPICA code, so changes like this should go in via the upstream.
>
Hi,
> Erik may want to pick this up, however.
>
Thanks for pointing this out. I found solution to fix the indentation issue.
It will be in the next release.
Erik
> > ---
> > drivers/acpi/acpica/exdump.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/exdump.c
> > b/drivers/acpi/acpica/exdump.c index 83398dc..f43d3d7 100644
> > --- a/drivers/acpi/acpica/exdump.c
> > +++ b/drivers/acpi/acpica/exdump.c
> > @@ -619,8 +619,8 @@ void acpi_ex_dump_operand(union
> > acpi_operand_object *obj_desc, u32 depth)
> >
> > ACPI_FUNCTION_NAME(ex_dump_operand)
> >
> > - /* Check if debug output enabled */
> > - if (!ACPI_IS_DEBUG_ENABLED(ACPI_LV_EXEC, _COMPONENT)) {
> > + /* Check if debug output enabled */
> > + if (!ACPI_IS_DEBUG_ENABLED(ACPI_LV_EXEC, _COMPONENT)) {
> > return;
> > }
> >
> > --
RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long
> -Original Message- > From: alexander.le...@verizon.com [mailto:alexander.le...@verizon.com] > Sent: Thursday, November 16, 2017 4:56 PM > To: Schmauss, Erik > Cc: Moore, Robert ; linux-kernel@vger.kernel.org; > sta...@vger.kernel.org; Wysocki, Rafael J > Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid > resource if buffer length too long > > On Wed, Nov 15, 2017 at 05:05:21PM +, Schmauss, Erik wrote: > > > > > >> -Original Message- > >> From: alexander.le...@verizon.com > >> [mailto:alexander.le...@verizon.com] > >> Sent: Wednesday, November 15, 2017 8:39 AM > >> To: Moore, Robert > >> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Wysocki, > >> Rafael J ; Schmauss, Erik > >> > >> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a > >> valid resource if buffer length too long > >> > >> On Wed, Nov 15, 2017 at 03:39:22PM +, Moore, Robert wrote: > >> >> -Original Message- > >> >> From: alexander.le...@verizon.com > >> >> [mailto:alexander.le...@verizon.com] > >> >> Sent: Tuesday, November 14, 2017 6:46 PM > >> >> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org > >> >> Cc: Moore, Robert ; Zheng, Lv > >> >> ; Wysocki, Rafael J > >> >> ; alexander.le...@verizon.com > >> >> Subject: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a > >> >> valid resource if buffer length too long > >> >> > >> >> From: Bob Moore > >> >> > >> >> [ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ] > >> >> > >> >> ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 > >> >> ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a > >> >> ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e > >> >> > >> >> The declared buffer length must be the same as the length of the > >> >> byte initializer list, otherwise not a valid resource descriptor. > >> [snip] > >> > >> >[Moore, Robert] > >> > > >> >Please explain what you are doing here. > >> > >> Proposing this commit for the 4.9 LTS tree. > > > >What problem are you trying to solve with this change? Are you seeing ACPI > errors? If so what are they? > > Not seeing an actual problem myself. Was this patch supposed to fix a problem > or just deal with a theoretical scenario? > This was supposed to fix issues with our AML disassembler to parse a strange corner in the ASL test suite. I believe this was due to the end tag contains a checksum byte that ACPICA and other ACPI implementations ignore. We thought this was useful in the test suite because we test the disassembler by comparing normally compiled AML with AML that has been compiled, disassembled, and re-compiled. Without this change, the endtag checksum would be over-written to 0 rather than the existing value. I believe this change broke a few things such as the execution of ConcatResTemplate. We concluded to not use this solution and alter the test suite instead because this endtag byte is usually ignored anyway. To answer your question, this was to deal with a theoretical scenario. Erik > -- > > Thanks, > Sasha
