On Tue, 2012-10-16 at 10:17 +0800, Bob Liu wrote: > On Tue, Oct 16, 2012 at 2:28 AM, Tony Prisk wrote: > > On Mon, 2012-10-15 at 10:45 +0100, Mel Gorman wrote: > >> On Mon, Oct 15, 2012 at 09:34:55AM +1300, Tony Prisk wrote: > >> > On Sun, 2012-10-14 at 18:28 +1300, Tony Prisk wrote: > >> > > Up until 07 Oct, drivers/video/wm8505-fb.c was working fine, but on the > >> > > 11 Oct when I did another pull from linus all of a sudden > >> > > dma_alloc_coherent is failing to allocate the framebuffer any longer. > >> > > > >> > > I did a quick look back and found this: > >> > > > >> > > ARM: add coherent dma ops > >> > > > >> > > arch_is_coherent is problematic as it is a global symbol. This > >> > > doesn't work for multi-platform kernels or platforms which can support > >> > > per device coherent DMA. > >> > > > >> > > This adds arm_coherent_dma_ops to be used for devices which connected > >> > > coherently (i.e. to the ACP port on Cortex-A9 or A15). The arm_dma_ops > >> > > are modified at boot when arch_is_coherent is true. > >> > > > >> > > Signed-off-by: Rob Herring > >> > > Cc: Russell King > >> > > Cc: Marek Szyprowski > >> > > Signed-off-by: Marek Szyprowski > >> > > > >> > > > >> > > This is the only patch lately that I could find (not that I would claim > >> > > to be any good at finding things) that is related to the problem. Could > >> > > it have caused the allocations to fail? > >> > > > >> > > Regards > >> > > Tony P > >> > > >> > Have done a bit more digging and found the cause - not Rob's patch so > >> > apologies. > >> > > >> > The cause of the regression is this patch: > >> > > >> > From f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e Mon Sep 17 00:00:00 2001 > >> > From: Mel Gorman > >> > Date: Mon, 8 Oct 2012 16:32:36 -0700 > >> > Subject: [PATCH 2/3] mm: compaction: acquire the zone->lock as late as > >> > possible > >> > > >> > Up until then, the framebuffer allocation with dma_alloc_coherent(...) > >> > was fine. From this patch onwards, allocations fail. > >> > > >> > >> Was this found through bisection or some other means? > >> > >> There was a bug in that series that broke CMA but it was commit bb13ffeb > >> (mm: compaction: cache if a pageblock was scanned and no pages were > >> isolated) and it was fixed by 62726059 (mm: compaction: fix bit ranges > >> in {get,clear,set}_pageblock_skip()). So it should have been fixed by > >> 3.7-rc1 and probably was included by the time you pulled in October 11th > >> but bisection would be a pain. There were problems with that series during > >> development but tests were completing for other people. > >> > >> Just in case, is this still broken in 3.7-rc1? > > > > Still broken. Although the printk's might have cleared it up a bit. > >> > >> > I don't know how this patch would effect CMA allocations, but it seems > >> > to be causing the issue (or at least, it's caused an error in > >> > arch-vt8500 to become visible). > >> > > >> > Perhaps someone who understand -mm could explain the best way to > >> > troubleshoot the cause of this problem? > >> > > >> > >> If you are comfortable with ftrace, it can be used to narrow down where > >> the exact failure is occurring but if you're not comfortable with that > >> then the easiest is a bunch of printks starting in alloc_contig_range() > >> to see at what point and why it returns failure. > >> > >> It's not obvious at the moment why that patch would cause an allocation > >> problem. It's the type of patch that if it was wrong it would fail every > >> time for everyone, not just for a single driver. > >> > > > > I added some printk's to see what was happening. > > > > from arch/arm/mm/dma-mapping.c: arm_dma_alloc(..) it calls out to: > > dma_alloc_from_coherent(). > > > > This returns 0, because: > > mem = dev->dma_mem > > if (!mem) return 0; > > > > and then arm_dma_alloc() falls back on __dma_alloc(..) > > > > > > I suspect the reason this fault is a bit 'weird' is because its > > effectively not using alloc_from_coherent at all, but falling back on > > __dma_alloc all the time, and sometimes it fails. > > > > I think you need to declare that memory using > dma_declare_coherent_memory() before > alloc_from_coherent. I can't dma_declare_coherent_memory() because I don't have the memory yet. We are trying to avoid 'reserving' a block of memory for the framebuffer by requesting it in probe(). > > > Why it caused a problem on that particular commit I don't know - but it > > was reproducible by adding/removing it. > > > > > > Regards > > Tony P > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-mm' in > > the body to majordomo@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Don't email: email@kvack.org > I did a bit more testing, and I've figured out why its different between CMA and non-CMA. in arch/arm/mm/dma-mapping.c static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp, pgprot_t prot, bool is_coherent, const void *caller) { ... if (is_coherent || nommu()) addr = __alloc_simple_buffer(dev, size, gfp, &page); else if (gfp & GFP_ATOMIC) addr = __alloc_from_pool(size, &page); else if (!IS_ENABLED(CONFIG_CMA)) addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, caller); else addr = __alloc_from_contiguous(dev, size, prot, &page); ... With CMA enabled, it calls __alloc_from_contiguous. Without CMA, it calls __alloc_remap_buffer. __alloc_from_contiguous() calls into dma_alloc_from_contiguous(). This shows count=375, align=8 which makes sense (375*4K = ~1.5MB). The 256 page alignment was a concern, so I limited it to 4, but it made no difference either. The for(;;) loop goes through the entire cma bitmap, but alloc_contig_range() returns -16 on every call. I have attached a kernel log with some of my debug messages. CMA was 16MB during this run, with max-order=4. It appears it simply can't find enough contiguous memory. Hopefully someone can see something that makes sense. Regards Tony P