"Menon, Nishanth" <nm@xxxxxx> writes: >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Guzman Lugo, Fernando >> Sent: Thursday, March 12, 2009 2:04 AM >> To: linux-omap@xxxxxxxxxxxxxxx >> Subject: DSPBRIDGE: segmentation fault after reloading dspbridge several >> times due to a memory leak. >> Reloading the dspbridge several times I am getting a Segmentation >> fault. Seeing the log it seems that the memory was exhausted >> >> The error happens when ioremap is called >> >> void MEM_ExtPhysPoolInit(u32 poolPhysBase, u32 poolSize) >> { >> u32 poolVirtBase; >> >> /* get the virtual address for the physical memory pool passed >> */ >> poolVirtBase = (u32)ioremap(poolPhysBase, poolSize); >> . >> >> Putting some printk's and printing the address returned by ioremap, I >> realized that address returned by ioremap each time I reload the dspbridge >> is different, in fact the address is increasing. I also put a printk where >> iounmap is called to make sure it is called and yes it is actually called. >> However testing with a kernel + bridge for linux 23x I always get the same >> address for pool memory. Any idea what the problem is? I have included the >> console output where you can see the address increasing. > > I duplicated this with the following dummy driver which ioremaps as per the same allocations that the bridge driver would have done: > > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/slab.h> > #include <linux/mm.h> > #include <linux/dma-mapping.h> > > #define BASE 0x87000000 > #define SIZE 0x600000 > > struct mem_s{ > void * vir; > u32 phy; > u32 size; > }; > > struct mem_s b[]={ > {0,BASE,SIZE}, > {0,0x48306000,4096}, > {0,0x48004000,4096}, > {0,0x48094000,4096}, > {0,0x48002000,4096}, > {0,0x5c7f8000,98304}, > {0,0x5ce00000,32768}, > {0,0x5cf04000,81920}, > {0,0x48005000,4096}, > {0,0x48307000,4096}, > {0,0x48306a00,4096}, > {0,0x5d000000,4096}, > }; Nishant, Which of these physical addresses causes an increasing virtual address? The addresses in the 0x48xxxxxx (L4, L4_WKUP) range should just trigger static mapping via the arch-specific ioremap, so those should always map to the same virt address. Could you do the experiment with a smaller number of mappings? Maybe just one at a time of the non L4 mappings? Probably starting with only the BASE,SIZE mapping. Kevin > > static int __init dummy_init(void) > { > int i; > for (i=0;i<(sizeof(b)/sizeof(struct mem_s));i++) { > b[i].vir = ioremap(b[i].phy,b[i].size); > if(b[i].vir == NULL) { > printk(KERN_ERR "Allocation failed idx=%d\n",i); > /* Free up all the prev allocs */ > i--; > while(i>=0) { > iounmap(b[i].vir); > i--; > } > return -ENOMEM; > > } > } > return 0; > } > module_init(dummy_init); > static void __exit dummy_exit(void) > { > int i; > for (i=0;i<(sizeof(b)/sizeof(struct mem_s));i++) { > iounmap(b[i].vir); > } > } > module_exit(dummy_exit); > MODULE_LICENSE("GPL"); > > > Regression script: > #!/bin/bash > i=0 > slee() > { > echo "Sleep " > #sleep 5 > } > while [ $i -lt 100 ]; do > echo "insmod $i" > insmod ./dummy.ko > if [ $? -ne 0 ]; then > echo "QUIT IN INSMOD $i" > exit 1; > fi > slee > echo "rmmod $i" > rmmod dummy > if [ $? -ne 0 ]; then > echo "QUIT IN RMMOD $i" > exit 1; > fi > i=`expr $i + 1` > slee > done > > > > after around 38 iterations: > <4>vmap allocation failed: use vmalloc=<size> to increase size. > vmap allocation failed: use vmalloc=<size> to increase size. > <3>Allocation failed idx=0 > Allocation failed idx=0 > > However cat /proc/meminfo after this error is: > cat /proc/meminfo > MemTotal: 61920 kB > MemFree: 56900 kB > Buffers: 0 kB > Cached: 2592 kB > SwapCached: 0 kB > Active: 1920 kB > Inactive: 1252 kB > Active(anon): 580 kB > Inactive(anon): 0 kB > Active(file): 1340 kB > Inactive(file): 1252 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 0 kB > SwapFree: 0 kB > Dirty: 0 kB > Writeback: 0 kB > AnonPages: 616 kB > Mapped: 688 kB > Slab: 1296 kB > SReclaimable: 480 kB > SUnreclaim: 816 kB > PageTables: 96 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 30960 kB > Committed_AS: 2932 kB > VmallocTotal: 319488 kB > VmallocUsed: 8 kB > VmallocChunk: 319448 kB > > > We seem to have more than enough vmalloc space according to this.. am I right in thinking this is a kernel vmalloc handling issue? > > Regards, > Nishanth Menon > -- > 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 -- 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
