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