> I do not know enough about SPARC processors at that level - are
> window underflows common or are they an abberation that is signalled
> ?

A window underflow trap is taken when a restore instruction tries to
restore into a window that is not resident.  They are in no way
aberrant; any return from a routine is liable to cause a window
underflow.  Even in cases like leaf routines, it can still happen; the
kernel may have had to handle an interrupt or something that forced the
user windows onto the stack.

> If so, when one occurs, restart any outstanding SCSI requests ...

My reaction to this is that it's way, way, overkill to bash all
outstanding SCSI requests every time a window underflow happens.  If
nothing else, on a processor with a reasonably small number of windows,
the code to restart the SCSI requests could run the machine out of
windows, thereby causing a window underflow trap as soon as (or perhaps
even before) it returns to user-land.  This would be a Bad Thing. :-)

I'm having trouble thinking of a way of handling this that doesn't
involve (a) not using CPUs that randomly issue reads to random
addresses (I'd call such hardware severely broken) or (b) putting some
kind of timeout on SCSI requests, which could be very bad for tapes.
You might be able to get away with putting a timeout on SCSI requests
to disk...though then you could still get stuck missing a completion
interrupt from a tape.

Or I suppose you could hack gcc so it never, ever, uses %o7 for
anything (just remove %i7 and %o7 from the machine description,
perhaps), and go through and make sure none of the .s code in the tree
does either...except perhaps window spill and load, which could be
changed but it's probably easier not to.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D