Well, what I would suggest is to put in a call to the Debugger() right
before that stretch of assembly code, and then single-step through it.

What this usually ends up meaning is that something in the code that was
read from the card's declaration ROM is calling some unimplemented MacOS
trap, and/or is referencing an unimplemented MacOS table by dereferencing
some low memory global.  

The stack trace isn't going to be too terribly useful, since most of the
code called from the card's ROM doesn't set up nice neat stack frames,
and gdb can't decode them very well.

BTW, nice to see someone else trying to improve upon the SLOTMAN stuff!
I hope you'll feed back any changes you end up making.

On Sun, 2 May 1999, Jason W. Fogt wrote:

> Good day everyone.
> 	While working on writing a driver for the Apple Macintosh 8-24 GC
> video card (it is a very weird card), I have gotten to the point where the
> machine consistently crashes on boot.  I consider myself fairly competent
> in basic UNIX system administration, and a fairly decent programmer,
> however, I don't know enough about what NetBSD reports when things go very
> wrong to make much sense of what is happening.
> 
> Background: I am integrating the slotman(ager) code with some parts that I
> have written myself.  The slotman(ager) code is where the error is
> occuring.  During boot, while attempting to initialize the card, the
> system consistently panics with a UVM fault.
> 
> The gory details:
> (the lines of death):
> uvm_fault(0x15ad6c,0xc4000000,0,0x3)->0x1
> type 8, code [mmu,,ssw]:401070d
> trap type 8, code=0x401070d, v=0xc4000008
> kernel program counter = 0x101f86c
> Kernel: MMU fault trap
> pid=0, pc=0101F86C, ps=2008, sfc=1, dfc=1
> (questions on this)
> 1.  what is the signifigance of each of the hexadecimal numbers in the
> line that starts with "uvm_fault" ?
> 2.  What is a type 8 ?
> 3.  What does the text "[mmu,,ssw]" mean in line 2 ?
> 4.  In general, what is the signifigance of each of the hexadecimal lines
> in this section ?
> 
> (a debugger trace)
> _Debugger(2004,1c7c28,8,28950,1c7c14)+6
> _panic(13ac8f,3,270c,4000008,152488)+52
> _trap(8,401070d,c4000008)+24e
> _end(?)
> _mrg_SExec(1c7d58,1c7d58,0,f,1379f6)+e8b1fc
> _mrg_SPrimaryInit(1c7d58,0,10138d4,1c7e66,14a74c)+ac
> ...
> (questions)
> 1.  I assume/know that the first thing on this line is the name of the
> procedure being executed, but what is the signifigance of each of the hex
> digits following it ?
> 2.  What does the "end(?)" mean (right where it died) ?
> 
> (and finally, the bit of code that is causing all the problem)
> This is an assembly block inside of mrg_SExec that should emulate the
> slot manager call to preform a primary init.  I am 99.9% certain that this
> is the last bit of code the computer executes from this program before it
> dies.
> 
> 			__asm __volatile ("
> 				movl	%1, a0
> 				addql	#4, a0
> 				movl	a0@, a2
> 				addal	a0, a2
> 				moveal	%0, a0
> 				moveml	d0-d7/a0-a6,a7@-
> 				jsr a2@
> 				moveml a7@+, d0-d7/a0-a6"
> 			    :
> 			    : "d" (sp->spsExecPBlk), "d" (execAddr)
> 			    : "a0", "a1", "a2");
>  
> 
> I am sorry for such a long question, but if anyone can help me with this,
> that would be great.  If you need more information, please don't hesitate
> to email me.
> 
> Jason
> 
> 
> =============================================================================
> Jason W. Fogt             |"What then shall we say in response to this -  If
> jwfogt@midway.uchicago.edu| God is for us, who can be against us ?" - Rom. 8:31
> =============================================================================
> 
> 

--------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:     |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com    |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  pgoyette@juniper.net |
--------------------------------------------------------------------------