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
C00015 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 KL10 paging mode with 101 ucode.
    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 CON 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 or CONO PI,0

    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.

8.  [This one comes from MIT]
    CONO PI,turn off channel does not necessarily prevent interrupts on that
    channel.  Consider the following scenario.  While the EBOX is doing a
    CONO PI,CH3OFF and has the EBUS grabbed, PIR3 may still be set by a
    PI5 LOAD.  PIR3 causes PI2 REQ which stops the PI5 LOAD/PI5 TEST
    synchronizer while in PI5 TEST causing PI5 EBUS REQ.  The PI system
    remains in this state all during the remainder of the CONO PI,CH3OFF
    microcode.  When the EBOX releases the EBUS, PI5 EBUS REQ will cause a
    PI cycle to be started for the channel 3 interrupt even though channel
    3 is now turned off.  This can causes serious system problems since it
    takes several instruction times for this interrupt to percolate through
    the EBUS handshake protocol, during which time the processor can enter
    its critical section of code which, it thinks, cannot be interrupted
    out of.  In our system, this is fixed by checking to see that the PI channel
    is turned on when an interrupt occurs.  If not, the interrupt is dismissed.
    This problem is fixed by Rev 8.  (See ECO.LOG item 13 for a description of
    the fix.)

9.  The EBOX meter counts too few times for the case of a JRST . in the
    cache.  There are 4 microinstructions, each of which is 2 MBOX ticks
    long, except that one of them is 3 ticks due to an MBWAIT.  Therefore,
    8 ticks should be counted for the EBOX (not waiting for memory).
    However, the EBOX counter only counts to 7.  The problem is due to the
    signal MTR EBOX WAITING which is the and of CLK EBOX SYNC and CON MBOX WAIT.
    (With Rev 8 it includes -VMA AC REF too.)  This signal comes true one
    tick before the EBOX is actually waiting for the MBOX.  (This is the right
    thing, since it is looked at on the next MBOX clock.)  However, it goes
    away at the same time as the next EBOX clock which happens concurrently
    with an MBOX clock.  Since it is looked at on an MBOX clock, it is
    therefore true one tick too many.  It should drop one MBOX tick before
    CON MBOX WAIT does, so that on the next MBOX tick the meter board will
    be charging time to the EBOX rather than the MBOX.  This could be accomplished
    by adding one more term to the and gate that produces MTR EBOX WAITING.
    Adding -CLK MB XFER should cause MTR EBOX WAITING to drop just as the MBOX
    tells the clock board it is done, which is one tick before the next EBOX
    clock.