In message <354CC32E.3DF74E1B@causality.com> you wrote:

> Adam Gundy wrote:
> 
> > The reason I've found this is that I've added some code to the
> > prefetch abort handler to try and fix the StrongARM LDM bug -
> > unfortunately it ends up with the same panic...
> 
> It's unfixable. I've just clarified that in the fault taken, apparently
> R14 can get trashed so there's not always a way to get bck. Bummer.
> Approaching Acorn/Simtec is probably the best bet!

The solution then is not to allow the fault to occur (which is what
my fix attempts to do):

when a prefetch abort occurs for a page

  while the last instruction on the page is an LDM or an LDR
    lock the current page in memory (ie prevent any more aborts)
    lock the next page in memory (stop the bug appearing)
  endwhile
  
  
unfortunately, the call to vm_map_pageable() rapidly (ie during
boot) results in the kernel panic I reported.

the best I can achieve without panics at the moment is simply to
pre-page the next page(s) - this didn't seem to help, but then I'm
not currently testing for LDRs (I was assuming that the next page was
being thrown out then the offending LDM reexecuted).

the number of pages locked in memory isn't too bad; my gcc 2.8.0 has about
6 LDMs (this number is going to change now that I've seen the DEC errata -
I'll have to look for LDRs as well as LDMs, but to counter that I can
ignore both if they don't change the PC). I can see that when running
X a fair number of pages will need to be wired :-(

PS for a complete solution the data abort handler will have to do the
   same checks if the abort is from an executable section of memory
   (in case a constant is read from a page with an LDM/LDR).
   
Seeya,
 Adam.
-- 
As the year 2000 approaches, the carefully planned Millenium 'bug'
begins to manifest itself in the computing job market...
Real programmers don't comment their code. If it was hard to write, it
should be harder to modify. These are all my own opinions.