Subject: Re: Stability of 2.0_RCx?
To: Christian Groessler <chris@groessler.org>
From: Marcus Comstedt <marcus@mc.pp.se>
List: port-dreamcast
Date: 12/13/2004 23:48:17
Christian Groessler <chris@groessler.org> writes:

> When an external interrupt happens it probably has to be acknowledged
> before it can occur again? Otherwise interrupts occuring too fast would
> always cause a reboot.
>
> I can see 2 possible reasons for the reboot problem:
>
> 	- exception inside an exception handler (e.g. wrong memory access
> 	  address; page swapped out)
>
> 	- enabling hw interrupts again before this above mask bit in the
> 	  status register is reset

When an interrupt or exception happens, the BL bit is automatically
set.  As I said, this causes all interrupts to be deferred.  They will
happen when the BL bit is cleared again, but not before.  (Exceptions
can not be deferred in this way, so that is why they cause a system
reset.)  So what you need to do is to acknowledge the external
interrupt source (thus causing it to stop requesting an interrupt)
before clearing the BL bit (either manually, or by returning from the
interrupt which restores the status register).

Thus your second reason is a non-issue.  You can't reenable hw
interrupts before resetting the BL bit, since the BL bit is what
disables the interrupts in the first place.  :-)


> For me the "page swapped out" case seems most difficult to sort out.

It's not just swapped out pages you have to worry about.  Since the
TLB is managed by the CPU, any TLB miss will cause an exception, even
if the target page is actually in RAM.  (Because of this, it is
essential that the exception handler itself is called through a
physical address, not a mapped one.)

What you need to do before executing any code which uses virtual
memory (or can cause any other type of exception) is to save the
exception return state (which would otherwise be overwritten by the
nested exception), adjust the interrupt mask appropriately (to only
allow interrupts over a certain level), and then manually clear the BL
bit.  Then your handler can cause exceptions which are again
dispatched back to the exception handler in the normal fashion.  It's
completely up to the software to make sure that this kind of nesting
works by saving the appropriate context in suitable locations and then
restoring it before calling RTE.  (The BL bit should be manually set
again at exit time to avoid races while restoring the exception
context.)


  // Marcus