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.
