"Menon, Nishanth" <[email protected]> writes:
>> -----Original Message-----
>> From: [email protected] [mailto:linux-omap-
>> [email protected]] On Behalf Of Guzman Lugo, Fernando
>> Sent: Thursday, March 12, 2009 2:04 AM
>> To: [email protected]
>> 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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
