[Top] [All Lists]

Re: Kernel crash in / bcm1480 with 16k page size

To: Guenter Roeck <>
Subject: Re: Kernel crash in / bcm1480 with 16k page size
From: David Daney <>
Date: Fri, 29 Jan 2010 12:23:21 -0800
Cc: Ralf Baechle <>, "" <>
In-reply-to: <>
References: <> <> <> <> <> <> <> <> <> <>
User-agent: Thunderbird (X11/20090320)
Guenter Roeck wrote:
On Fri, Jan 29, 2010 at 02:28:49PM -0500, David Daney wrote:
Guenter Roeck wrote:
On Fri, Jan 29, 2010 at 01:56:32PM -0500, David Daney wrote:
Guenter Roeck wrote:
On Fri, Jan 29, 2010 at 01:06:20PM -0500, Ralf Baechle wrote:
On Fri, Jan 29, 2010 at 09:11:46AM -0800, David Daney wrote:

So first question would be: Has anyone successfully loaded a 64
bit mips kernel with 2.6.32 and a page size of 16k or 64k ? This
would at least help me reducing the problem to sb1.
Yes, I routinely run with both 64K and 16K page sizes on 2.6.32 and
2.6.33-rc*.  I have not seen any crashes that can not be easily
I can reproduce it with today's 14b7baff3eb4b1b46a592630e6f85ded9264798a.
4K page size works ok, 16K without IPv6 works ok and 16K with IPv6 crashes.
Note, I was testing with a non-16K capable userland so ok means userland is

Either way, that's good enought to look into things.

16k page size works for me with the patch below. Not that I have any idea why;
this was just a blind test.

It seems to me that the notes in arch/mips/include/asm/pgtable-64.h regarding
available virtual memory per page size may contradict with the definition
of VMALLOC_END. VMALLOC_END-VMALLOC_START increases as the page size increases,
but the comments indicate that a system with 16k pages should have _less_
virtual memory available than a system with 4k pages because it only uses
a 2 level page table.



git diff arch/mips/include/asm/pgtable-64.h
diff --git a/arch/mips/include/asm/pgtable-64.h 
index 9cd5089..bd61030 100644
--- a/arch/mips/include/asm/pgtable-64.h
+++ b/arch/mips/include/asm/pgtable-64.h
@@ -110,7 +110,7 @@
 #define VMALLOC_START          MAP_BASE
 #define VMALLOC_END    \
        (VMALLOC_START + \
<< 32))
 #if defined(CONFIG_MODULES) && defined(KBUILD_64BIT_SYM32) && \
 /* Load modules into 32bit-compatible segment. */
Although it may fix it, I think something along the lines of this:

In asm/mach-generic/spaces.h:
#define MAX_VIRTUAL_SIZE (1 << some number)

In asm/mach-sibyte/paces.h:
#define MAX_VIRTUAL_SIZE (1 << some other umber)

In arch/mips/include/asm/pgtable-64.h


Something like that. My patch wasn't supposed to be a proposal for a fix,
just a guide to help finding the underlying problem.
It may require some factor related to the page size.
Someone who knows mips and its memory management scheme should have
a look, otherwise it would just be a trial-end-error fix.

I suspect you are hitting a maximum valid address bits limit and getting the Address Exception. Limiting VMALLOC_END so that you don't hit the limit seems to be the solution. I don't have the manual for the sibyte, so I don't know what the limit is. The architecture specification doesn't state a fixed limit, although it tells what should happen when the limit is reached.

To follow up on this - does Octeon have a fixed VM size limit ?

Yes.  But it is larger than SB1's 44 bits.  For Octeon it is 49 bits.

And when you run your tests with larger page sizes, do you have IPV6 enabled ?


But at 16K pages the VM size is 47 bits, so it is under the limit.

At 64K pages I am using 2-level page tables for 42 bits of VM space which is again under the limit.

On SB1 and 3-level tables, you will always exceed the limit for both 16K (47 bits) and 64K (55 bits) page sizes.

David Daney

<Prev in Thread] Current Thread [Next in Thread>