>>> On 03.10.12 at 16:03, Matt Fleming <matt.fleming@xxxxxxxxx> wrote: > On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote: >> >>> Matt Fleming <matt@xxxxxxxxxxxxxxxxx> 10/03/12 2:59 PM >>> >> >@@ -163,6 +258,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, >> > ret_addr = (void __iomem *) (vaddr + offset); >> > mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr); >> > >> >+ if (insert_identity_mapping(phys_addr, vaddr, size)) >> >+ printk(KERN_WARNING "ioremap: unable to map 0x%llx in identity pagetable\n", >> >+ (unsigned long long)phys_addr); >> >> Isn't that going to trigger quite frequently on 32-bit kernels? > > Hmmm... yeah, probably, though it didn't during my testing. If it is That's suspicious, isn't it? In general, on any machine with more than 3Gb of memory below the 4Gb boundary this ought to trigger for _all_ mappings of MMIO space, and that's already only considering the default of VMSPLIT_3G. > likely to trigger a lot then we might be best only inserting the > identity mmio mapping for 64-bit, and addressing the 32-bit case if we > ever actually need the identity pagetable. I think that would be the best choice for the moment. Btw., once this set of yours is in - will I need to resubmit the time handling patch that actually triggered this work, or will you just reinstate it without further action on my part? Jan -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
