Ryan Ordway wrote:
> 
> 	Ok, I setup a serial console between my PB540c and my Q900 to get a
> backtrace once the debugger is reached. Here's what it spat out at me:
> 
> 
> _Debugger(3fe000,41727,128674,18af04,b4904) + 6
> _panic(b47ca,114000,c00,c,100) + 50
> _uvm_km_suballoc(10d47c,18af48,18af44,114000,0) + 10a
> _pmap_init(1cb000,fffff000,18af74,18af70,130784) + 318
> _uvm_init(1beff,1befc,103388,1b870,1c630) + 54
> uvm_fault(0x10d47c, 0xfffff000, 0, 0x1) -> 0x1
>   type 8, code [mmu,,ssw]: 505
> trap type 8, code = 0x505, v = 0xfffffffb
> kernel program counter = 0xec4b8
> kernel: MMU fault trap
> Caught exception in ddb.
> _main() + 3a
> _main() + 3a
> 
> 
> 	So, it appears that the problem ISN'T where I thought it was, it's
> in pmap_init, which is machine-dependent, or at least it's located in the
> mac68k tree. But for some reason it goes past pmap_init() and doesn't
> freeze up until after uvm_pager_init().

hmmm...strange.  do you happen to know what subregion we're trying to
allocate above when we get the panic in question?  perhaps we're mapping
in something that we shouldn't for the Q9x0's...
 
> 	But then when I added the printf() calls to see where it was
> dying... it started dying in pmap_init() and actually causing a kernel
> panic and dropping into the debugger rather than just freezing up the
> machine.
> 
> 	That's about the extent of my knowledge, I've never worked this
> much with the kernel... I'm afraid I'll blow up my machines! Anyone have
> any ideas of what to try from here?

well, take a look at the code that's actually signalling the panic and
work your way back from there.  what is the actual text of the panic
itself?  don't worry, it's rather unlikely that you're going to blow up
your machine :-)  

later.

colin