COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	1.  All page faults appear as "no PT DIR MATCH" faults due to missing
C00011 ENDMK
C⊗;
1.  All page faults appear as "no PT DIR MATCH" faults due to missing
    CON KI10 PAGING MODE on E43(7) on PAG3.  Fixed by ECO 1.

2.  On PAG4 there is a term which is never true (PAGE TEST PRIVATE ∧
    PAGE UNPAGED REF ∧ PAGE EXEC REF).

3.  The MAP instruction has no chance of working in KI10 paging mode!
    On CSH3, a timing chain is started if a MAP gets a page fault, since
    PAGE REFILL is only true for KI paging mode.  However, another timing
    chain is generated by the page fault on CSH4 (PAGE FAIL T2,T3).  In
    addition, PAGE FAIL HOLD will not hold due to -APR EBOX READ REG.
    Finally, if the page fail microcode tries to restart a MAP that got
    a page fault due to no page table information being loaded, it will
    not restart properly since there is no way to generate APR EBOX READ REG.

4.  It is a bug that MCL VMA PREV EN can be caused by MCL PREV COND and
    MCL VMA/AD in certain circumstances.  If the target instruction of
    a PXCT gets a page fault, then it is quite possible that MCL PREV COND
    is asserted.  This affects the page fail microcode in at least three ways.
    When the page fail microcode tries to read a page table entry, it will
    probably do a VMA/AD,LOAD AR,PHYS REF which will set MCL VMA PREVIOUS
    which will do a user mode cycle if PCU is true.  This can be fixed by
    putting the VMA/AD and LOAD AR,PHYS REF on separate lines.  When the
    microcode attempts to restore the VMA and the MCL VMA USER bit so that
    it can write the new page table entry, it will probably do a VMA/AD,EXEC REF
    in the case where the original MCL VMA USER was off.  If, however, MCL PREV
    COND and PCU are true, MCL VMA USER will be set anyway.  This can be fixed
    in the same way.  Finally, when restarting the cycle that caused the page
    fault, the microcode may try to do VMA/AD,MEM/AD FUNC.  This may again set
    MCL VMA USER erroneously.  The fix for this is to say VMA/PC,MEM/AD FUNC
    since MEM/AD FUNC forces the VMA to be loaded from the AD anyway, and
    MCL PREV COND is only looked at under VMA/AD.

5.  When an (illegal) I/O instruction is executed in user mode, the EBOX still
    performs the MEM/AREAD function which can start a fetch of the effective
    address and possibly get a page fault.  All illegal I/O instructions should
    avoid doing an AREAD and trap as a UUO.  One kludgy way to make this happen
    is to detect -I/O LEGAL and USER MODE and -IOT USER and force the DRAM address
    to be 777 or 776.  These are CONSZ and CONSO for the external devices and
    have a DRAM A field of I and are therefore innocuous.

6.  A spurious ARX parity error will be generated under the following set
    of circumstances.  An instruction is being executed whose DRAM A field
    is I-PF, causing the next instruction to be prefetched.  However, the
    next instruction is in a different page than the current one, and the
    page table RAM indicates a page fault.  (Whether the page fault is due
    to no PT DIR MATCH or NO ACCESS or anything else is irrelevant.)  The
    MBOX will rapidly discover the page fault (within 4 ticks) and abort
    its cycle (in 3 more ticks).  CLK PAGE FAIL EN (CLK4) will be set, but
    CLK PAGE FAIL won't since the EBOX is still executing microcode for the
    immediate type instruction and has not yet caused COM MBOX WAIT.  As
    a result, the MBOX will have set CLK MBOX RESP but not CLK INSTR 1777.
    This will cause CON ARX LOADED to be set, and of course, the ARX has been
    loaded with a bad parity zero from the aborted MBOX cycle.  Therefore, when
    the EBOX finally does take the page fault, it will get an ARX parity error.

7.  CONO PI,initiate interrupt is not guaranteed to interrupt before the next
    instruction is executed (assuming you are initiating into a higher
    priority channel).  Several instructions may be executed before the
    interrupt occurs.  Similarly, if you are trying to initiate an interrupt
    in a lower priority channel, the interrupt may not (read will not) occur
    until several instruction times after the dismiss from the higher channel.
    This is due to the fact that it takes many MBOX clock periods between the
    time that the PI board detects the highest priority request and it raises
    the microcode INT REQ branch condition.  It spends all this time performing
    the EBUS handshaking protocol since it can't tell the difference at this
    point between an internally and an externally generated request.  It is
    possible to get around the first of these problems (going from a lower to
    a higher priority channel) by the following sequence of instructions:

		CONO PI,4000+CHANNEL BIT
		CONO PI,PION

    The second of these instructions first tries to grab the EBUS.  However,
    the EBUS will be busy doing the handshake for the generated interrupt and
    so the EBOX will hang until it gets the EBUS or an interrupt occurs.  The
    interrupt is guaranteed to occur first and the EBOX will then branch off
    to do the interrupt.  The PC stored will be that of the CONO PI,PION.