[Top] [All Lists]

RE: [SPAM] linux- Porting OOPS

To: "J.Ma" <>, "Markus Gothe" <>
Subject: RE: [SPAM] linux- Porting OOPS
From: "Pelton, Dave" <>
Date: Thu, 12 Jun 2008 15:02:31 -0400
Cc: <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
Thread-index: AcjMcgBfCmtwKgxyS6S8eSW8ouBHYgAQDO5g
Thread-topic: [SPAM] linux- Porting OOPS
> -----Original Message-----
> From: 
> [] On Behalf Of J.Ma
> Sent: Thursday, June 12, 2008 5:52 AM
> To: Markus Gothe
> Cc:
> Subject: Re: [SPAM] linux- Porting OOPS
> On Mon, Jun 9, 2008 at 1:53 PM, Markus Gothe 
> <> wrote:
> > Start with checking the memory mapping as hinted by:
> > ra    : 8000dd10 copy_user_highpage+0x98/0x158
> > //Markus
> Thank you for your advice, I checked this function and found that the
> problem might be "cpu_has_dc_aliases", After disabling
> MIPS_CACHE_ALIASES in probe_pcache(), the linux goes on with no oops.
> Could anyone here provide instructions about fusion MIPS SOC(R3K/R4K
> for example)? It confused me a lot. :)

Recently I have been working with on a Broadcom SOC (Raven
56210) with an embedded MIPS32 core, and I had problems similar to what
you were experiencing.

My understanding of the probe code is that there is an automatic
detection of data cache aliasing based on the size of your memory and
the properties of the data cache itself.  Thus while your fix may
your initial kernel OOPs problem, you may be exposed to other problems
a result of data cache aliasing.

The problem I had on my system was that my userspace init would crash
(SIGSEGV).  The same userspace code would run fine on an older kernel
(2.6.14).  Changing the init call to other things (such as /bin/sh)
lead to similar problems.  Using a JTAG debugger, I was able to track
things into the copy_user_highpage function, and I found that this
function was calling copy_page with a source address that had incorrect
data.  The source address was coming from kmap_coherent (which is only
used if cpu_has_dc_aliases is true).  As far as I can tell, the job of
kmap_coherent is to map a user page into kernel virtual memory (kseg2).
Normally kseg2 is in the address range 0xC0000000-0xFFFFFFFF.  However,
on the BMIPS3300 (the embedded MIPS32 core used on my SOC), there is a
range of addresses within kseg2 that are reserved
This means that the TLB entry that kmap_coherent creates will not work
if it falls within the reserved range.  The virtual address space used
by kmap_coherent is controlled by FIXADDR_TOP in
To fix my issue, I changed FIXADDR_TOP to avoid the reserved address

I am hoping to provide a full set of patches to support the evaluation
board that has this chip.  In the meantime, here is the change I made to

--- linux-      2008-05-15
11:00:12.000000000 -0400
+++ linux-    2008-06-12
13:21:49.042673000 -0400
@@ -69,6 +69,8 @@ enum fixed_addresses {
 #if defined(CONFIG_CPU_TX39XX) || defined(CONFIG_CPU_TX49XX)
 #define FIXADDR_TOP    ((unsigned long)(long)(int)(0xff000000 -
+#elif defined(CONFIG_CPU_BMIPS3300)
+#define FIXADDR_TOP    ((unsigned long)(long)(int)0xff200000 - 0x1000)
 #define FIXADDR_TOP    ((unsigned long)(long)(int)0xfffe0000)

You will need to define CONFIG_CPU_BMIPS3300 in your config file for
this change to be applied.  I suspect that the same core is present in
a number of Broadcom SOC designs, so this issue may exist for a number
of different chips.

- David Pelton

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