Subject: Re: more Q900 info
To: None <ender@macbsd.com>
From: Ryan Ordway <sammael@pacifier.com>
List: port-mac68k
Date: 07/21/1999 08:38:54
At 1:56 PM -0700 7/20/99, Colin Wood wrote:
>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 :-)

	In pmap_init() we call uvm_km_suballoc() twice. It's dying on the
first call, on the call to uvm_map_submap() within uvm_km_suballoc() in
uvm_km.c. The text of the panic reads: panic: uvm_km_suballoc: submap
allocation failed.

	I find it interesting that before I started digging around this
panic() was never triggered, but when I added a few printf() calls to
determine where the thing was dying, I got a panic. Unfortunately I'm not
good enough with m68k assembly to step through from boottime and see
exactly what is going on, but I could boot via serial console and keep a
log of it if that would help someone else figure it out.

	I have an unsupported video card and an unsupported serial port
card in this machine right now. Could that cause problems like this? I
wouldn't think so, since it boots a 1.4C kernel just fine, even into
multi-user.

	Does anyone have a copy of the UVM code from around 06061999? That
is the last kernel that I have tried that boots without problems.
Apparently something has changed between then and now to cause problems, at
least on this machine.

	In the meantime I will try some older kernels from the snapshots on
ftp.netbsd.org to see when the last bootable kernel was compiled to zero in
on what was changed that broke the Q9x0 support. And of course, any advice
and help is appreciated. :-)

	Thanks,

	Ryan




--
HELO... my name is rewt... you have SIGKILLed my father... prepare to vi!