"alloc_area_pte: page already exists"

"alloc_area_pte: page already exists"

[Xupei Liang]

Hi,

I am working on a PPC440 board running 2.4.19 kernel.
I am seeing this message when I try to boot up the
system. "alloc_area_pte: page already exists". I
am able to get a stack trace to show where it
comes from. The stack trace is shown as follows.

======= Stack trace begins =============

>>NIP; c002e474 <__vmalloc+0x164/0x234 [kernel]>
<=====
Trace; c002e474 <__vmalloc+0x164/0x234 [kernel]>
Trace; c019422c <copy_entries_to_user+0x40/0x2f0
[kernel]>
Trace; c019453c <get_entries+0x60/0xac [kernel]>
Trace; c0195148 <do_ipt_get_ctl+0x2a4/0x2cc [kernel]>
Trace; c0158190 <nf_sockopt+0x150/0x210 [kernel]>
Trace; c0158290 <nf_getsockopt+0x14/0x24 [kernel]>
Trace; c0168380 <ip_getsockopt+0x6f4/0x9ec [kernel]>
Trace; c01829fc <raw_getsockopt+0x1c/0x160 [kernel]>
Trace; c0189a8c <inet_getsockopt+0x20/0x30 [kernel]>
Trace; c01496f0 <sys_getsockopt+0x78/0x9c [kernel]>
Trace; c0149d9c <sys_socketcall+0x1ac/0x1e0 [kernel]>
Trace; c000353c <ret_from_syscall_1+0x0/0xb4 [kernel]>
Trace; 7fffccb8 <Unknown (0x7fffccb8)>
Trace; 10006de4 <Unknown (0x10006de4)>
Trace; 100018f4 <Unknown (0x100018f4)>
Trace; 10001d1c <Unknown (0x10001d1c)>
Trace; 0fefe7f8 <Unknown (0xfefe7f8)>
Trace; 00000000 <Unknown (0x0)>

============ Stack trace ends ================

It seems to me it is from vmalloc(). Has anybody
seen this problem before?

Thank you in advanced for your reply.

Regards,

Terry L.

Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Matt Porter]

On Mon, Jul 21, 2003 at 06:06:08PM -0700, Xupei Liang wrote:
>
> Hi,
>
> I am working on a PPC440 board running 2.4.19 kernel.

Custom board?

--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Xupei Liang]

Matt,

It is a custom board with 256MB of memory.

Regards,

Terry Liang

--- Matt Porter <mporter@kernel.crashing.org> wrote:
>
> On Mon, Jul 21, 2003 at 06:06:08PM -0700, Xupei
> Liang wrote:
> >
> > Hi,
> >
> > I am working on a PPC440 board running 2.4.19
> kernel.
>
> Custom board?
>
> --
> Matt Porter
> mporter@kernel.crashing.org
>
>


Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Matt Porter]

On Mon, Jul 21, 2003 at 07:01:49PM -0700, Xupei Liang wrote:
>
> Matt,
>
> It is a custom board with 256MB of memory.

Ahh, ok.  So, what you've done is misconfigured a mapping in
your custom board port.  It's reporting that you already have
a pte allocated in the vmalloc area which must be untouched
so the VM can allocate memory at runtime.

Usually, this is the result of an errant io_block_map entry
which overlaps the vmalloc area.  Examine the VMALLOC_START
macro to see how the start of vmalloc space is calculated.
In your case, (256MB of RAM) the start of vmalloc space will
be at 0xd1000000 assuming a standard PAGE_OFFSET of 0xc0000000.
If you've mapped something near that virtual address or somewhere
close above that address then you need to move it.  How much
vmalloc space you need to reserve depends solely on your specific
application.

In most cases, it's smarter to never use io_block_map and to
let ioremap() create mappings dynamically so this sort of thing
doesn't happen. Most modern in-kernel ports try to not use
io_block_map if at all possible.

Regards,
--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Xupei Liang]

Hi, Matt,

Thank you.

I am not using any io_block_map() call in the code.
However, there are might be other similar causes.
I am still working on it.

If you have more ideas, please let me know.

Regards,

Terry L.


--- Matt Porter <mporter@kernel.crashing.org> wrote:
>
> On Mon, Jul 21, 2003 at 07:01:49PM -0700, Xupei
> Liang wrote:
> >
> > Matt,
> >
> > It is a custom board with 256MB of memory.
>
> Ahh, ok.  So, what you've done is misconfigured a
> mapping in
> your custom board port.  It's reporting that you
> already have
> a pte allocated in the vmalloc area which must be
> untouched
> so the VM can allocate memory at runtime.
>
> Usually, this is the result of an errant
> io_block_map entry
> which overlaps the vmalloc area.  Examine the
> VMALLOC_START
> macro to see how the start of vmalloc space is
> calculated.
> In your case, (256MB of RAM) the start of vmalloc
> space will
> be at 0xd1000000 assuming a standard PAGE_OFFSET of
> 0xc0000000.
> If you've mapped something near that virtual address
> or somewhere
> close above that address then you need to move it.
> How much
> vmalloc space you need to reserve depends solely on
> your specific
> application.
>
> In most cases, it's smarter to never use
> io_block_map and to
> let ioremap() create mappings dynamically so this
> sort of thing
> doesn't happen. Most modern in-kernel ports try to
> not use
> io_block_map if at all possible.
>
> Regards,
> --
> Matt Porter
> mporter@kernel.crashing.org
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Kalpesh Jasapara]

Hello,

>From the code it appears that iounmap() or vfree() of
any virtual address that maps physical address beyond
the 32 bit address space, especially in case of PPC
440 (where pte_t is defined as unsigned long long ),
free_area_pte() will return without completely
clearing out the pte.

If the pte has not completely been cleaned up (all 64
bits) during the iounmap(or vfree) is it possible that
pte_none() would complain and you see the messages ?

Matt, do you think it is a bug ?
the FIXME suggests that this needs to be cleaned up.

File: pgtable.h
<..snip..>
#else /* CONFIG_440 */
/* FIXME: Clean this up */
static inline unsigned long pte_update(pte_t *p,
unsigned long clr,
                                       unsigned long
set)
{
        unsigned long old, tmp, offset;

        __asm__ __volatile__("\
1:      li      %0,4\n\
        lwarx   %2,%0,%4\n\
        andc    %1,%2,%5\n\
        or      %1,%1,%6\n"
"       stwcx.  %1,%0,%4\n\
        bne-    1b"
        : "=&r" (offset), "=&r" (tmp), "=&r" (old),
"=m" (*p)
        : "r" (p), "r" (clr), "r" (set), "m" (*p)
        : "cc" );
        return old;
}
#endif /* CONFIG_440 */
<...snip...>

Regards,
-Kalpesh

>
> Matt,
>
> It is a custom board with 256MB of memory.

Ahh, ok. So, what you've done is misconfigured a
mapping in
your custom board port. It's reporting that you
already have
a pte allocated in the vmalloc area which must be
untouched
so the VM can allocate memory at runtime.

Usually, this is the result of an errant io_block_map
entry
which overlaps the vmalloc area. Examine the
VMALLOC_START
macro to see how the start of vmalloc space is
calculated.
In your case, (256MB of RAM) the start of vmalloc
space will
be at 0xd1000000 assuming a standard PAGE_OFFSET of
0xc0000000.
If you've mapped something near that virtual address
or somewhere
close above that address then you need to move it. How
much
vmalloc space you need to reserve depends solely on
your specific
application.

In most cases, it's smarter to never use io_block_map
and to
let ioremap() create mappings dynamically so this sort
of thing
doesn't happen. Most modern in-kernel ports try to not
use
io_block_map if at all possible.

Regards,
--
Matt Porter


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Matt Porter]

On Mon, Jul 28, 2003 at 11:23:48PM -0700, Kalpesh Jasapara wrote:
> Hello,
>
> >From the code it appears that iounmap() or vfree() of
> any virtual address that maps physical address beyond
> the 32 bit address space, especially in case of PPC
> 440 (where pte_t is defined as unsigned long long ),
> free_area_pte() will return without completely
> clearing out the pte.
>
> If the pte has not completely been cleaned up (all 64
> bits) during the iounmap(or vfree) is it possible that
> pte_none() would complain and you see the messages ?
>
> Matt, do you think it is a bug ?
> the FIXME suggests that this needs to be cleaned up.

Yes it is...good catch. :)  The FIXME comment in pte_update()
is really suggesting that the interface isn't suitable for
64-bit PTE.  We can fix this by providing a suitable
_PTE_NONE_MASK, it's intended to be used in PTEs where everything
isn't cleared.

It would be interesting to hear if the following patch solves
the original problem.  It helps me.

-Matt

===== include/asm-ppc/pgtable.h 1.41 vs edited =====
--- 1.41/include/asm-ppc/pgtable.h      Wed Jul 16 18:38:55 2003
+++ edited/include/asm-ppc/pgtable.h    Tue Jul 29 06:25:15 2003
@@ -220,6 +220,9 @@
 #define _PMD_PRESENT_MASK (PAGE_MASK)
 #define _PMD_BAD       (~PAGE_MASK)

+/* ERPN in a PTE never gets cleared, ignore it */
+#define _PTE_NONE_MASK 0xffffffff00000000ULL
+
 #elif defined(CONFIG_8xx)
 /* Definitions for 8xx embedded chips. */
 #define _PAGE_PRESENT  0x0001  /* Page is valid */

--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "alloc_area_pte: page already exists"

[Xupei Liang]

Hi,

Thank both for looking into this. The patch
has got rid of the message.

Regards,

Terry Liang

--- Matt Porter <mporter@kernel.crashing.org> wrote:
>
> On Mon, Jul 28, 2003 at 11:23:48PM -0700, Kalpesh
> Jasapara wrote:
> > Hello,
> >
> > >From the code it appears that iounmap() or
> vfree() of
> > any virtual address that maps physical address
> beyond
> > the 32 bit address space, especially in case of
> PPC
> > 440 (where pte_t is defined as unsigned long long
> ),
> > free_area_pte() will return without completely
> > clearing out the pte.
> >
> > If the pte has not completely been cleaned up (all
> 64
> > bits) during the iounmap(or vfree) is it possible
> that
> > pte_none() would complain and you see the messages
> ?
> >
> > Matt, do you think it is a bug ?
> > the FIXME suggests that this needs to be cleaned
> up.
>
> Yes it is...good catch. :)  The FIXME comment in
> pte_update()
> is really suggesting that the interface isn't
> suitable for
> 64-bit PTE.  We can fix this by providing a suitable
> _PTE_NONE_MASK, it's intended to be used in PTEs
> where everything
> isn't cleared.
>
> It would be interesting to hear if the following
> patch solves
> the original problem.  It helps me.
>
> -Matt
>
> ===== include/asm-ppc/pgtable.h 1.41 vs edited =====
> --- 1.41/include/asm-ppc/pgtable.h      Wed Jul 16
> 18:38:55 2003
> +++ edited/include/asm-ppc/pgtable.h    Tue Jul 29
> 06:25:15 2003
> @@ -220,6 +220,9 @@
>  #define _PMD_PRESENT_MASK (PAGE_MASK)
>  #define _PMD_BAD       (~PAGE_MASK)
>
> +/* ERPN in a PTE never gets cleared, ignore it */
> +#define _PTE_NONE_MASK 0xffffffff00000000ULL
> +
>  #elif defined(CONFIG_8xx)
>  /* Definitions for 8xx embedded chips. */
>  #define _PAGE_PRESENT  0x0001  /* Page is valid */
>
> --
> Matt Porter
> mporter@kernel.crashing.org
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/