Re: Stability of 2.0_RCx?
Marcus Comstedt <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.dreamcast |
|---|---|
| Message-ID | <[email protected]> |
Christian Groessler <[email protected]> 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