On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote:
> This patch addresses a problem on x86 EFI systems with larger memory
> configurations. Up until now, we've relied on the fact that the
> ACPI RSDT would reside somewhere in low memory that could be permanently
> mapped in kernel address space - so __va() has been sufficient. However,
> on EFI systems, the RSDT is often anywhere in the lower 4GB of physical
> address space. So, we may need to remap it on x86 systems.
The hunk below breaks HP rx7620, rx8620, and Superdome (all ia64)
systems. This is from 2.6.13-rc4-mm1, in
acpi-fix-table-discovery-from-efi-for-x86.patch
> @@ -187,7 +187,9 @@ acpi_status
> acpi_os_map_memory(acpi_physical_address phys, acpi_size size, void __iomem **virt)
> {
> if (efi_enabled) {
> - if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
> + /* determine whether or not we need to call ioremap */
> + if ((EFI_MEMORY_WB & efi_mem_attributes(phys)) &&
> + ((unsigned long)phys < (unsigned long)__pa(high_memory))) {
> *virt = (void __iomem *) phys_to_virt(phys);
> } else {
> *virt = ioremap(phys, size);
If "phys >= __pa(high_memory)", we use ioremap(), but there's no
guarantee that phys is in memory that supports UC. On the systems
I mentioned, phys is above high_memory, but in memory that only
supports WB, which leads to an MCA.
Here's a bit of the memmap:
available 0000000100000000-00000007FDFFFFFF 00000000006FE000 0000000000000008
reserved 00000040000A0000-00000040000BFFFF 0000000000000020 0000000000000008
available 0000004080000000-00000040FED9FFFF 000000000007EDA0 0000000000000008
BS_data 00000040FEDA0000-00000040FEDA1FFF 0000000000000002 0000000000000008
available 00000040FEDA2000-00000040FEDA7FFF 0000000000000006 0000000000000008
BS_data 00000040FEDA8000-00000040FF1FFFFF 0000000000000458 0000000000000008
available 00000040FF200000-00000040FF555FFF 0000000000000356 0000000000000008
RT_code 00000040FF556000-00000040FF5BFFFF 000000000000006A 8000000000000008
BS_code 00000040FF5C0000-00000040FF5FFFFF 0000000000000040 0000000000000008
available 00000040FF600000-00000040FF641FFF 0000000000000042 0000000000000008
RT_code 00000040FF642000-00000040FF67FFFF 000000000000003E 8000000000000008
available 00000040FF680000-00000040FF7DFFFF 0000000000000160 0000000000000008
RT_data 00000040FF7E0000-00000040FF7FFFFF 0000000000000020 8000000000000008
RT_code 00000703FF000000-00000703FFFFFFFF 0000000000001000 8000000000000008
PAL_code 00000723FF000000-00000723FF03FFFF 0000000000000040 8000000000000008
RT_code 00000723FF040000-00000723FFBAFFFF 0000000000000B70 8000000000000008
reserved 00000723FFBB0000-00000723FFE8FFFF 00000000000002E0 8000000000000008
RT_code 00000723FFE90000-00000723FFFFFFFF 0000000000000170 8000000000000008
MemMapIO 00000F0000000000-00000F003FFFFFFF 0000000000040000 8000000000000001
The firmware tables are up in the reserved section at 0x723FFBB0000:
EFI v1.10 by HP: SALsystab=0x723ff7e7640 ACPI 2.0=0x723ffbb0000 HCDP=0x723ffbf27f0 SMBIOS=0x7fffe000
But high_memory is only 0x00000040ff000000 because there's no available
memory for the OS to use above that point (there are a few pages marked
"available", but we ignore them to avoid attribute aliasing on ia64).
So we erroneously try to ioremap the ACPI tables, which causes uncached
accesses to them, which blows up because they really live in memory that
doesn't support UC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |