On Mon, Jan 19, 2009 at 10:07:13AM -0700, Matt Gerassimoff wrote: > On Mon, 19 Jan 2009 09:13:58 -0700, Russell King - ARM Linux > <[email protected]> wrote: > > >diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c > >index 18373f7..9f88dd3 100644 > >--- a/arch/arm/mm/ioremap.c > >+++ b/arch/arm/mm/ioremap.c > >@@ -138,7 +138,7 @@ void __check_kvm_seq(struct mm_struct *mm) > > */ > > static void unmap_area_sections(unsigned long virt, unsigned long size) > > { > >- unsigned long addr = virt, end = virt + (size & ~SZ_1M); > >+ unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1)); > > pgd_t *pgd; > > flush_cache_vunmap(addr, end); > >@@ -337,10 +337,7 @@ void __iounmap(volatile void __iomem *io_addr) > > void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr); > > #ifndef CONFIG_SMP > > struct vm_struct **p, *tmp; > >-#endif > >- unsigned int section_mapping = 0; > >-#ifndef CONFIG_SMP > > /* > > * If this is a section based mapping we need to handle it > > * specially as the VM subsystem does not know how to handle > >@@ -352,11 +349,8 @@ void __iounmap(volatile void __iomem *io_addr) > > for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) { > > if ((tmp->flags & VM_IOREMAP) && (tmp->addr == addr)) { > > if (tmp->flags & VM_ARM_SECTION_MAPPING) { > >- *p = tmp->next; > > unmap_area_sections((unsigned long)tmp->addr, > > tmp->size); > >- kfree(tmp); > >- section_mapping = 1; > > } > > break; > > } > >@@ -364,7 +358,6 @@ void __iounmap(volatile void __iomem *io_addr) > > write_unlock(&vmlist_lock); > > #endif > >- if (!section_mapping) > >- vunmap(addr); > >+ vunmap(addr); > > } > > EXPORT_SYMBOL(__iounmap); > > Before this is even tested. I've went down this path. You will receive a > ton > of Bad PMD errors. unmap_area_sections() and vunmap() don't play nice > together. > This type of solution will require changes to unmap_area_sections().
Okay, I've just lost interest in persuing this bug any further. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
