Why does one "stw" fail with address translation disabled in PPC405EP?

[Josh Boyer]

On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote:
>Hi, all:
>    I think I meet an odd problem with PPC405EP (PPChameleonEVB Board).

What kernel version are you using?

>    I am running a kernel module which will execute a user space
>application. The entry point of the application is 0x100000a0. At the

That should be the first clue that you are doing it wrong.  Don't do
stuff like that in modules...

>moment when the processor tries to execute the application, 0x100000a0
>is not in TLB (this can be seen from BDI by printing out TLB entries),
>so DTLBMiss is called automatically and then finish_tlb_load. However,
>InstructionAccess is followed and the problem arises here.
>InstructionAccess starts from 0x400, and after instruction "0xc0000434
><InstructionAccess+52>:      stw     r12,64(r11)", machine check occurs.
>This instruction will store the value of r12, which is 0x0 at this
>moment, to address 0x03072de0. I am puzzled why this action leads to
>machine check. Is it illegal to store 0x0 in a memory address? Or is
>there some other cause of the machine check here?

I have no idea if you're using physical or virtual addresses here, so
there isn't much we can do to help you.

Do you have enough DRAM to cover that?  Some of those boards only come
with 32MiB of DRAM.

josh