> On Mon, Jan 19, 2009 at 07:34:47AM -0600, Woodruff, Richard wrote: > > > Running with latest linux-omap kernel on OMAP3 SDP board, I have problem > > > with iounmap(). It looks like iounmap() does not properly free large > > > areas. Below is a test which fails for me in 6-7 loops. > > > > > > OMAP spesific ioremap code doesn't do much, so I think it's somewhere in > > > generic ARM code. I looked at the ioremap code and for larger areas the > > > code uses area sections, and I believe the bug is somewhere there. > > > > > > Does this work on other processors? > > > > If you wait around a bit using some kind of schedule() + jiffy wait after > > free will it work longer? > > > > Every now and then I've seen some deferred resource releases cause > > failures of such loops. Usually they are more obvious like if your > > really malloc/free'ing direct memory, but there are indirect allocations > > which might add up. > > > > Anyway, it's a behavioral question to help isolate. > > There is no deferred resource releasing here, so such a test is a waste > of time. None? Aren't at least TLB table structures allocated to cover memory but some other tables? Or are those all synchronous allocate and release? I was under some impression that kmalloc's to get some of these came from slabs which don't reap right away. Defiantly we have had issues in video memory before in these kinds of test loops. Are you simplifying or am I just off. Thanks, 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
