> -----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}, }; 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
