In message <3551B69E.4F5B2B08@causality.com> you wrote:

> kim@pvv.ntnu.no wrote:
> 
> ...
> 
> I think the best fixup is to get the compiler to emit every LDM twice,
> and then NOP one of them out... Huh, but LDRs may cause it too, and
> doubling and NOPing every LDR will hit performance noticably... Aaargh!

horrible. screwing everyone's binaries just for rev K StrongARMS.

> I think the best bet may be to get those StrongARMs replaced :-) When we
> go to UVM the problem may get a bit better as there will then be
> clustered page-ins. I've had an ugly thought: Hack the kernel to check,
> when it pages a page in, if the last instruction is an LDR, if so, bring
> in the next page too :) Or did someone already start implementing this,
> I can't remember... This is _so_ ugly though!

ugly? it's what DEC suggest in their errata...

I've already implemented what you suggest and it isn't enough 
(ie it doesn't prevent the problem all the time) - the pages need to
be locked in memory as well (to prevent the 'next' page from being
thrown out by the page stealer). 

Unfortunately we then get a kernel panic due to a bug in (I think)
the MI VM stuff...
As an aside, does anyone have a non-ARM NetBSD machine that
they can test for this panic on?

try (as root):

mlock( 4096, 4096 );
fork();

This will panic with "vm_fault_copy_wired: page missing". If it happens
on a non-ARM system I'll raise a PR..

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.