Fixed loading of ACPI tables on EFI (side effect was apparent memory corruption ranging from unpredictable behavior to system reset).
Reported by Nando Eva <nando4...@ymail.com> --- @Nando: please test this patch. It fixed loading for me at least on QEMU/OVMF. It conflicts with lsacpi patch, but you can actually verify that RSDP was updated by using "lsefisystab" in grub. @Vladimir: this looks like 2.02 material as it was obviously wrong. It does not fix weird behavior on physical system (loss of partitions afetr loading table using "acpi"); unfortunately, I cannot reproduce it in QEMU which makes it rather hard to debug. This smells like yet another meory corruption. Also our ACPI table mangling code is not clean (e.g. Linux reports FACS two times). Note that ACPI says normal and extended addresses (i.e. DSDT/XDSDT and FACS/XFACS) are mutually exclusive, while we set both to non-zero. This strictly speaking violates specs. grub-core/commands/acpi.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c index b5c2f27..9f02f22 100644 --- a/grub-core/commands/acpi.c +++ b/grub-core/commands/acpi.c @@ -761,10 +761,10 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int argc, char **args) struct grub_efi_guid acpi = GRUB_EFI_ACPI_TABLE_GUID; struct grub_efi_guid acpi20 = GRUB_EFI_ACPI_20_TABLE_GUID; - grub_efi_system_table->boot_services->install_configuration_table - (&acpi20, grub_acpi_get_rsdpv2 ()); - grub_efi_system_table->boot_services->install_configuration_table - (&acpi, grub_acpi_get_rsdpv1 ()); + efi_call_2 (grub_efi_system_table->boot_services->install_configuration_table, + &acpi20, grub_acpi_get_rsdpv2 ()); + efi_call_2 (grub_efi_system_table->boot_services->install_configuration_table, + &acpi, grub_acpi_get_rsdpv1 ()); } #endif -- tg: (8014b7b..) u/acpi-efi_call (depends on: master) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel