[PATCH] 8xx: tlbie debugging aid (try #2)

[Marcelo Tosatti]

Hi Dan,

On Mon, Jun 27, 2005 at 04:18:14PM -0400, Dan Malek wrote:
> 
> On Jun 27, 2005, at 10:28 AM, Marcelo Tosatti wrote:
> 
> >it yields
> >
> >_tlbie on pinned range: c0000000-c1800000
> >Badness in _tlbie at arch/ppc/mm/pgtable.c:527
> >Call trace:
> > [c0005530] dump_stack+0x18/0x28
> > [c0003628] check_bug_trap+0x84/0xac
> > [c00037b0] ProgramCheckException+0x160/0x1a0
> > [c0002d50] ret_from_except_full+0x0/0x4c
> > [c000a91c] _tlbie+0x94/0xa0
> > [c902f018] alloc_init_module+0x18/0x40 [alloc]
> > [c002c4ac] sys_init_module+0x224/0x324
> > [c00026f0] ret_from_syscall+0x0/0x44

Note: this was just a test module doing tlbie(0xc0000100)... 
Hum, it should also print out the address in question...

> How much real memory on your board?

128M

> We need to ensure VMALLOC_START is beyond
> the pinned entries. 

Right now VMALLOC_START is before the IMMR pinned space.

> We should make all of the code
> much smarter to pin on the real space that is on
> the board.  

Oh! What are the side effects of such pinning as the 
code is today?

The only issue I see with pinning virtual address translations
farther the the physical addresses (real space) is that we lose
some virtual space, but nothing more than that.

Is it only that?

> For testing now, just make VMALLOC_OFFSET
> 32M, which will push the start to the 32M boundary
> after the kernel.

For what purpose? Sorry I don't get you, please be more
verbose.