On Mon, 10 Aug 1998, Richard Earnshaw wrote:

> > > $ uname -a
> > > NetBSD shark1 1.3F NetBSD 1.3F (SHARK) #0: Fri Jun 26 10:33:59 EDT 1998    
> > >  tv@nc1.home.duh.org:/usr/SRC/netbsd/src/sys/arch/arm32/compile/SHARK arm32
> > > 
> > > While trying to test out a snapshot of EGCS 1.1 development tree, I tried 
> > > to build the Xemacs package, but the emacs binary seems to be looping 
> > > infinitely into the kernel when trying to execute a strh instruction to 
> > > the first word of a page (I suspect the page is newly allocated, but can't 
> > > be sure).
> > 
> > Ok this could be a bug in the fault handler. There should not be any
> > actual register fixups requires for the SA110 that some of the older ARM
> > needs but the faulting instruction is disassembled to determine if the
> > fault was caused by a load or a store. I suspect that this is going wrong
> > for the strh and ldrh instructions and thus the page is only ever being
> > mapped as read only which would explain the looping ..
> > 
> 
> Poking the memory location with gdb means that the instruction will then 
> execute successfully.

That would make sense as the poke will result in the page gaining write
access.

Cheers,
				Mark