> On Thu, May 24, 2001 at 12:45:31AM +0100, Mike Pumford wrote:
> > 
> > Since the binary recovered and carried on there must be something that 
> > can be done to prevent the repeated page faults and allow the program to 
> > continue. The next time I get a binary which faults in this way I will try
> > and figure out a reliable fix.
> 
> I've thought that it should be possible to "check for the condition, curse, 
> patch the instruction to the workaround in memory, synchronize i-cache with
> d-cache" might work, but I'm not familiar with the exact bug description.
> 
> Is this possible?
> 
> Regards,
> 	-is


No, because by the time the fault happens you no-longer know where the 
faulty instruction is.

Remember the problem occurs when

1) The last instruction in the page is ldr or ldm that writes the PC
2) The next page is not mapped

Condition 2 causes a tentative pre-fetch abort to be flagged in the 
pipeline.  The branch operation of 1 should clear this but doesn't, so the 
abort gets tagged against an instruction at the target of the branch; by 
the time we execute that instruction (and fault) we no-longer know where 
we were executing before, so we can't go back and fix up the problem...

R.