> > ( I'm not too sure on this part, but this is the bit that doesn't work...)
> > When an LDM is the last instruction on the end of a page it causes the fault
> > to return to the wrong place, IE back to the LDM instruction on the end of
> > the page
> > 
> > This is how I interpretted what I've seen.
> 
> Hm. But if it is that would'nt it be possible to do a workaround in the
> VM system? It should be possible. You could have a look where the fault
> wants to return to. If it is a LDM instruction just before a page boundary
> you increase the return address by 4 so that it points just behind the LDM
> as it should. Could there be problems with such a workaround?
> 

Not like this.  The problem occurs when the LDM restores the PC (ie a 
return).  If the next page (in the virtual address space) after the 
address where the LDM is located is not mapped in then the prefetch abort 
that is in the pipeline does not get cleared by the action of flushing the 
instruction pipeline.  What then happens is that your program takes a 
prefetch abort which appears to have come from the page where the return 
occured (rather than the one after the LDM instruction).  The vm system 
then ensures that the page where the fault "occurred" is loaded and 
restarts the faulting instruction.  Unfortunately the "faulting" 
instruction in this case is usually a bl to the subroutine you have just 
returned from.

I'm told that no successful fix for the problem has been found, since 
occasionally certain registers can become corrupted (I don't know how or 
in what way), and the only solution is either to fix your processor (get a 
new one) or write your VM system in a way that the fault will never occur 
-- the note I posted a reference to earlier has some suggestions and I'm 
not sure why these can't be implemented in NetBSD -- unfortunately I'm not 
a vm expert so I can't comment on the practicality of these.

This is just speculation, but maybe another solution which might work 
_most_ of the time (it is easy to construct cases where it could fail, but 
it would be somewhat rare for them to occur in practice) would be for the 
VM system to check if the faulting page really were mapped out or marked 
unavailable, and if not to just try returning to the address _after_ the 
one it appears to have come from.

Richard.