On Tue, 17 Aug 2010, Jack Steiner wrote: > On EFI-enabled systems (like UV), the ACPI tables are already mapped as > WB memory. This is done in the EFI function efi_enter_virtual_mode(). > > The E820_ACPI & E820_NVS regions will be mapped as WB memory if the BIOS > sets the WB attribute in the EFI memmap entry for the chunk of memory. > > The ACPI code in acpi_os_map_memory() is not currently aware of the EFI mapping > & currently maps the memory as UC. This seems like a bug. > > In order to prevent attribute aliasing, I think the ACPI mapping needs to > be consistent with the EFI mapping. Otherwise, we will have the OS > referencing the memory as UC at the same time BIOS is referencing it as WB. When would the firmware touch those tables after booting the OS? We once found a Toshiba laptop where the BIOS scribbles on the DSDT at run-time. We presumed from this that Windows must snapshot the tables at boot and run from a copy. We decided not to copy the tables, but to use them in-place. So we added a check for run-time corruption of the tables and we've seen it fire only on that one Toshiba box (which now boots with "acpi=copy_dsdt"). thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
