Hi,
I am using custom 460ex board with kernel version 2.6.30.
I noticed that page_alloc() is returning a page whose memory
is already allocated by lmb_alloc() while unflattening the device
tree. As per my knowledge the memory allocated by lmb_alloc()
should be reserved till the end, right?
Some more explanation of what I observed:
unflatten_device_tree() allocates memory, which will be used
for "struct node" objects in the device tree. I obtained base
address of allocated memory in "unsigned long base_mem"
Now I executed the following code after the kernel booted properly.
---------------------------------------------------------------
extern unsigned long mem; // lmb_alloc() memory
struct page *test_page = virt_to_page(mem);
struct page *new_page = NULL;
while(1)
{
new_page = NULL;
new_page = alloc_page(GFP_KERNEL);
if(!new_page)
{
printk("Allocation failed\n");
while(1);
}
if(test_page == new_page)
{
printk("Memory already allocated by lmb_alloc\n");
while(1);
}
}
---------------------------------------------------------------
After many page allocations, I always hit the condition (test_page == new_page).
Am I doing anything wrong here?
Has anybody faced this kind of problem before?
I also noticed that lmb_dump_all() shows 2 regions overlapping (last two):
LMB configuration:
rmo_size = 0x30000000
memory.size = 0x30000000
memory.cnt = 0x1
memory[0x0] 0x0000000000000000 - 0x000000002fffffff, 0x30000000 bytes
reserved.cnt = 0x6
reserved[0x0] 0x0000000000000000 - 0x00000000006bffff, 0x6c0000 bytes
reserved[0x1] 0x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 bytes
reserved[0x2] 0x000000002fdd0000 - 0x000000002fddffff, 0x10000 bytes
reserved[0x3] 0x000000002fde4000 - 0x000000002fde9fff, 0x6000 bytes
reserved[0x4] 0x000000002fdeb060 - 0x000000002ffff768, 0x214709 bytes
reserved[0x5] 0x000000002fdee000 - 0x000000002ffff769, 0x21176a bytes
Thanks,
Prashant
On Tue, 2011-11-29 at 18:51 +0530, Prashant Bhole wrote:
Hi,
I am using custom 460ex board with kernel version 2.6.30.
I noticed that page_alloc() is returning a page whose memory
is already allocated by lmb_alloc() while unflattening the device
tree. As per my knowledge the memory allocated by lmb_alloc()
should be reserved till the end, right?
This should have been fixed in memblock in recent kernel, at least I
believe it is. It looks like this is caused by overlapping lmb_reserve()
at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
boils down to the same thing).
Old lmb didn't deal with that well at all and that lead to corruption of
the lmb list. We fixed that in
8f7a66051b7523108c5aefb08c6a637e54aedc47
mm/memblock: properly handle overlaps and fix error path
Which got merged in 2.6.39.
If you absolutely need to stick to 2.6.30, you can try backporting the
fix to lmb.
Cheers,
Ben.
Some more explanation of what I observed:
unflatten_device_tree() allocates memory, which will be used
for "struct node" objects in the device tree. I obtained base
address of allocated memory in "unsigned long base_mem"
Now I executed the following code after the kernel booted properly.
---------------------------------------------------------------
extern unsigned long mem; // lmb_alloc() memory
struct page *test_page = virt_to_page(mem);
struct page *new_page = NULL;
while(1)
{
new_page = NULL;
new_page = alloc_page(GFP_KERNEL);
if(!new_page)
{
printk("Allocation failed\n");
while(1);
}
if(test_page == new_page)
{
printk("Memory already allocated by lmb_alloc\n");
while(1);
}
}
---------------------------------------------------------------
After many page allocations, I always hit the condition (test_page == new_page).
Am I doing anything wrong here?
Has anybody faced this kind of problem before?
I also noticed that lmb_dump_all() shows 2 regions overlapping (last two):
LMB configuration:
rmo_size = 0x30000000
memory.size = 0x30000000
memory.cnt = 0x1
memory[0x0] 0x0000000000000000 - 0x000000002fffffff, 0x30000000 bytes
reserved.cnt = 0x6
reserved[0x0] 0x0000000000000000 - 0x00000000006bffff, 0x6c0000 bytes
reserved[0x1] 0x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 bytes
reserved[0x2] 0x000000002fdd0000 - 0x000000002fddffff, 0x10000 bytes
reserved[0x3] 0x000000002fde4000 - 0x000000002fde9fff, 0x6000 bytes
reserved[0x4] 0x000000002fdeb060 - 0x000000002ffff768, 0x214709 bytes
reserved[0x5] 0x000000002fdee000 - 0x000000002ffff769, 0x21176a bytes
Thanks,
Prashant
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Dec 1, 2011 at 9:30 AM, Benjamin Herrenschmidt
[off-list ref] wrote:
On Tue, 2011-11-29 at 18:51 +0530, Prashant Bhole wrote:
quoted
Hi,
I am using custom 460ex board with kernel version 2.6.30.
I noticed that page_alloc() is returning a page whose memory
is already allocated by lmb_alloc() while unflattening the device
tree. As per my knowledge the memory allocated by lmb_alloc()
should be reserved till the end, right?
This should have been fixed in memblock in recent kernel, at least I
believe it is. It looks like this is caused by overlapping lmb_reserve()
at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
boils down to the same thing).
Old lmb didn't deal with that well at all and that lead to corruption of
the lmb list. We fixed that in
8f7a66051b7523108c5aefb08c6a637e54aedc47
=A0 =A0mm/memblock: properly handle overlaps and fix error path
Which got merged in 2.6.39.
If you absolutely need to stick to 2.6.30, you can try backporting the
fix to lmb.
Cheers,
Ben.
I need to stick to 2.6.30, will try backporting the fix. Is this the same t=
hing
which is causing the wrong page (already allocated memory) allocation?
quoted
Some more explanation of what I observed:
unflatten_device_tree() allocates memory, which will be used
for "struct node" objects in the device tree. I obtained base
address of allocated memory in "unsigned long base_mem"
Now I executed the following code after the kernel booted properly.
---------------------------------------------------------------
extern unsigned long mem; // lmb_alloc() memory
struct page *test_page =3D virt_to_page(mem);
struct page *new_page =3D NULL;
while(1)
{
=A0 =A0 new_page =3D NULL;
=A0 =A0 new_page =3D alloc_page(GFP_KERNEL);
=A0 =A0 if(!new_page)
=A0 =A0 {
=A0 =A0 =A0 =A0 printk("Allocation failed\n");
=A0 =A0 =A0 =A0 while(1);
=A0 =A0 }
=A0 =A0 if(test_page =3D=3D new_page)
=A0 =A0 {
=A0 =A0 =A0 =A0 =A0printk("Memory already allocated by lmb_alloc\n");
=A0 =A0 =A0 =A0 =A0while(1);
=A0 =A0 }
}
---------------------------------------------------------------
After many page allocations, I always hit the condition (test_page =3D=
=3D new_page).
quoted
Am I doing anything wrong here?
Has anybody faced this kind of problem before?
I also noticed that lmb_dump_all() shows 2 regions overlapping (last two=
):
quoted
LMB configuration:
=A0rmo_size =A0 =A0=3D 0x30000000
=A0memory.size =3D 0x30000000
=A0memory.cnt =A0=3D 0x1
=A0memory[0x0] =A0 =A00x0000000000000000 - 0x000000002fffffff, 0x3000000=
0 bytes
quoted
=A0reserved.cnt =A0=3D 0x6
=A0reserved[0x0] =A00x0000000000000000 - 0x00000000006bffff, 0x6c0000 by=
tes
quoted
=A0reserved[0x1] =A00x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 byte=
s
quoted
=A0reserved[0x2] =A00x000000002fdd0000 - 0x000000002fddffff, 0x10000 byt=
es
quoted
=A0reserved[0x3] =A00x000000002fde4000 - 0x000000002fde9fff, 0x6000 byte=
s
quoted
=A0reserved[0x4] =A00x000000002fdeb060 - 0x000000002ffff768, 0x214709 by=
tes
quoted
=A0reserved[0x5] =A00x000000002fdee000 - 0x000000002ffff769, 0x21176a by=
tes
quoted
Thanks,
Prashant
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Thanks,
Prashant
quoted
This should have been fixed in memblock in recent kernel, at least I
believe it is. It looks like this is caused by overlapping lmb_reserve()
at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
boils down to the same thing).
Old lmb didn't deal with that well at all and that lead to corruption of
the lmb list. We fixed that in
8f7a66051b7523108c5aefb08c6a637e54aedc47
mm/memblock: properly handle overlaps and fix error path
Which got merged in 2.6.39.
If you absolutely need to stick to 2.6.30, you can try backporting the
fix to lmb.
Cheers,
Ben.
I need to stick to 2.6.30, will try backporting the fix. Is this the same thing
which is causing the wrong page (already allocated memory) allocation?
I can't say for sure but it looks like it could be.
Cheers,
Ben.