> The other thing to point out is that vunmap() does its work lazily > (as Richard tried to point out). However, it'll become unlazy when > it has more than 32MB * NR_CPUS to deal with. So, make sure that your > ioremap/vmalloc region is larger than 32MB otherwise you'll still see > crashes. Where we felt the most problems in past years was in low physical memory situations with this kind of looping. The system would get caught in a live lock in rebalance code. That code tries to shrink caches but needs some allocations for it to happen. Maybe 2.6.29 code is better in this regard. The other common but easier to fix spot was test code where user space mmap callers would spin in alloc and free. The MMAP calls would always fail after a while. I've not hear reports for a while so maybe current kernel is great here or the tests aren't being run anymore. Glad RMK has found the root cause for this issue. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
