The sun mmu is very broken, and we all can thank crashme for
authordavem <davem@openbsd.org>
Sun, 14 Jan 1996 00:39:18 +0000 (00:39 +0000)
committerdavem <davem@openbsd.org>
Sun, 14 Jan 1996 00:39:18 +0000 (00:39 +0000)
commit8d71c1d45f236c6efb0f749c2d53ba9433acf66a
treeeeb341f608833329d9623bf9826ba74ecc73cfb2
parent06e1e225194f77339e625451943c97baf520da1e
The sun mmu is very broken, and we all can thank crashme for
helping me find this bug.  On execution of an atomic load/store instruction
the chip will only say that a read fault is happening, we then load up a
readonly translation to the accessed page, and we get the fault again still
showing a read-fault.  We end up faulting in a loop forever and the process
appears to be completely stuck.  The algorithm to fix this problem goes like
this.  If we get a non-text fault, and the fault type is VM_PROT_READ, and
the SER_PROT bit is set in the syncronous fault error register, we take
a peek at the instruction at pc.  If this instruction is indeed an ldstub
or a swap variant we or in VM_PROT_WRITE to the fault type.
sys/arch/sparc/sparc/trap.c