| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: system lockup with 2.6.29 on Cavium/Octeon, Greg Ungerer |
|---|---|
| Next by Date: | Re: [loongson-PATCH-v1 03/27] fix-error: incompatiable argument type of clear_user, Ralf Baechle |
| Previous by Thread: | Re: system lockup with 2.6.29 on Cavium/Octeon, Greg Ungerer |
| Next by Thread: | Re: system lockup with 2.6.29 on Cavium/Octeon, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |