linux-2.6.25.4 Porting OOPS

linux-2.6.25.4 Porting OOPS

[J.Ma]

Hi all,
    I am a newbie in kernel, so please be gentle.:)
    For these days, I am working on porting linux-2.6.25.4 to my own
Broadcom's SOC board, and I choose BCM47xx to start when menuconfig.
Everything goes well, I ported timer, serial, flash,etc. howerver, it
just broken when jumping to the userspace routine /sbin/init, please
take a look at the oops dump belowed.
    Could anyone give me a hint kindly? I doubt it might be the
toolchain's problem(maybe syscall_exit got a invalid para), bcz the
mipsel-linux- toolchain I used is built for linux-2.6.12. Since it
would be a huge work to rebuild a new 2.6.25-based toolchain, I sent
this email to check if any experienced guy could acknowledge this.
    Thanks in advance.



open /dev/console done.
try execute_command.
try /sbin/init.
Data bus error, epc == 8038c180, ra == 8000dd10
Oops[#1]:
Cpu 0
$ 0   : 00000000 10008000 fffda000 00000001
$ 4   : 811bf000 fffda000 811bff00 fffda000
$ 8   : 81007b20 00000044 2aaad268 2ab45c5c
$12   : 00000248 007cd68b 2ab48f4c 004670d0
$16   : 811bf000 80380000 7fb0a1d8 87d05a50
$20   : 87d7c7f8 87d05a50 87cfb1a0 7fb0a1d8
$24   : 000001b7 2aaa8a9c
$28   : 87d78000 87d79da0 87cfb1f0 8000dd10
Hi    : 308287f7
Lo    : b4e07b20
epc   : 8038c180 0x8038c180     Not tainted
ra    : 8000dd10 copy_user_highpage+0x98/0x158
Status: 10008003    KERNEL EXL IE
Cause : 0080001c
PrId  : 00020000 (Broadcom BCM4710)
Modules linked in:
Process init (pid: 206, threadinfo=87d78000, task=87c32df8)
Stack : 00000000 81007b20 87d7fc28 87d05a50 00000000 81007b20 87d7fc28 810237e0
        800774f8 80077440 87cfb1a0 87d7c004 00000000 00000000 00000000 00000000
        00000000 00000000 003d969b 87d7fc28 003d969b 87d05a50 87cfb1f0 7fb0a1d8
        87d7c7f8 00030000 7fb0a624 80078c88 87cfb1a0 00000000 87c32df8 802c3b0c
        87d7c7f8 87cfb1f0 003d969b 87cfb1a0 802c35ec 00000000 00000000 00000000
        ...
Call Trace:
[<800774f8>] do_wp_page+0x58c/0x818
[<80077440>] do_wp_page+0x4d4/0x818
[<80078c88>] handle_mm_fault+0x778/0x86c
[<802c3b0c>] _spin_unlock_irq+0x10/0x3c
[<802c35ec>] __down_read+0x48/0x150
[<8000d6f0>] do_page_fault+0x100/0x340
[<80002a00>] ret_from_exception+0x0/0x24
[<80002a78>] syscall_exit+0x0/0x38


Code: cca40100  8ca80000  8ca90004 <8caa0008> 8cab000c  cc9e0100
ac880000  ac890004  ac8a0008
note: init[206] exited with preempt_count 2
BUG: scheduling while atomic: init/206/0x10000002
Call Trace:
[<80008384>] dump_stack+0x8/0x34
[<802c0c6c>] schedule+0x74/0x5b8
[<80023e90>] __cond_resched+0x30/0x5c
[<802c1304>] _cond_resched+0x4c/0x60
[<802c2a50>] down_read+0x28/0x3c
[<80056ecc>] acct_collect+0x48/0x1a8
[<8002c340>] do_exit+0x2a0/0x738
[<80008a80>] do_be+0x0/0x16c

Data bus error, epc == 8038c180, ra == 8000dd10
Oops[#2]:
Cpu 0
$ 0   : 00000000 10008000 fffda000 00000002
$ 4   : 811c4000 fffda000 811c4f00 fffda000
$ 8   : 81007b20 00000001 81023940 00080000
$12   : 00000000 80386980 00000001 2ab437dc
$16   : 811c4000 80380000 7fb0a1dc 87d05058
$20   : 87d0a7f8 87d05058 87cfb000 7fb0a1dc
$24   : 00000001 0046703c
$28   : 87c18000 87c19da0 87cfb050 8000dd10
Hi    : 308287f7
Lo    : b4e07b20
epc   : 8038c180 0x8038c180     Tainted: G      D
ra    : 8000dd10 copy_user_highpage+0x98/0x158
Status: 10008003    KERNEL EXL IE
Cause : 0080001c
PrId  : 00020000 (Broadcom BCM4710)
Modules linked in:
Process init (pid: 1, threadinfo=87c18000, task=87c16000)
Stack : 00000000 81007b20 87d17c28 87d05058 00000000 81007b20 87d17c28 81023880
        800774f8 80077440 00000000 10008000 00000001 ffffffff 00000000 00000000
        00000000 00000000 003d969b 87d17c28 003d969b 87d05058 87cfb050 7fb0a1dc
        87d0a7f8 00030000 7fb0a624 80078c88 000000ce 00000000 87c16000 802c3b0c
        87d0a7f8 87cfb050 003d969b 87cfb000 802c35ec 8001fa34 87c18000 87c19e60
        ...
Call Trace:
[<800774f8>] do_wp_page+0x58c/0x818
[<80077440>] do_wp_page+0x4d4/0x818
[<80078c88>] handle_mm_fault+0x778/0x86c
[<802c3b0c>] _spin_unlock_irq+0x10/0x3c
[<802c35ec>] __down_read+0x48/0x150
[<8001fa34>] enqueue_task_fair+0x2c/0x44
[<8000d6f0>] do_page_fault+0x100/0x340
[<80027908>] do_fork+0x254/0x338
[<800277d0>] do_fork+0x11c/0x338
[<8001f9cc>] set_next_entity+0x28/0x64
[<8001f9cc>] set_next_entity+0x28/0x64
[<8001fd84>] pick_next_task_fair+0xc0/0xf0
[<8001fdfc>] put_prev_task_fair+0x48/0x64
[<8001fde4>] put_prev_task_fair+0x30/0x64
[<802c1160>] schedule+0x568/0x5b8
[<80002a00>] ret_from_exception+0x0/0x24
[<80002b80>] work_resched+0x8/0x44


Code: cca40100  8ca80000  8ca90004 <8caa0008> 8cab000c  cc9e0100
ac880000  ac890004  ac8a0008
note: init[1] exited with preempt_count 2
Kernel panic - not syncing: Attempted to kill init!



-- 
FIXME if it is wrong.

Re: [SPAM] linux-2.6.25.4 Porting OOPS

[Markus Gothe]

[-- Attachment #1.1: Type: text/plain, Size: 5476 bytes --]

Start with checking the memory mapping as hinted by:
ra    : 8000dd10 copy_user_highpage+0x98/0x158

//Markus

On 9 Jun 2008, at 05:01, J.Ma wrote:

> Hi all,
>    I am a newbie in kernel, so please be gentle.:)
>    For these days, I am working on porting linux-2.6.25.4 to my own
> Broadcom's SOC board, and I choose BCM47xx to start when menuconfig.
> Everything goes well, I ported timer, serial, flash,etc. howerver, it
> just broken when jumping to the userspace routine /sbin/init, please
> take a look at the oops dump belowed.
>    Could anyone give me a hint kindly? I doubt it might be the
> toolchain's problem(maybe syscall_exit got a invalid para), bcz the
> mipsel-linux- toolchain I used is built for linux-2.6.12. Since it
> would be a huge work to rebuild a new 2.6.25-based toolchain, I sent
> this email to check if any experienced guy could acknowledge this.
>    Thanks in advance.
>
>
>
> open /dev/console done.
> try execute_command.
> try /sbin/init.
> Data bus error, epc == 8038c180, ra == 8000dd10
> Oops[#1]:
> Cpu 0
> $ 0   : 00000000 10008000 fffda000 00000001
> $ 4   : 811bf000 fffda000 811bff00 fffda000
> $ 8   : 81007b20 00000044 2aaad268 2ab45c5c
> $12   : 00000248 007cd68b 2ab48f4c 004670d0
> $16   : 811bf000 80380000 7fb0a1d8 87d05a50
> $20   : 87d7c7f8 87d05a50 87cfb1a0 7fb0a1d8
> $24   : 000001b7 2aaa8a9c
> $28   : 87d78000 87d79da0 87cfb1f0 8000dd10
> Hi    : 308287f7
> Lo    : b4e07b20
> epc   : 8038c180 0x8038c180     Not tainted
> ra    : 8000dd10 copy_user_highpage+0x98/0x158
> Status: 10008003    KERNEL EXL IE
> Cause : 0080001c
> PrId  : 00020000 (Broadcom BCM4710)
> Modules linked in:
> Process init (pid: 206, threadinfo=87d78000, task=87c32df8)
> Stack : 00000000 81007b20 87d7fc28 87d05a50 00000000 81007b20  
> 87d7fc28 810237e0
>        800774f8 80077440 87cfb1a0 87d7c004 00000000 00000000  
> 00000000 00000000
>        00000000 00000000 003d969b 87d7fc28 003d969b 87d05a50  
> 87cfb1f0 7fb0a1d8
>        87d7c7f8 00030000 7fb0a624 80078c88 87cfb1a0 00000000  
> 87c32df8 802c3b0c
>        87d7c7f8 87cfb1f0 003d969b 87cfb1a0 802c35ec 00000000  
> 00000000 00000000
>        ...
> Call Trace:
> [<800774f8>] do_wp_page+0x58c/0x818
> [<80077440>] do_wp_page+0x4d4/0x818
> [<80078c88>] handle_mm_fault+0x778/0x86c
> [<802c3b0c>] _spin_unlock_irq+0x10/0x3c
> [<802c35ec>] __down_read+0x48/0x150
> [<8000d6f0>] do_page_fault+0x100/0x340
> [<80002a00>] ret_from_exception+0x0/0x24
> [<80002a78>] syscall_exit+0x0/0x38
>
>
> Code: cca40100  8ca80000  8ca90004 <8caa0008> 8cab000c  cc9e0100
> ac880000  ac890004  ac8a0008
> note: init[206] exited with preempt_count 2
> BUG: scheduling while atomic: init/206/0x10000002
> Call Trace:
> [<80008384>] dump_stack+0x8/0x34
> [<802c0c6c>] schedule+0x74/0x5b8
> [<80023e90>] __cond_resched+0x30/0x5c
> [<802c1304>] _cond_resched+0x4c/0x60
> [<802c2a50>] down_read+0x28/0x3c
> [<80056ecc>] acct_collect+0x48/0x1a8
> [<8002c340>] do_exit+0x2a0/0x738
> [<80008a80>] do_be+0x0/0x16c
>
> Data bus error, epc == 8038c180, ra == 8000dd10
> Oops[#2]:
> Cpu 0
> $ 0   : 00000000 10008000 fffda000 00000002
> $ 4   : 811c4000 fffda000 811c4f00 fffda000
> $ 8   : 81007b20 00000001 81023940 00080000
> $12   : 00000000 80386980 00000001 2ab437dc
> $16   : 811c4000 80380000 7fb0a1dc 87d05058
> $20   : 87d0a7f8 87d05058 87cfb000 7fb0a1dc
> $24   : 00000001 0046703c
> $28   : 87c18000 87c19da0 87cfb050 8000dd10
> Hi    : 308287f7
> Lo    : b4e07b20
> epc   : 8038c180 0x8038c180     Tainted: G      D
> ra    : 8000dd10 copy_user_highpage+0x98/0x158
> Status: 10008003    KERNEL EXL IE
> Cause : 0080001c
> PrId  : 00020000 (Broadcom BCM4710)
> Modules linked in:
> Process init (pid: 1, threadinfo=87c18000, task=87c16000)
> Stack : 00000000 81007b20 87d17c28 87d05058 00000000 81007b20  
> 87d17c28 81023880
>        800774f8 80077440 00000000 10008000 00000001 ffffffff  
> 00000000 00000000
>        00000000 00000000 003d969b 87d17c28 003d969b 87d05058  
> 87cfb050 7fb0a1dc
>        87d0a7f8 00030000 7fb0a624 80078c88 000000ce 00000000  
> 87c16000 802c3b0c
>        87d0a7f8 87cfb050 003d969b 87cfb000 802c35ec 8001fa34  
> 87c18000 87c19e60
>        ...
> Call Trace:
> [<800774f8>] do_wp_page+0x58c/0x818
> [<80077440>] do_wp_page+0x4d4/0x818
> [<80078c88>] handle_mm_fault+0x778/0x86c
> [<802c3b0c>] _spin_unlock_irq+0x10/0x3c
> [<802c35ec>] __down_read+0x48/0x150
> [<8001fa34>] enqueue_task_fair+0x2c/0x44
> [<8000d6f0>] do_page_fault+0x100/0x340
> [<80027908>] do_fork+0x254/0x338
> [<800277d0>] do_fork+0x11c/0x338
> [<8001f9cc>] set_next_entity+0x28/0x64
> [<8001f9cc>] set_next_entity+0x28/0x64
> [<8001fd84>] pick_next_task_fair+0xc0/0xf0
> [<8001fdfc>] put_prev_task_fair+0x48/0x64
> [<8001fde4>] put_prev_task_fair+0x30/0x64
> [<802c1160>] schedule+0x568/0x5b8
> [<80002a00>] ret_from_exception+0x0/0x24
> [<80002b80>] work_resched+0x8/0x44
>
>
> Code: cca40100  8ca80000  8ca90004 <8caa0008> 8cab000c  cc9e0100
> ac880000  ac890004  ac8a0008
> note: init[1] exited with preempt_count 2
> Kernel panic - not syncing: Attempted to kill init!
>
>
>
> -- 
> FIXME if it is wrong.
>

_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)70 348 44 35
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com




[-- Attachment #1.2: Type: text/html, Size: 9052 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [SPAM] linux-2.6.25.4 Porting OOPS

[J.Ma]

On Mon, Jun 9, 2008 at 1:53 PM, Markus Gothe <markus.gothe@27m.se> 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. :)

-- 
FIXME if it is wrong.

RE: [SPAM] linux-2.6.25.4 Porting OOPS

[Pelton, Dave]

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of J.Ma
> Sent: Thursday, June 12, 2008 5:52 AM
> To: Markus Gothe
> Cc: linux-mips@linux-mips.org
> Subject: Re: [SPAM] linux-2.6.25.4 Porting OOPS
> 
> On Mon, Jun 9, 2008 at 1:53 PM, Markus Gothe 
> <markus.gothe@27m.se> 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 2.6.25.4 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
address
your initial kernel OOPs problem, you may be exposed to other problems
as
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)
would
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
(0xFF200000-0xFFFEFFFF).
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
include/asm-mips/fixmap.h.
To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
space.

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
include/asm-mips/fixmap.h:

--- linux-2.6.25.4-clean/include/asm-mips/fixmap.h      2008-05-15
11:00:12.000000000 -0400
+++ linux-2.6.25.4/include/asm-mips/fixmap.h    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 -
0x20000))
+#elif defined(CONFIG_CPU_BMIPS3300)
+#define FIXADDR_TOP    ((unsigned long)(long)(int)0xff200000 - 0x1000)
 #else
 #define FIXADDR_TOP    ((unsigned long)(long)(int)0xfffe0000)
 #endif

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

RE: [SPAM] linux-2.6.25.4 Porting OOPS

[Pelton, Dave]

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of J.Ma
> Sent: Thursday, June 12, 2008 5:52 AM
> To: Markus Gothe
> Cc: linux-mips@linux-mips.org
> Subject: Re: [SPAM] linux-2.6.25.4 Porting OOPS
> 
> On Mon, Jun 9, 2008 at 1:53 PM, Markus Gothe 
> <markus.gothe@27m.se> 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 2.6.25.4 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
address
your initial kernel OOPs problem, you may be exposed to other problems
as
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)
would
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
(0xFF200000-0xFFFEFFFF).
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
include/asm-mips/fixmap.h.
To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
space.

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
include/asm-mips/fixmap.h:

--- linux-2.6.25.4-clean/include/asm-mips/fixmap.h      2008-05-15
11:00:12.000000000 -0400
+++ linux-2.6.25.4/include/asm-mips/fixmap.h    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 -
0x20000))
+#elif defined(CONFIG_CPU_BMIPS3300)
+#define FIXADDR_TOP    ((unsigned long)(long)(int)0xff200000 - 0x1000)
 #else
 #define FIXADDR_TOP    ((unsigned long)(long)(int)0xfffe0000)
 #endif

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

Re: [SPAM] linux-2.6.25.4 Porting OOPS

[Ralf Baechle]

On Thu, Jun 12, 2008 at 03:02:31PM -0400, Pelton, Dave wrote:

> --- linux-2.6.25.4-clean/include/asm-mips/fixmap.h      2008-05-15
> 11:00:12.000000000 -0400
> +++ linux-2.6.25.4/include/asm-mips/fixmap.h    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 -
> 0x20000))
> +#elif defined(CONFIG_CPU_BMIPS3300)
> +#define FIXADDR_TOP    ((unsigned long)(long)(int)0xff200000 - 0x1000)
>  #else
>  #define FIXADDR_TOP    ((unsigned long)(long)(int)0xfffe0000)
>  #endif
> 
> 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.

There are a few other processors such as some TX4900 family members which
use up some virtual address space without telling telling the OS.  In any
case I consider that a blatant violation fo the architecture and the
kernel should be tought about these special cases.

  Ralf

Re: [SPAM] linux-2.6.25.4 Porting OOPS

[David VomLehn]

Pelton, Dave wrote:

> 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)
> would
> 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
> (0xFF200000-0xFFFEFFFF).
> 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
> include/asm-mips/fixmap.h.
> To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
> space.
<snip>

Is your range of addresses reserved on the BMIPS3300 because it is being used as 
dseg, i.e. because it is being used for debugging? If I read the documentation on 
the processor I am using, the 24Kc, it has a similar issue. I don't need to be 
able to use kmap_coherent because the 24K hardware takes care of data coherence 
issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we might just 
generally want to change FIXADDR_TOP to avoid address in the dseg range for all 
MIPS32 processors. As we work our way through some of the cache flushing issues 
related to using high memory, I'd like to be able to develop code that works on 
processors for which cpu_has_dc_aliases is true. If my kmap_coherent is working I 
can check things out for those processors and then simply use kmap_atomic for 
processors where cpu_has_dc_aliases is false.

Any comments?

-- 
David VomLehn, dvomlehn@cisco.com
The opinions expressed herein are likely mine, but might not be my employer's...




     - - - - -                              Cisco                            - - - - -         
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to 
the addressee). If you are not the intended recipient of this message, you are 
not authorized to read, print, retain, copy or disseminate this message or any 
part of it. If you have received this e-mail in error, please notify the sender 
immediately by return e-mail and delete it from your computer.

RE: [SPAM] linux-2.6.25.4 Porting OOPS

[Pelton, Dave]

David VomLehn wrote:
> Pelton, Dave wrote:
> > <snip>
> > 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
> > (0xFF200000-0xFFFEFFFF).
> > 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
> > include/asm-mips/fixmap.h.
> > To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
> > space.
> <snip>
> 
> Is your range of addresses reserved on the BMIPS3300 because it is
being used as
> dseg, i.e. because it is being used for debugging? If I read the
documentation on
> the processor I am using, the 24Kc, it has a similar issue. I don't
need to be
> able to use kmap_coherent because the 24K hardware takes care of data
coherence
> issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we
might just
> generally want to change FIXADDR_TOP to avoid address in the dseg
range for all
> MIPS32 processors. As we work our way through some of the cache
flushing issues
> related to using high memory, I'd like to be able to develop code that
works on
> processors for which cpu_has_dc_aliases is true. If my kmap_coherent
is working I
> can check things out for those processors and then simply use
kmap_atomic for
> processors where cpu_has_dc_aliases is false.

Apologies in advance for what my plain-text impaired mail client is
likely to do to this message.  The reserved range on the BMIPS3300 is
used by memory mapped registers.  I am not a memory management expert,
so I am not sure what implications there would be to moving FIXADDR_TOP
as a general fix.  The impression I have from general MIPS documentation
is that kseg2 should not be used for memory mapped i/o and hence
platforms that do this should be treated as an exception case, rather
than moving the general case to deal with this.

- David Pelton

RE: [SPAM] linux-2.6.25.4 Porting OOPS

[Pelton, Dave]

David VomLehn wrote:
> Pelton, Dave wrote:
> > <snip>
> > 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
> > (0xFF200000-0xFFFEFFFF).
> > 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
> > include/asm-mips/fixmap.h.
> > To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
> > space.
> <snip>
> 
> Is your range of addresses reserved on the BMIPS3300 because it is
being used as
> dseg, i.e. because it is being used for debugging? If I read the
documentation on
> the processor I am using, the 24Kc, it has a similar issue. I don't
need to be
> able to use kmap_coherent because the 24K hardware takes care of data
coherence
> issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we
might just
> generally want to change FIXADDR_TOP to avoid address in the dseg
range for all
> MIPS32 processors. As we work our way through some of the cache
flushing issues
> related to using high memory, I'd like to be able to develop code that
works on
> processors for which cpu_has_dc_aliases is true. If my kmap_coherent
is working I
> can check things out for those processors and then simply use
kmap_atomic for
> processors where cpu_has_dc_aliases is false.

Apologies in advance for what my plain-text impaired mail client is
likely to do to this message.  The reserved range on the BMIPS3300 is
used by memory mapped registers.  I am not a memory management expert,
so I am not sure what implications there would be to moving FIXADDR_TOP
as a general fix.  The impression I have from general MIPS documentation
is that kseg2 should not be used for memory mapped i/o and hence
platforms that do this should be treated as an exception case, rather
than moving the general case to deal with this.

- David Pelton

Re: linux-2.6.25.4 Porting OOPS

[Kevin D. Kissell]

The MIPS32 EJTAG debug capability includes a set of memory mapped
registers from 0xff200000 to 0xff3ffff, which overlay kernel mapped memory
ONLY if the processor is in a Debug state.  If that's the way it's been
done, then one is constrained in one's ability to debug kernel code/data in
that region using EJTAG (it can still be done by slight-of-hand) but it 
won't
otherwise interfere with the kernel's use of the region.

That should be the case for all "true" MIPS32 processors, but EJTAG
pre-dates the MIPS32 architecture specification, and I know that some
processors were done in the late 1990's where this "dseg" overlay of kseg2
was larger and/or permanently mapped.  If you've got one of the later,
you may have to play games with FIXADDR_TOP etc.

          Regards,

          Kevin K.

Pelton, Dave wrote:
> David VomLehn wrote:
>   
>> Pelton, Dave wrote:
>>     
>>> <snip>
>>> 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
>>> (0xFF200000-0xFFFEFFFF).
>>> 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
>>> include/asm-mips/fixmap.h.
>>> To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
>>> space.
>>>       
>> <snip>
>>
>> Is your range of addresses reserved on the BMIPS3300 because it is
>>     
> being used as
>   
>> dseg, i.e. because it is being used for debugging? If I read the
>>     
> documentation on
>   
>> the processor I am using, the 24Kc, it has a similar issue. I don't
>>     
> need to be
>   
>> able to use kmap_coherent because the 24K hardware takes care of data
>>     
> coherence
>   
>> issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we
>>     
> might just
>   
>> generally want to change FIXADDR_TOP to avoid address in the dseg
>>     
> range for all
>   
>> MIPS32 processors. As we work our way through some of the cache
>>     
> flushing issues
>   
>> related to using high memory, I'd like to be able to develop code that
>>     
> works on
>   
>> processors for which cpu_has_dc_aliases is true. If my kmap_coherent
>>     
> is working I
>   
>> can check things out for those processors and then simply use
>>     
> kmap_atomic for
>   
>> processors where cpu_has_dc_aliases is false.
>>     
>
> Apologies in advance for what my plain-text impaired mail client is
> likely to do to this message.  The reserved range on the BMIPS3300 is
> used by memory mapped registers.  I am not a memory management expert,
> so I am not sure what implications there would be to moving FIXADDR_TOP
> as a general fix.  The impression I have from general MIPS documentation
> is that kseg2 should not be used for memory mapped i/o and hence
> platforms that do this should be treated as an exception case, rather
> than moving the general case to deal with this.
>
> - David Pelton
>
>
>