I think it would be a good idea to always print a note when trimming the EFI memory map, even if it's not "available" memory. I just debugged a problem where we trimmed out some memory that contained ACPI tables. When we went to look at a table later, we used the wrong attribute because we couldn't find its address in the EFI memory map. This caused an MCA (uncached access to memory). Straightforward to debug, but the note would have made it quicker. This patch is against 2.5. Bjorn ===== arch/ia64/kernel/efi.c 1.23 vs edited ===== --- 1.23/arch/ia64/kernel/efi.c Wed Aug 27 10:47:27 2003 +++ edited/arch/ia64/kernel/efi.c Wed Sep 24 20:14:01 2003 @@ -249,11 +249,10 @@ if (num_skipped_pages > md->num_pages) num_skipped_pages = md->num_pages; - if (is_available_memory(md)) - printk(KERN_NOTICE "efi.%s: ignoring %luKB of memory at 0x%lx due to granule hole " - "at 0x%lx\n", __FUNCTION__, - (num_skipped_pages << EFI_PAGE_SHIFT) >> 10, - md->phys_addr, start_addr - IA64_GRANULE_SIZE); + printk(KERN_NOTICE "efi.%s: ignoring %luKB of memory at 0x%lx due to granule hole " + "at 0x%lx\n", __FUNCTION__, + (num_skipped_pages << EFI_PAGE_SHIFT) >> 10, + md->phys_addr, start_addr - IA64_GRANULE_SIZE); /* * NOTE: Don't set md->phys_addr to START_ADDR because that could cause the memory * descriptor list to become unsorted. In such a case, md->num_pages will be @@ -277,11 +276,10 @@ if (num_dropped_pages > md->num_pages) num_dropped_pages = md->num_pages; - if (is_available_memory(md)) - printk(KERN_NOTICE "efi.%s: ignoring %luKB of memory at 0x%lx due to granule hole " - "at 0x%lx\n", __FUNCTION__, - (num_dropped_pages << EFI_PAGE_SHIFT) >> 10, - md->phys_addr, end_addr); + printk(KERN_NOTICE "efi.%s: ignoring %luKB of memory at 0x%lx due to granule hole " + "at 0x%lx\n", __FUNCTION__, + (num_dropped_pages << EFI_PAGE_SHIFT) >> 10, + md->phys_addr, end_addr); md->num_pages -= num_dropped_pages; } - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Sep 24 19:53:31 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:17 EST