Subject: re: SIR Reset with todays sources
To: matthew green <firstname.lastname@example.org>
From: Eduardo Horvath <eeh@NetBSD.org>
Date: 03/19/2007 23:54:00
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
> 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
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