Hi Wolfgang, On Fri, 4 Sep 2020 at 08:16, Wolfgang Wallner <wolfgang.wall...@br-automation.com> wrote: > > Hi Simon, Bin, > > -----"Simon Glass" <s...@chromium.org> schrieb: ----- > > Betreff: [PATCH v2 08/57] x86: acpi: Support external GNVS tables > > > > At present U-Boot puts a magic number in the ASL for the GNVS table and > > searches for it later. > > > > Add a Kconfig option to use a different approach, where the ASL files > > declare the table as an external symbol. U-Boot can then put it wherever > > it likes, without any magic numbers or searching. > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > --- > > [snip] > > diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c > [snip] > > acpi_inc_align(ctx, dsdt->length - sizeof(struct acpi_table_header)); > > + dsdt->length = ctx->current - (void *)dsdt; > > While testing the latest series of ACPI patches I saw strange behavior when > booting Linux. Sometimes it would boot, sometimes it would hang, sometimes it > would boot but show ACPI-related errors in dmesg. > > Debugging showed that the reason is that the calculated length of the DSDT > in the above code includes any additional bytes that were added for alignment, > and those are not initialized. I gues the Linux ACPI implementation tries to > decode those, and then something crashes. > > Changing the above two lines to the following > > acpi_inc(ctx, dsdt->length - sizeof(struct acpi_table_header)); > dsdt->length = ctx->current - (void *)dsdt; > acpi_align(ctx); > > fixes the issue for me. > > But the issue already exists in the previous code. Would it be better to > send a patch which applies to the currrent master, or on top of the ACPI > series?
I think to the current master would be better. I have seen that problem so thank you for figuring it out! Regards, SImon