perm filename KL.BUG[KL,SYS] blob sn#268523
filedate 1977-03-15 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00002 00002 1. All page faults appear as "no PT DIR MATCH" faults due to missing
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
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