All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Kernel crash in 2.6.32.6 / bcm1480 with 16k page size
Date: Fri, 29 Jan 2010 10:56:32 -0800	[thread overview]
Message-ID: <4B632F60.4000604@caviumnetworks.com> (raw)
In-Reply-To: <20100129183926.GB9895@ericsson.com>

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
>>> explained.
>> 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
>> reached.
>>
>> 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.
> 
> Guenter
> 
> ---------------
> 
> git diff arch/mips/include/asm/pgtable-64.h
> diff --git a/arch/mips/include/asm/pgtable-64.h b/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 + \
> -        PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE - (1UL << 32))
> +        (PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE / 16) - (1UL << 32))
>  #if defined(CONFIG_MODULES) && defined(KBUILD_64BIT_SYM32) && \
>         VMALLOC_START != CKSSEG
>  /* 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

#define VIRTUAL_SIZE (PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * 
PAGE_SIZE)

#define VMALLOC_END (VMALLOC_START + min(MAX_VIRTUAL_SIZE, VIRTUAL_SIZE) 
- (1UL << 32))

  reply	other threads:[~2010-01-29 18:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-28 15:55 Kernel crash in 2.6.32.6 / bcm1480 with 16k page size Guenter Roeck
2010-01-29 13:24 ` Ralf Baechle
2010-01-29 15:12   ` Guenter Roeck
2010-01-29 17:11     ` David Daney
2010-01-29 18:06       ` Ralf Baechle
2010-01-29 18:21         ` Guenter Roeck
2010-01-30  2:05           ` Ralf Baechle
2010-01-30 21:34             ` Guenter Roeck
2010-01-31  3:19               ` Guenter Roeck
2010-01-29 18:39         ` Guenter Roeck
2010-01-29 18:56           ` David Daney [this message]
2010-01-29 19:25             ` Guenter Roeck
2010-01-29 19:28               ` David Daney
2010-01-29 19:58                 ` Guenter Roeck
2010-01-31  9:10                   ` Maciej W. Rozycki
2010-01-31 16:55                     ` Guenter Roeck
2010-02-01  2:18                       ` Ralf Baechle
2010-02-01 14:50                         ` Maciej W. Rozycki
2010-02-01 15:26                           ` Ralf Baechle
2010-02-01 23:11                             ` Maciej W. Rozycki
2010-02-01 15:04                         ` Guenter Roeck
2010-02-01 20:21                         ` Guenter Roeck
2010-02-01 20:49                           ` Ralf Baechle
2010-02-01 21:12                             ` Guenter Roeck
2010-01-29 20:00                 ` Guenter Roeck
2010-01-29 20:23                   ` David Daney
2010-01-29 22:19                     ` Guenter Roeck
2010-01-29 18:24       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B632F60.4000604@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=guenter.roeck@ericsson.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.