On Tue, 20 Mar 2007, matthew green wrote:

>    As the `SIR Reset' is not solved yet I tried this:
>    
>    - Replace all `sir' opcodes to `nop' in locore.s.
>    - Put them back until I get the `SIR Reset' instead of a hard lock.
>    
>    Thus tracked it down to this `sir'.
>    
>    --- locore.s	2007-02-23 02:06:38.000000000 +0100
>    +++ locore.s	2007-03-19 13:01:54.000000000 +0100
>    @@ -2099,5 +2099,5 @@ winfix:
>     	!!
>     	wrpr	%g2, %tl		! Restore trap level.
>    -	sir				! Just issue a reset and don't try to recover.
>    +	nop				! Just issue a reset and don't try to recover.
>     	mov	%fp, %l6		! Save the frame pointer
>     	set	EINTSTACK+USPACE+CC64FSZ-STKB, %fp ! Set the frame pointer to the middle of the idle stack
>    
>    Is it really possible to reach this statement?
>    
>    Any chance to get a trace or otherwise debug it?

Do a .trap-registers and compare your the different TPC values to specific 
sir instructions in locore.s.  You can use GDB on the kernel for the 
latter.

> what does "ctrace" from the prom say at this point?  that should
> give you a stack trace you can feed addresses back to GDB for
> to get line numbers.

ctrace is unlikely to help here since the machine state is completely 
stuffed up.

Try enabling traptrace and then see if you can dump the contents of
the traptrace buffer at OpenBoot.  That should give you some idea what set 
of conditions led to this situation.  You can also try changing the sir 
instructions to jump to a bit of code that completely reinitializes the 
processor state and enters DDB, that way you can dump the traptrace buffer 
more easily.

Eduardo