On Tue, 5 May 1998, Kim G. S. OEyhus wrote:

> Where the LDM^ paging bugs fit into this scheme, I havent the
> faintest notion about. 

Hmm as has been usual lately I am very slow to join in some of these
discussions ;-)

...

What LDM^ bug ? I am not aware of one.

There is a STM^ bug which the kernel is aware of and I work round this
one.

This is basically a bug in

stm	r0, {r0-r14}^

when executed in a priveledged mode during a cache line that causes
the stored registers to be corrupted.
This as a simple workout of avoiding the store like this and breaking it
up into several different stores.
(Have a look at the PUSHFRAME in sys/arch/arm32/include/frame.h for
example).

The LDM bug at the end of the page does not involve the use of ^
LDM^ will never be used by user land programs as it only makes sense
from a priviledged mode to access the USR32 registers.

Now the rev K bug that is causing all the problems is an LDM at the end of
a page when the following page is not accessable. There are some potential
issues with whether the following page is genuinely invalid or whether it
is invalid due to permissions. You also need to couple it with whether
there is a TLB entry for the location after the LDM instuction or not,
wether the data loading into the PC is cached or not etc.etc.

The upshot of which was then when I first looked into this problem some
time ago now there was a recovery problem i.e. you took a prefetch abort
that you should not have but the return address from that abort was a
problem. One example of the problem was binaries would appear to lock up
in endless loops prefetch aborting of pages that were already mapped and
with the prefetch abort handler returning to the wrong location after the
abort or they would SEGV as the return address from the abort was wrong.

The word I got from talking to people who know was that either you avoid
generating the situation or you get out your soldering iron.

It is entirely possible that the problem is better understood now and that
there may be possible ways to work around it or ways to minimise its
impact on the system.

Certainly I can think of one or two hacks that could be tried in order to
reduce the frequency of hitting this problem.

As soon as I can find a source for a rev K RiscPC cpu card I will take
another look at things.

Certainly I had not realised until recently just how much of a problem
this bug was on the 1.3.1 release as I am without rev K silicon to play
with (everything is rev S until I can get some rev T)

Cheers,
				Mark