linux-mips
[Top] [All Lists]

Re: system lockup with 2.6.29 on Cavium/Octeon

To: Greg Ungerer <gerg@snapgear.com>
Subject: Re: system lockup with 2.6.29 on Cavium/Octeon
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 21 May 2009 07:28:02 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <4A14E6A1.4030700@snapgear.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4A139F50.7050409@snapgear.com> <20090520142604.GA29677@linux-mips.org> <4A14E6A1.4030700@snapgear.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, May 21, 2009 at 03:29:05PM +1000, Greg Ungerer wrote:

> Interestingly the definition of MODULE_START is like this:
>
> #if defined(CONFIG_MODULES) && defined(KBUILD_64BIT_SYM32) && \
>         VMALLOC_START != CKSSEG
> /* Load modules into 32bit-compatible segment. */
> #define MODULE_START    CKSSEG
>
>
> If MODULE_START wasn't defined then the module_alloc() code would
> have just called vmalloc() directly - and we wouldn't be in this
> mess :-)

The reason it's done like this is that if the kernel is in CKSEG0 and
modules in CKSEG2 all address references to kernel code and variables are
just 32-bit that is they can be referenced with a much shorter instruction
sequence than for full blown 64-bit code.  This is just one of the
artefacts and I think we can just ignore it.

  Ralf

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