summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authordavem <davem@cvs.openbsd.org>1996-01-14 00:39:19 +0000
committerdavem <davem@cvs.openbsd.org>1996-01-14 00:39:19 +0000
commit1b2c14105180551c765eaaeec49fe51420a7492e (patch)
treeb753b44e4fff5db36043d7030729a265e05feab6 /lib
parent91703ca9110fc1d4453236b51c3976121762ee57 (diff)
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.
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions